booidea, glxinfo у вас показывает что-нибудь? У меня там можно найти такие строчки
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 430.50
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Ну, может быть перемотать эту красоту вверх и там посмотреть или только это и есть?

В xorg у вас vesa фигурирует почему-то, к сожалению я не спец и надо ждать прокуренных манами друидов. Признаться даже не знаю как без перемотки в терминале посмотреть вендора и драйвера с их версиями. Bormant придёт чего-нибудь умного скажет...

Это ничего не значит, всего лишь список автоконфига иксов, иксы пробуют драйвера в порядке приоритета, карту все-равно подхватывает AMDGPU:

[    61.341] (==) Matched amdgpu as autoconfigured driver 0
[    61.341] (==) Matched ati as autoconfigured driver 1
[    61.341] (==) Matched modesetting as autoconfigured driver 2
[    61.341] (==) Matched fbdev as autoconfigured driver 3
[    61.341] (==) Matched vesa as autoconfigured driver 4

[    61.341] (II) LoadModule: "amdgpu"
[    61.342] (II) Loading /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
[    61.389] (II) Module amdgpu: vendor="X.Org Foundation"
[    61.389]     compiled for 1.20.5, module version = 19.1.0
[    61.390]     Module class: X.Org Video Driver
[    61.390]     ABI class: X.Org Video Driver, version 24.0

[    61.405] (WW) Warning, couldn't open module fbdev
[    61.405] (EE) Failed to load module "fbdev" (module does not exist, 0)

[    61.408] (II) AMDGPU: Driver for AMD Radeon:
[    61.415] (II) AMDGPU(0): [KMS] Kernel modesetting enabled.
[    61.445] (II) AMDGPU(0): Creating default Display subsection in Screen section
    "Default Screen Section" for depth/fbbpp 24/32
[    61.445] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[    61.445] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[    61.445] (==) AMDGPU(0): Default visual is TrueColor
[    61.445] (==) AMDGPU(0): RGB weight 888
[    61.445] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC)
[    61.445] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x98e4)

...

[    64.386] (II) UnloadModule: "modesetting"
[    64.386] (II) Unloading modesetting
[    64.386] (II) UnloadModule: "vesa"
[    64.386] (II) Unloading vesa

*** Добавлено: 26.10.2019 18:04:23 ***

Меня смущает, что иксовый драйвер не знает непосредственно этот адаптер:

[    61.445] (--) AMDGPU(0): Chipset: "Unknown AMD Radeon GPU" (ChipID = 0x98e4)

Версия драйвера xf86-video-amdgpu последняя доступная:
https://gitlab.freedesktop.org/xorg/dri … deo-amdgpu

В lilo.conf не обязательно вписывать на этапе тестирования, можно указать их при загрузке в командной строке (в меню LILO нажать таб, набрать имя пункта, набрать желаемые параметры, нажать Enter) и посмотреть, повлияло ли это на что-либо.

Если вписывать, есть смысл скопировать пункт меню, поменять ему label, дописать в этот пункт в addappend = "...", если будут проблемы с загрузкой, можно будет погрузиться нормально.

Если грузитесь через LILO, в /etc/lilo.conf что-то такое:

image = /boot/vmlinuz
  root = /dev/sda2  # тут имя вашего корневого устройства
  label = Linux
  read-only

Это и копируем, получится что-то вроде:

image = /boot/vmlinuz
  root = /dev/sda2  # тут имя вашего корневого устройства
  label = Linux
  read-only
image = /boot/vmlinuz
  root = /dev/sda2  # тут имя вашего корневого устройства
  addappend = "amdgpu.dc=0 amdgpu.dpm=0 amdgpu.aspm=0 amdgpu.runpm=0 amdgpu.bapm=0"
  label = Linux2
  read-only

Потом от root зовем

# lilo -v

Контролируем отсутствие ошибок.

Что из этих параметров и как влияет, что нужно оставить следует определять экспериментально.
*** Добавлено: 26.10.2019 18:48:56 ***

в меню LILO нажать Таб, набрать имя пункта (автодополнение по Tab кажется тоже работает), набрать следом желаемые параметры, нажать Enter

booidea,
рекомендую немного продолжить эксперимент, и начать отключать добавленное по одному, чтобы понять, что имело отношение к решению проблемы.
Так-то все *pm касаются управления питанием -- power management.

Можно так.
Скорее всего можно также в командной строке LILO при загрузке машины вписывать противоположное:
boot: Linux2 amdgpu.bapm=1
Но тут не уверен, как отреагирует модуль amdgpu на наличие в комстроке ядра "amdgpu.bapm=0 amdgpu.bapm=1". Должен брать последнее значение, но  как оно на самом деле окажется, утверждать не возьмусь.

