glxspheres64 works, but glxgears does not

[zoidby]

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.

[DRC]

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 <b4kuret5...@gmail.com> wrote:

Hi

--
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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/3acaec31-c5a3-4f40-849f-37041cbc36aan%40googlegroups.com.

[zoidby]

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!

[DRC]

It might not have, because some of the 10-bpc FB configs have alpha as well. 

On Sep 21, 2020, at 12:32 PM, zoidby <b4kuret5...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/fac16ad5-f699-48c8-9ade-654e736f8bc5n%40googlegroups.com.

[DRC]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/fac16ad5-f699-48c8-9ade-654e736f8bc5n%40googlegroups.com.

[DRC]

Can you confirm whether the latest stable pre-release build fixes the issue with nouveau?

On 9/21/20 1:32 PM, zoidby wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/fac16ad5-f699-48c8-9ade-654e736f8bc5n%40googlegroups.com.

[zoidby]

First of all, sorry that it took me so long to reply. I tried testing your changes earlier but the git-package from the Arch User Repository wouldn’t build on my system. I’ve created my own package now and got it to build. I also had to revert back to nouveau which contributed to this not being done quicker.

But i can report that your changes work!

To check if the error was still there i’ve reverted to nouveau and used the original package provided by my distribution. Error was still there.

Then i replaced the original virtualgl package with my own -git package and the error is gone. glxgears works now.

Thank you for this fix! And sorry again, that i keept you waiting this long.

[DRC]

Thanks for testing!

On Oct 17, 2020, at 12:38 PM, zoidby <b4kuret5...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/d78958fb-c922-489c-b1fc-58575fdc539dn%40googlegroups.com.