Проблема ТС в том, что он отформатировал корень в F2FS. Для того, чтобы refind смог найти и загрузить ядра с F2FS раздела, нужен соответствующий EFI драйвер. Единственные (полу)рабочие драйверы для нестандартных ФС тут: https://efi.akeo.ie/
У меня самого корень на XFS, с этим драйвером Refind находит файлы ядра, но не может их загрузить с невероятно быстро мелькающей ошибкой "Failed to load initrd: Buffer too small", которую удалось заснять только на ультразамедленную съёмку на телефон (наверное, это проблема EFI моей материнской платы). С F2FS драйвером аналогично. Возможно, на других материнских платах получится загрузиться.
Варианта у ТС три:
1. Попробовать этот драйвер
2. Вынести /boot на отдельный раздел с ext4(3,2), для которой есть беспроблемный драйвер
3. Грузиться через GRUB, он грузит и с F2FS, и с XFS (я остановился на этом).
В первую очередь - убрать разгон памяти (если был ручной) или же отключить XMP профиль. От переразгона памяти имел похожие проблемы с ryzen 2600.
Пока пересел на Pantheon, с linux-ck ядром поприятнее немного стало, но дёргания анимации всё равно есть. Подозреваю, что дальнейшее улучшение будет происходить через повышение производительности самого композитора - в данном случае mutter. Сейчас там много открытых пулл реквестов, например такой: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1309
Правда, накладывается патч только на самый свежий master, а там версия mutter 3.37.91 с новой версией API, с которой gala (надстройка Pantheon над mutter) ещё не работает.
vasek
и все-таки интересно посмотреть, что будет если отключить hpet - попробуй загрузиться с параметром hpet=disable

PS - перед отключением посмотри выводы # grep hpet /proc/timer_list и dmesg | grep hpet, чтобы потом сравнить их с отключенным hpet
очень интересно.
Загрузился с hpet=disable - vsyncmark на vsynctester.com вырос с 100 до 150, а если клацать на окна, то и до 200 вырастает (видимо вместе с возрастанием частоты GPU). Статтеры остались, но не такие сильные - визуально плавнее стало (у меня 144 герца, кстати, поэтому всё это очень хорошо видно).
Тем не менее, на AMD (ryzen 2600 + rx 570) было гораздо плавнее в linux (а вот в оффтопике наоборот).
Рост балла vsyncmark на vsynctester.com и увеличение плавности похоже произошли от перехода на linux-ck ядро, а не от отключения HPET. Перезагрузился с включённым - никаких изменений.
Процессор остался старый? 
Заменён на i9-9900. Думаю, окошки рисовать с эффектиками должно хватать. Во всяком случае, в оффтопике хватает.
При фоновой нагрузке ничего не меняется. Да, частота становится максимальной, статтеры всё равно продолжаются.

direct rendering: Yes

TrippleBuffer уже пробовал, попробовал ещё раз - не помогает (в т.ч. в комбинации с ForceFullCompositionPipeline)

В логах ошибок отрисовки нет.
Глянул. Ну растёт загрузка GPU с 15% до 40%, потом резко вниз. Больше ничего не увидел.
Примерно полгода назад последний раз заходил в linux десктоп - была видеокарта RX 570 и всё работало отлично с драйвером amdgpu.
Недавно обновил аппаратуру, теперь видео RTX 2070 Super. Наблюдаю следующую проблему с проприетарным драйвером:
в любом композитном менеджере (kwin, mutter, gala) при открытии любого окна, даже например всплывающего окна календаря, происходит очень заметный лаг/фриз/статтер.
Как проверяю - в браузере открывал vsynctester.com и дальше нажимаю на менюшки, запускаю приложения и вижу всплески на графике задержки vsynctester. Проблема в том, что фриз происходит всегда, то есть проблема судя по всему не в первичной подгрузке ассетов приложения, потому что при втором и следующих запусках происходит то же самое, хотя казалось бы кеш уже есть.
Проверял, повторюсь, везде - KDE (Kwin-lowlatency тоже пробовал - никаких улучшений), GNOME, Pantheon.
Более того, помимо Арча проверял в Федоре - там то же самое.
Что пробовал: force (full) composite pipeline, отключение flipping, выставление powermizer в производительный режим, включение тройной буферизации. Не работает ничего ни в каких комбинациях.
Вижу, что даже тут на форуме люди с Nvidia замечали, что интерфейс после обновлений стал дёрганный - подозреваю, именно это они и наблюдают. Нагуглил всего одну похожую проблему (https://github.com/PapirusDevelopmentTeam/arc-kde/issues/117), но там помогает смена темы в KDE - мне же не помогает даже смена DE. Куда ещё копать не представляю. Думал, может всё-таки дело в i/o или cpu планировщике - ставил разные ядра, включая realtime, пробовал разные планировщики для nvme - ничего не помогает.
linux /boot/vmlinuz-linux-lts root=/dev/sdb3
sda3 должно быть. Лучше вообще заменить на UUID как для Debian.
Извиняюсь за оффтоп, но: слишком часто стало происходить, не находите?
Не помню вообще ни разу таких проблем года эдак до 2017.