Если уж трогать конфиг, то лучше удалять. Вдруг у каких-то из них дефолт не 1, а другое значение?

Стоит проверить реальное содержимое ком.строки ядра, вдруг не туда или не с тем прогрузились

Все на месте?
*** Добавлено: 27.10.2019 07:52:14 ***

Не появилось ли чего подозрительного в журналах (/var/log/messages, /var/log/Xorg.0.log)?

*** Добавлено: 27.10.2019 08:12:18 ***

Может видео моргания записать секунд от 10 и выложить куда-то.

Вообще говоря, моргания бывают весьма разные, некоторые могут быть вызваны тривиальными аппаратными проблемами: повреждением шлейфа, нарушением контакта видеочипа и т.п. Часто проблема может проявляться после прогрева, или наоборот, уходить после прогрева (тепловые деформации). Поэтому проверку работы в Windows как в предпочитаемой производителем ОС, тоже было бы не лишним провести. А с учетом того, что для проявления может требоваться длительное время, то и время наблюдения обеспечить соответствующее.

Сегодня раздобуду флешку и попробую livecd винды десятки, для так сказать исключения аппаратной проблемы.

Я много лет пользуюсь слакой, мне очень удобно, совсем не хочется изменять привычкам. Считаю её оптимальным дистрибутивом.
*** Добавлено: 27.10.2019 09:49:54 ***

/var/log/Xorg.0.log:
https://dropmefiles.com/BnvUP

/var/log/messages:
https://dropmefiles.com/sRJy9

*** Добавлено: 27.10.2019 09:56:21 ***

Видео «мигания»:

vimple.co/9d4f2bcb426d423b91603ecc54e62c85

Еще такое соображение.
Поскольку влияние оказывают параметры, передаваемые ядру (на самом деле модулю ядра amdgpu), то корень проблемы скорее всего именно в модуле ядра, а не в драйвере X /usr/lib64/xorg/modules/drivers/amdgpu_drv.so.

Поэтому имеет смысл посмотреть на журналы изменений в ядрах, обращая внимание на наличие изменений в модуле amdgpu. При наличии таких изменений либо применить аналогичные заплатки и пересобрать модуль в 4.19, либо, если изменения зависели и от прочих подсистем ядра, собрать ядрышко новой версии и проверить, как там обстоят дела.

Исходники в ядерной DVCS:
https://git.kernel.org/pub/scm/linux/ke … pu/drm/amd

Журнал изменений разрабатываемого ядра в части amdgpu и рядом весьма активный:
https://git.kernel.org/pub/scm/linux/ke … pu/drm/amd

Можно зайти с другого конца.
Собрал ядро 5.4_rc5 (конфиг от 4.19.х из current + make olddefconfig) -- по идее последнее из актуальных и будущий LTS:
https://dropmefiles.com/spAxj
можете попробовать с ним.
Сперва подстелите соломки: пропишите в lilo.conf в дополнительный пункт текущее ядро по полному его имени (вместо ссылки vmlinuz).

append = " "
...

image = /boot/vmlinuz
  root = /dev/sda2  # ваш корень
  label = Linux
  read-only

image = /boot/vmlinuz
  addappend = "amdgpu.dc=0 amdgpu.dpm=0 amdgpu.aspm=0 amdgpu.runpm=0 amdgpu.bapm=0"
  root = /dev/sda2  # ваш корень
  label = LinuxA
  read-only

image = /boot/vmlinuz-huge-4.19.80
  addappend = "amdgpu.dc=0 amdgpu.dpm=0 amdgpu.aspm=0 amdgpu.runpm=0 amdgpu.bapm=0"
  root = /dev/sda2  # ваш корень
  label = Linux419
  read-only

Затем распакуйте тарбол в отдельный каталог и поставьте новые ядра и модули рядом (без замены уже установленных -- по installpkg, ссылка vmlinuz будет переставлена на последнее установленное ядро), затем позовите lilo и проконтролируйте отсутствие ошибок:

# mkdir /tmp/kernel-5.4_rc5; cd /tmp/kernel-5.4_rc5
# tar xf /tmp/kernel-5.4_rc5.tar
# installpkg kernel-*t?z  # это гарантирует, что последним поставится -huge- и /boot/vmlinuz будет указывать на него
# lilo -v

Загрузитесь с 5.4_rc5 (пункт меню, где image = /boot/vmlinuz) и посмотрите, нет ли положительных сдвигов для случая без дополнительных amdgpu.*= и, если есть проблемы, с дополнительными ;-)

Спасибо