I did some further research, and I believe that the underlying problem is the same as the one experienced by AMDGPU users (but I can't yet confirm that, because I haven't been able to make Nouveau work with my Quadro 600.) According to the GLX API, any value specified for GLX_[RED|GREEN|BLUE|ALPHA]_SIZE in glXChooseVisual() or glXChooseFBConfig() is treated as a minimum value, and visuals or FB configs with larger red/green/blue/alpha component sizes are preferred. AMDGPU and Nouveau both place 10-bpc FB configs at the head of the list, so when an application specifies GLX_RED_SIZE=GLX_GREEN_SIZE=GLX_BLUE_SIZE=8 and VirtualGL passes those values to the "real" glXChooseFBConfig() function, 10-bpc FB configs are returned first. Those FB configs do not support window rendering and do not have visuals attached, so 3D applications (including GLXspheres) that specify GLX_VISUAL_TYPE=... or GLX_DRAWABLE_TYPE=GLX_WINDOW_BIT|... (the default value of GLX_DRAWABLE_TYPE is GLX_WINDOW_BIT) with glXChooseFBConfig() will exclude the 10-bpc FB configs. However, VirtualGL specifies GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT|GLX_PIXMAP_BIT because VirtualGL never actually renders into a window. Technically speaking, the underlying GLX implementation should never set GLX_PIXMAP_BIT for a FB config without also setting GLX_WINDOW_BIT (glXCreatePixmap() should throw BadMatch if the FB config passed to it doesn't have GLX_WINDOW_BIT set), and GLX_PIXMAP_BIT should never be set for an FB config without an attached visual. However, unfortunately AMDGPU (and presumably Nouveau) do this for the aforementioned 10-bpc FB configs. The issue is with 3D applications (including GLXgears) that use glXChooseVisual(), because VirtualGL's implementation of glXChooseVisual() chose the first FB config returned by the "real" glXChooseConfig() function. Modifying our implementation of glXChooseVisual() so that it chooses the first FB config **with a visual attached** returned by the "real" glXChooseFBConfig() function works around the problem, at least with the AMDGPU drivers. If you or someone else could confirm, using the latest 2.6.x stable pre-release build (I just pushed, so give it a few minutes to spin), that the problem is also worked around for Nouveau, I would appreciate it.
DRC On 9/21/20 1:32 PM, zoidby wrote: > You were right, this seems nouveau related. I switched to the official > nvidia driver and it is working. > > But i am not sure if VGL_FORCEALPHA=1 would have fixed this. I > remember trying that without success when i used nouveau since it was > suggested here: > https://wiki.archlinux.org/index.php/VirtualGL#Problem:_rendering_glitches,_unusually_poor_performance,_or_application_errors > > But i could be wrong. > > Thank you! > On Monday, 21 September 2020 at 03:35:04 UTC+2 DRC wrote: > > That error probably means that the driver (nouveau?) places 10-bpc > GLXFBConfigs at the head of the list. AMDGPU does that, too. I > have a workaround for that issue but was waiting until other > AMDGPU issues were resolved by AMD. In the meantime, try setting > VGL_FORCEALPHA=1 to encourage VGL to use an 8-bpc GLXFBConfig. > >> On Sep 20, 2020, at 9:03 AM, zoidby <[email protected]> wrote: >> >> Hi >> >> >> When i run glxgears, i get this error: >> >> > vglrun glxgears >> [VGL] NOTICE: Automatically setting VGL_CLIENT environment >> variable to >> [VGL] 10.0.0.3, the IP address of your SSH client. >> [VGL] ERROR: in sendVGL-- >> [VGL] 477: The VGL Transport requires 8 bits per component >> >> >> But glxspheres64 works: >> >> > vglrun glxspheres64 >> [VGL] NOTICE: Automatically setting VGL_CLIENT environment >> variable to >> [VGL] 10.0.0.3, the IP address of your SSH client. >> Polygons in scene: 62464 (61 spheres * 1024 polys/spheres) >> GLX FB config ID of window: 0xb5 (8/8/8/8) >> Visual ID of window: 0x20 >> Context is Direct >> OpenGL Renderer: NV106 >> 101.623796 frames/sec - 113.412157 Mpixels/sec >> 101.201136 frames/sec - 112.940467 Mpixels/sec >> 101.317899 frames/sec - 113.070776 Mpixels/sec >> 101.085025 frames/sec - 112.810888 Mpixels/sec >> >> >> The same goes for other programs. Warsow works, quake3 does not. >> -- >> You received this message because you are subscribed to the >> Google Groups "VirtualGL User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> To view this discussion on the web visit >> >> https://groups.google.com/d/msgid/virtualgl-users/3acaec31-c5a3-4f40-849f-37041cbc36aan%40googlegroups.com >> >> <https://groups.google.com/d/msgid/virtualgl-users/3acaec31-c5a3-4f40-849f-37041cbc36aan%40googlegroups.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google > Groups "VirtualGL User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/fac16ad5-f699-48c8-9ade-654e736f8bc5n%40googlegroups.com > <https://groups.google.com/d/msgid/virtualgl-users/fac16ad5-f699-48c8-9ade-654e736f8bc5n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/26c8e886-681b-8dbf-1ee2-f60adfd7f968%40virtualgl.org.
