VGL_FORCEALPHA only affects the underlying pixel readback methods, so it shouldn't matter which transport is in use. Regardless, however, that should be seen as a workaround necessitated by a bug in the amdgpu driver, and I would recommend that anyone who is a paying AMD GPU customer file a support request with them to fix the issue.
On 3/13/19 2:03 PM, Martin Lueker wrote: > DRC, Richard, > Just a delayed followup: > Thank you both so much! Your assistance on this has been marvelous, > and your analysis of the 32-bit PBuffer issue has been so > interesting. I gave your solution a try with VGL_FORCEALPHA=1, and > after trying a few other tranport options (As far as I can tell this > only works with, the proxy transport), it does seem to work amazingly well. > > Thanks again for your help! > Martin > > > On Sat, Feb 16, 2019 at 9:45 AM 'Richard' via VirtualGL User > Discussion/Support <[email protected] > <mailto:[email protected]>> wrote: > > On Fri, 15 Feb 2019 18:30:02 -0600 > DRC <[email protected] <mailto:[email protected]>> wrote: > > > Thanks for giving me access to poke around. The conclusion is: the > > Pbuffer implementation in the amdgpu driver you're using is > resoundingly > > broken and not at all compliant with the GLX specification. However, > > fortunately there's a better workaround than using Pixmaps. It seems > > that setting VGL_FORCEALPHA=1 in the environment is the magic formula. > > That forces VirtualGL to return only 32-bit (alpha-channel-enabled) > > visuals and GLXFBConfigs to the application, as well as to use only > > 32-bit GLXFBConfigs when creating its own Pbuffers. So the underlying > > issue seems to be that amdgpu doesn't handle 24-bit Pbuffers. > > > > I ran some comparative timing tests to assess the impact of the > VGL_FORCEALPHA workaround and I am very happy. The four tests were all > run on the same hardware using the glxspheres64 program. > > Two tests were run on Mageia 6 which was the last system I had with a > fully functional VGL and Mesa implementation (virtualgl-2.5.2). This > system can use either default pbuffers or the forced alpha version. > There was no meaningful difference in the average fps achieved: 141 Two > more tests were run in Mageia 7 beta 1 "Cauldron". This system has to > use the forced alpha switch in order to work and the tests were run > using two versions of the amdgpu kernel driver. > > The first version was the same as that used in Mageia 6 thanks to a > re-compiled kernel 4.14.89 and the second tested used the current > Cauldron kernel 4.20.9. The speed difference is small but significant. > The old Mageia 6 kernel produced an average result of 158 fps and the > current kernel gave 161 fps. > > I conclude that AMD devs are doing a great job of improving their > drivers' efficiency; both kernel amdgpu and Mesa radeonsi and there is > no performance hit from having to use 32 bit buffers rather than 24 bit > in VirtualGL. Now all I have to get them to do is fix the pbuffer > implementation! :~) > > I have attached a CSV file of the simple results table. > > > On 2/15/19 3:44 PM, 'Richard' via VirtualGL User > Discussion/Support wrote: > > > On Fri, 15 Feb 2019 13:48:33 -0600 > > > DRC <[email protected] <mailto:[email protected]>> wrote: > > > > > >> You could actually do that for VGL as well, but it's useful to > make sure > > >> you can build VGL so I'll be able to do likewise. :) > > > > > > Last night's VGL git clone has just compiled with no issues and all > > > options left at the defaults. The installed version is > > > virtualgl-2.6.1-4.mga7 from 6 Jan 2019. > > > > > > Would you like it out of the way or can you run test builds with > it in > > > place? > > > > > > I have also installed debug-info and debug-source rpms for VGL, GL, > > > GLU, Mesa in case you might find these useful. > > > > -- > > > -- > Richard <[email protected] > <mailto:[email protected]>> > > -- > 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:virtualgl-users%[email protected]>. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/virtualgl-users/20190216174525.eebde56fe5517bc83270ea9c%40ntlworld.com. > For more options, visit https://groups.google.com/d/optout. > > -- > 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/CAOMX8tNhUCrV1FC3PC1smEF%3D8Py0CSLTT9kEGbtaOt47TbpHYg%40mail.gmail.com > <https://groups.google.com/d/msgid/virtualgl-users/CAOMX8tNhUCrV1FC3PC1smEF%3D8Py0CSLTT9kEGbtaOt47TbpHYg%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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/cec791bf-3dc9-514e-51dc-651455e0fbd5%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
