Сбой запуска GL приложения по ssh -X

Имей в виду, что ты сможешь через Indirect GLX пускать приложения, которые используют OpenGL не выше 2.0 . Стандарт GLX вообще остановился на 1.4, но NVIDIA допинали до 2.0 и даже вроде для 2.1 что-то было. Недавно, правда, Adam Jackson кинул issue в стиле «а давайте улучшим» https://gitlab.freedesktop.org/xorg/xserver/-/issues/997. Но пока за это никто не брался и сильно не факт, что возьмется.

А что у тебя не запускается? glxgears (в теге увидел)? Этот вроде должен. Так запускаешь?

LIBGL_ALWAYS_INDIRECT=1 glxgears

LIBGL_ALWAYS_INDIRECT не влияет на успех запуска, только лога меньше

user1@astra:~$ LIBGL_ALWAYS_INDIRECT=1 glxgears
Error: couldn't get an RGB, Double-buffered visual

user1@astra:~$ LIBGL_DEBUG=verbose glxgears
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
libGL: Can't open configuration file /home/user1/.drirc: No such file or directory.
libGL: Can't open configuration file /home/user1/.drirc: No such file or directory.
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Error: couldn't get an RGB, Double-buffered visual

А, ну да. Я что-то тормознул. Ты же проприетарные дрова используешь. Тогда вот тут кое-что есть:

https://download.nvidia.com/XFree86/Linux-x86_64/340.17/README/openglenvvaria...

Using Unofficial GLX protocol

By default, the NVIDIA GLX implementation will not expose GLX protocol for GL commands if the protocol is not considered complete. Protocol could be considered incomplete for a number of reasons. The implementation could still be under development and contain known bugs, or the protocol specification itself could be under development or going through review. If users would like to test the client-side portion of such protocol when using indirect rendering, they can set the __GL_ALLOW_UNOFFICIAL_PROTOCOL environment variable to a non-zero value before starting their GLX application. When an NVIDIA GLX server is used, the related X Config option AllowUnofficialGLXProtocol will need to be set as well to enable support in the server.

В соседнем топике похожее было libGL error: failed to load driver: swrast и как вариант https://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update

установка опции Option «AllowUnofficialGLXProtocol» «on» не помогла и вручную:

kubuntu$ export __GL_ALLOW_UNOFFICIAL_PROTOCOL="1"; ssh -X user1@172.16.137.192 glxgears
user1@172.16.137.192's password: 
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Error: couldn't get an RGB, Double-buffered visual

насколько я понял соседний топик, то там была проблема с 32 разрядными приложениями, но у меня всё 64 бит

Это всё причина того что libGL у всех свой. Гуглится что или через ссылку или через LD_PRELOAD указывают libGL от nvidia https://askubuntu.com/a/566522

установка опции Option «AllowUnofficialGLXProtocol» «on» не помогла и вручную:

Есть информация, что проприетарный драйвер nvidia надо установить на обе машины, как это не странно [1]. На машину с приложениями поставь nvidia-glx той же версии (потом снесешь, если что).

[1]https://forums.developer.nvidia.com/t/glx-app-crashes-with-remote-ssh-ok-loca...

На машину с приложениями поставь nvidia-glx

вот бы не догадался ставить дрова в отсутствии карты !
glxgears появились, но не крутятся

$ LIBGL_DEBUG=verbose glxinfo |head
name of display: astra:10.0
display: astra:10  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
    GLX_ARB_context_flush_control, GLX_ARB_create_context, 
    GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
    GLX_ARB_multisample, GLX_EXT_buffer_age,

при этом аналогичный запуск из ubuntu 20.04 - direct rendering: Yes и шестеренки крутятся, пусть и медленно
можно ли както включить direct rendering при запуске с kubuntu ?

вот бы не догадался ставить дрова в отсутствии карты !

Ну не совсем дрова, а только реализацию GLX, если она отдельно устанавливается.

при этом аналогичный запуск из ubuntu 20.04 - direct rendering: Yes и шестеренки крутятся, пусть и медленно можно ли както включить direct rendering при запуске с kubuntu ?

Не совсем понял. Есть удаленная машина на Astra Linux и две клиентские машины: одна на kubuntu, а другая на ubuntu и на одной работает, а на другой не работает?

Есть удаленная машина на Astra Linux и две клиентские машины: одна на kubuntu, а другая на ubuntu и на одной работает, а на другой не работает?

да, так вот странно ведут себя они
а еще точнее ubuntu это виртуалка на kubuntu (vmware), казалось бы тут должно быть хуже, а нет

Ума не приложу. Может быть, попробовать синхронизацию с VBLANK включить/выключить? Я посмотрел, что в nvidia это переменная

Vblank syncing

