Support for amdgpu

[MartinLB]

Hello,
   I'm new to VirtualGL, and trying to get it to work with an AMD Radeon Vega M.   Looking through the server config files for VGL server, I see lots of options for for NVIDIA modules, but nothing related to the amdgpu drivers.   Has anyone had any luck with using VGL with amdgpu? 
Thanks in advance,
Martin

[MartinLB]

Hi Everyone,

   Follow up: Using a search for Radeon (as opposed to amdgpu) I found the solution here: https://groups.google.com/d/topic/virtualgl-users/TbMAhKq84yw/discussion

   Exporting VGL_DRAWABLE=pixmap before running vglrun is necessary, but I can attest that I am getting very good performance with a Radeon RX Vega M.

Thank you everyone for your support.
-Martin

[DRC]

Ugh. I noticed that AMD has new drivers that might actually support my
old FirePro card, so I'll give those a try and see if I can reproduce
the Pbuffer issue (I also have a Mobile Radeon that might reproduce it.)
I struggle to believe that any modern GPU would truly lack Pbuffer
support. Back in the day, the fglrx drivers did some funky things,
though, like supporting Pbuffers but not exporting the
glXCreatePbuffer() function from libGL, so you had to use
glXGetProcAddress() to load the symbol for that function before you
could call it. At this point, given that VirtualGL has existed for 15
years and is at the heart of a bunch of commercial remote desktop
solutions for Linux, I don't think it's too much to ask that both nVidia
and AMD test VGL against their Linux drivers and report any issues to me.

DRC

[DRC]

Unfortunately no dice. The latest driver available to my Mobile Radeon
is still the old Catalyst 15.9 proprietary driver, and the latest driver
available to my FirePro V5700 is v8.911.3.4 from 2012. I tested the
former and can't reproduce any issues with glXCreatePbuffer(), so this
appears to be specific to the amdgpu driver, which I unfortunately have
no ability to test. Referring to
https://github.com/VirtualGL/virtualgl/issues/93, the issue was also
observed with an AMD A10-7860 APU. The driver appears to be exporting
GLXFBConfigs that support Pbuffers. It simply isn't handling the
glXCreatePbuffer() X11 request properly.

If someone wants to provide me temporary SSH access to a machine that
demonstrates the problem, I can try to diagnose it remotely. The
machine would need to have a 64-bit VirtualGL build environment and
TurboVNC installed.

[Richard]

> --
> 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/37765144-e387-eb7e-c29b-28c33615afbf%40virtualgl.org.
> For more options, visit https://groups.google.com/d/optout.

I have a system I would be happy for you to play on. At the moment I
have only a sacrificial user account and a ssh key set but give me a
couple of days to get TurboVNC built and tested (I use X2Go) and I can
send you the connection information and public key.

This is the A10-7860 system currently running kernel 4.20 amdgpu driver
and Mesa 19.0 rc something. I have built VGL from git on this box and I
don't think it will be too hard to do the same for TurboVNC.

The OS is Mageia 7 Cauldron which is currently a beta release and will
be updated daily. This shouldn't be a problem but it may get several
kernel and mesa updates over the next week or so... oh, and I am on GMT+0

--
Richard <richard....@ntlworld.com>

[DRC]

On 2/14/19 1:49 PM, 'Richard' via VirtualGL User Discussion/Support wrote:
> I have a system I would be happy for you to play on. At the moment I
> have only a sacrificial user account and a ssh key set but give me a
> couple of days to get TurboVNC built and tested (I use X2Go) and I can
> send you the connection information and public key.
>
> This is the A10-7860 system currently running kernel 4.20 amdgpu driver
> and Mesa 19.0 rc something. I have built VGL from git on this box and I
> don't think it will be too hard to do the same for TurboVNC.
>
> The OS is Mageia 7 Cauldron which is currently a beta release and will
> be updated daily. This shouldn't be a problem but it may get several
> kernel and mesa updates over the next week or so... oh, and I am on GMT+0

You don't need to build TurboVNC from source, since I only need TurboVNC
for access purposes. Just download the pre-built RPM for 2.2.1
(https://sourceforge.net/projects/turbovnc/files/2.2.1) and install it.
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. :)

I will e-mail you an SSH public key off-list.

[Richard]

> --

Glad I can use the RH rpm otherwise I might have had to build turbojpeg too and it has been many a long year since I last wrestled with Java SDKs.

OK, the TVNC rpm is installed but not yet configured - still reading the docs.

I'll have an IP address and ssh port for you when required.
--
Richard <richard....@ntlworld.com>

[DRC]

On 2/15/19 3:05 PM, 'Richard' via VirtualGL User Discussion/Support wrote:
> Glad I can use the RH rpm otherwise I might have had to build turbojpeg too and it has been many a long year since I last wrestled with Java SDKs.
>
> OK, the TVNC rpm is installed but not yet configured - still reading the docs.
>
> I'll have an IP address and ssh port for you when required.

No configuration should be necessary. I can configure it through SSH
once I log in. Also, even if you had had to build TurboVNC from source,
Java is not required in order to build just the server.

[Richard]

On Fri, 15 Feb 2019 13:48:33 -0600
DRC <d...@virtualgl.org> 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 <richard....@ntlworld.com>

[DRC]

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.

[Richard]

On Fri, 15 Feb 2019 18:30:02 -0600
DRC <d...@virtualgl.org> 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 <d...@virtualgl.org> 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 <richard....@ntlworld.com>

[Martin Lueker]

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

--
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/20190216174525.eebde56fe5517bc83270ea9c%40ntlworld.com.

[DRC]

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 <virtual...@googlegroups.com

> <mailto:richard....@ntlworld.com>>

>
> --
> 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

> <mailto:virtualgl-users%2Bunsu...@googlegroups.com>.

> 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 virtualgl-use...@googlegroups.com

> <mailto:virtualgl-use...@googlegroups.com>.

> 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>.