The __GL_SYNC_TO_VBLANK (boolean) environment variable can be used to control whether swaps are synchronized to a display device's vertical refresh.

Setting __GL_SYNC_TO_VBLANK=0 allows glXSwapBuffers to swap without waiting for vblank.

Setting __GL_SYNC_TO_VBLANK=1 forces glXSwapBuffers to synchronize with the vertical blanking period. This is the default behavior.

игрища с vblank (echo «0/SyncToVBlank=0» >> ~/.nvidia-settings-rc на kubuntu) улучшили результат - шестеренки закрутились, но медленно, рывками

97534 frames in 5.4 seconds = 18192.564 FPS

при этом для ubuntu тоже не быстро, но всеже побыстрее

62 frames in 5.1 seconds = 12.203 FPS

direct rendering остается = No
возможно я хочу слишком многого в такой связке, где на удаленной машине нет nvidia карты, а на локальной есть и они путаются

А у тебя какое соединение вообще? Локальный Ethernet? Локальный Wi-Fi? Интернет-соединение?

Еще попробуй ssh с опциями -X, -XC, -Y.

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

Делай коннект на свою машину и будет работать , а то виндузота решила что она умнее других

> установка опции Option «AllowUnofficialGLXProtocol» «on» не помогла

Насколько я помню, Indirect Rendering отключен по умолчанию начиная с X-Server 1.17. Надо вручную включать. Я редактировал конфиг KDM, добавляя параметр +iglx

https://www.scm.com/doc/Installation/Remote_GUI.html
https://askubuntu.com/questions/745135/how-to-enable-indirect-glx-contexts-ig...

Он вклчил. Иначе бы вообще ничего не работало. Из поста:

[    10.349] (**) Option "IndirectGLX" "on"

А покажи на всякий случай лог загрузки иксов на kubuntu на pastebin.com. (файл /var/log/Xorg.0.log)

Xorg.0.log = https://pastebin.com/QC7ucYpb
Соединение между компами - ethernet 100mbit
-XC - не помогает, думаю трафик тут и небольшой

Соединение между компами - ethernet 100mbit

В принципе, на такой связи должно быть все нормально. Тем более что glxgears ну примитивное приложение. Где-то какой-то затык. Может быть, связанный с проприетарным драйвером. Попробуй все-таки без композитора запустить для галочки.

И еще покажи, а как симлинки разложились после установки драйверов на Astra Linux.

$ ls -l /usr/lib/x86_64-linux-gnu/libGL*

И еще. А ты драйвера из репозиториев ставишь или с сайта nvidia тягаешь?

astra$ ls -l /usr/lib/x86_64-linux-gnu/libGL*
lrwxrwxrwx 1 root root      22 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLdispatch.so -> libGLdispatch.so.0.0.0
lrwxrwxrwx 1 root root      22 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
-rw-r--r-- 1 root root  612872 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0
lrwxrwxrwx 1 root root      30 май 27  2019 /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1 -> libGLESv1_CM_nvidia.so.390.116
-rw-r--r-- 1 root root   60200 янв 27  2019 /usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.390.116
lrwxrwxrwx 1 root root      27 май 27  2019 /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2 -> libGLESv2_nvidia.so.390.116
-rw-r--r-- 1 root root  111400 янв 27  2019 /usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.390.116
lrwxrwxrwx 1 root root      18 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      18 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.1.0
-rw-r--r-- 1 root root   76160 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root      19 сен 16  2016 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.13 -> libGLEWmx.so.1.13.0
-rw-r--r-- 1 root root  477296 сен 16  2016 /usr/lib/x86_64-linux-gnu/libGLEWmx.so.1.13.0
lrwxrwxrwx 1 root root      16 сен 18  2016 /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 -> libGLEW.so.2.0.0
-rw-r--r-- 1 root root  587888 сен 18  2016 /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0.0
lrwxrwxrwx 1 root root      14 май 30  2018 /usr/lib/x86_64-linux-gnu/libGL.so -> libGL.so.1.7.0
lrwxrwxrwx 1 root root      14 май 30  2018 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.7.0
-rw-r--r-- 1 root root  567688 май 30  2018 /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0
-rw-r--r-- 1 root root  905538 сен 13  2015 /usr/lib/x86_64-linux-gnu/libGLU.a
lrwxrwxrwx 1 root root      15 сен 13  2015 /usr/lib/x86_64-linux-gnu/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root      15 сен 13  2015 /usr/lib/x86_64-linux-gnu/libGLU.so.1 -> libGLU.so.1.3.1
-rw-r--r-- 1 root root  449328 сен 13  2015 /usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1
lrwxrwxrwx 1 root root      16 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 -> libGLX_mesa.so.0
lrwxrwxrwx 1 root root      20 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rw-r--r-- 1 root root  479968 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
lrwxrwxrwx 1 root root      24 май 27  2019 /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 -> libGLX_nvidia.so.390.116
-rw-r--r-- 1 root root 1268112 янв 27  2019 /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.390.116
lrwxrwxrwx 1 root root      15 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so -> libGLX.so.0.0.0
lrwxrwxrwx 1 root root      15 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so.0 -> libGLX.so.0.0.0
-rw-r--r-- 1 root root   72304 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0

astra$ apt list --installed|grep nvidia
libnvidia-common-390/stable,stable,now 390.116-0ubuntu1astra1.18.04.2 all [installed,automatic]
libnvidia-gl-390/stable,now 390.116-0ubuntu1astra1.18.04.2 amd64 [installed]

kubuntu$ apt list --installed|grep nvidia
libnvidia-cfg1-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-common-390/focal-updates,focal-updates,focal-security,focal-security,now 390.138-0ubuntu0.20.04.1 all [installed,automatic]
libnvidia-compute-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-decode-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-encode-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-fbc1-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-gl-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
libnvidia-ifr1-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-compute-utils-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-dkms-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-driver-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed]
nvidia-kernel-common-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-kernel-source-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-prime/focal,focal,now 0.8.14 all [installed,automatic]
nvidia-settings/focal-updates,now 440.82-0ubuntu0.20.04.1 amd64 [installed,automatic]
nvidia-utils-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]
xserver-xorg-video-nvidia-390/focal-updates,focal-security,now 390.138-0ubuntu0.20.04.1 amd64 [installed,automatic]

пакеты nvidia на обоих машинах из реп

отключение композита в «System Settings > Hardware > Display and Monitor > Compositor» ничего не изменило

Вот тут меня чуть-чуть смущает.

lrwxrwxrwx 1 root root      16 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 -> libGLX_mesa.so.0
lrwxrwxrwx 1 root root      20 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0

Новые драйвера NVIDIA уже используют GLVND и эту ссылку не ставят. А у тебя, скорее всего, драйвера, которые используют GLVND. По идее указание на Mesa тоже должно работать, но на сайте nvidia говорится:

(ссылка: https://forums.developer.nvidia.com/t/multiple-glx-client-libraries-in-the-nv...)

GLVND vendor implementation libraries provide the NVIDIA implementations of the various OpenGL functions supported by the NVIDIA driver. Each of these libraries requires a symbolic link named after its SONAME which points to the installed file, whose name includes the driver version number, which is represented below by the placeholder $VERSION:

[...]

libGLX_nvidia.so.$VERSION (SONAME libGLX_nvidia.so.0); for indirect GLX support, an additional symbolic link libGLX_indirect.so.0 must point to libGLX_nvidia.so.$VERSION.

Я сильно не уверен, что это чем-то поможет, но стоит попробовать.

сделал так:

astra$ ls -l /usr/lib/x86_64-linux-gnu/libGLX*
lrwxrwxrwx 1 root root      24 ноя  4 00:17 /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 -> libGLX_nvidia.so.390.116
lrwxrwxrwx 1 root root      20 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rw-r--r-- 1 root root  479968 июн 20  2018 /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
lrwxrwxrwx 1 root root      24 май 27  2019 /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0 -> libGLX_nvidia.so.390.116
-rw-r--r-- 1 root root 1268112 янв 27  2019 /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.390.116
lrwxrwxrwx 1 root root      15 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so -> libGLX.so.0.0.0
lrwxrwxrwx 1 root root      15 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so.0 -> libGLX.so.0.0.0
-rw-r--r-- 1 root root   72304 май 30  2018 /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0

но не помогло

У меня такое ощущение, что glxgears рисуются программным OpenGL и потом гонятся картинкой по обычному X11. FPS на fullscreen и обычном маленьком окне сильно различаются?

UPD: А что это за цифры, я так по тексту не понял. В kubuntu большой fps и не крутит, а в ubuntu в виртуалке 12 fps и крутит лучше? Сбой запуска GL приложения по ssh -X (комментарий)

большой fps, насколько я помню, это показатель какихто проблем (должно быть 60)
и да, FPS = 12 - плавнее чем дерганный 18192.564
при этом Xorg на kubuntu загружает одно ядро на 100%, а на astre скачет 0..12..20
в маленьком окне FPS = 31084.549, на весь экран FPS = 3122.492 (и еще медленнее)
видимо да, программно
второго компа с картой nvidia - нет

проверил в обратную сторону (с astra на kubuntu):
в маленьком окошке fps = 25, чем больше окно, тем fps падает и растет нагрузка на проц от ssh - на asta
при добавлении ключа -Y: fps стал 219, а на полном экране 18 нагрузка на ssh возросла и на kubuntu
т.е. в данную сторону проблем нет, но мне туда не надо )

Как вариант, можно, вместо запуска «иксов» по SSH, запускать «иксы» удалённо.

большой fps, насколько я помню, это показатель какихто проблем (должно быть 60)

Нет, в принципе, большой FPS на этом приложении и будет, если ты отключишь синхронизацию с vblank: в случае проприетарного Nvidia __GL_SYNC_TO_VBLANK=0 glxgears, а для остальных vblank_mode=0 glxgears. Если ты включаешь vblank, то у тебя всегда будет FPS около частоты монитора, то есть в твоем случае 60 FPS где-то. Ты, насколько я помню, отключил синхронизацию с vblank. Можешь у себя на локальной kubuntu проверить __GL_SYNC_TO_VBLANK=0 и __GL_SYNC_TO_VBLANK=1 и увидеть цифры.

$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
310 frames in 5.0 seconds = 61.829 FPS
301 frames in 5.0 seconds = 60.018 FPS
301 frames in 5.0 seconds = 60.019 FPS

да, верно, 60 fps при синхронизации:

kubuntu$ __GL_SYNC_TO_VBLANK=0 glxgears 
130600 frames in 5.0 seconds = 26119.875 FPS
129980 frames in 5.0 seconds = 25995.916 FPS
X connection to :0 broken (explicit kill or server shutdown).

kubuntu$ __GL_SYNC_TO_VBLANK=1 glxgears 
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
302 frames in 5.0 seconds = 60.314 FPS
300 frames in 5.0 seconds = 59.949 FPS
X connection to :0 broken (explicit kill or server shutdown).

Ну вот цифры, которые показывает glxgears через IGLX в kubuntu кажутся похожими, но вот почему-то вращение тормозит. Я вот думаю, почему это может быть. Может, из-за буферизации какой-то. Ведь запросы сначала в буфер попадают, а потом могут сброситься скопом на исполнение. Вполне мог бы быть такой эффект. Интересно поглядеть какие-то еще приложения.

но вот почему-то вращение тормозит.

оно даже не просто медленно идет, а периодически дергается

Интересно поглядеть какие-то еще приложения.

qtcreator тормозит даже на вводе символов

Вот интересное. Сообщают о таком же поведении и есть патч к glxgears[1]. И еще есть ссылка на такой же патч в mesa-dev [2]. Я посмотрел исходники glxgears в Debian Stable у себя. Этот патч не приложен. Так как он старый, то я полагаю, что он никуда в итоге не попал. Только я пока не могу сообразить, решит ли он как-то проблему с прерывистым вращением.

К патчу [2] можно прочесть комментарий. В [3] тоже говорится о такой ситуации. И в [1], [2] и [3] упоминается как раз буферизация. То есть получается, что кадры накапливаются, а потом разом на отрисовку и продвижение происходит практически мгновенно.

Я полагаю, что все же Indirect GLX у тебя заработал, но glxgears через IGLX оказались весьма специфичным случаем. Может, патч наложить?

[1] https://gitlab.freedesktop.org/mesa/demos/-/issues/11

[2] https://patchwork.freedesktop.org/patch/22951/

[3] https://www.mail-archive.com/search?l=cygwin-xfree@cygwin.com&q=date:2014...

qtcreator тормозит даже на вводе символов

А это приложение, которое использует GL или это чисто X-протокол? Это все же разные вещи. Скорее всего, там x11 backend.

А это приложение, которое использует GL или это чисто X-протокол

использует GL, без него и не запускалось

Может, патч наложить?

вау, оно завертелось !

user1@astra:~/src/mesa/mesa-demos-8.4.0/src/xdemos$ ./glxgears
9553 frames in 5.0 seconds = 1910.490 FPS
9428 frames in 5.0 seconds = 1885.432 FPS
9545 frames in 5.0 seconds = 1908.910 FPS
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server "astra:10.0"
      after 88348 requests (88348 known processed) with 0 events remaining.

хм, получается чтобы qtcreator работал - нужно патчить Qt или писать багрепорт ?

использует GL, без него и не запускалось

Запусти с бекендом x11 и сравни. Я что-то пока сомневаюсь насчет Indirect GLX и приложения на Qt5 с движком OpenGL. Какие там минимальные требования к OpenGL?

Запусти удаленно (вроде этой переменной выбирается)

QT_QPA_PLATFORM=xcb  qtcreator

на данный момент мне помог ключ -C - стало заметно живее, вне зависимости от QT_QPA_PLATFORM (иначе даже ввод символов и перевод строки неприятно тормозит)
пока так и оставлю, а потом попробую примеры qt opengl - посмотрю как они двигаются

Ох уж эта хвалёная сетевая прозрачность иксов.

И, конечно, спасибо за помощь ! Я узнал чтото новое )