CUDA error - cudaGraphicsGLRegisterBuffer

[dave]

I'm trying to run one of the NVidia CUDA sample programs on an application server and view it in vncviewer.

I start the vnc servine in one ssh session:

$ /opt/TurboVNC/bin/vncserver

and in another run the application but get the following error:

$ vglrun -d :1 ./particles

CUDA Particles Simulation Starting...

grid: 64 x 64 x 64 = 262144 cells
particles: 16384
GPU Device 0: "GeForce RTX 2080 Ti" with compute capability 7.5

CUDA error at particleSystem_cuda.cu:79 code=30(cudaErrorUnknown) "cudaGraphicsGLRegisterBuffer(cuda_vbo_resource, vbo, cudaGraphicsMapFlagsNone)"

Any tips on how to progress?

Thanks, Dave

[DRC]

I’ll try to repro it. It may require a similar fix to the one I made in 2.6.3 to support OpenGL/OpenCL interoperability.

--
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/09ad303d-2dd5-4143-a7e7-c67072afb9b0%40googlegroups.com.

[dave-ms]

Through a bit of trial and error I think I've got it working in both Direct and Raw modes.

Using vglclient:

client> vglclient &
client> ssh -X <server>
server> export VGL_CLIENT=<client_ip>:0.0
server> vglrun -d :1 /opt/VirtualGL/bin/glxspheres64


This is on Ubuntu 18.04 which seems to create two displays when logged in on the server (one for gdm and one for the desktop).

Using vncserver:

server> /opt/TurboVNC/bin/vncserver
Desktop 'TurboVNC: server:2 (dave)' started on display server:2
client> /opt/TurboVNC/bin/vncviewer server:2 &
client> ssh server
server> DISPLAY=:2 vglrun -d :1 /opt/VirtualGL/bin/glxspheres64
Polygons in scene: 62464
Visual ID of window: 0xad
Context is Direct
OpenGL Renderer: GeForce RTX 2080


App is rendering in the vnc window on the client so I think I'm good.

Just to check,is it correct to use "ssh server" (no "-X") to hop to the server to launch applications (in this case)?

Thanks,

Dave.

On Friday, November 15, 2019 at 3:47:01 PM UTC+11, DRC wrote:

I’ll try to repro it. It may require a similar fix to the one I made in 2.6.3 to support OpenGL/OpenCL interoperability.

On Nov 14, 2019, at 7:54 PM, dave <davi...@gmail.com> wrote:

I'm trying to run one of the NVidia CUDA sample programs on an application server and view it in vncviewer.

I start the vnc servine in one ssh session:

$ /opt/TurboVNC/bin/vncserver

and in another run the application but get the following error:

$ vglrun -d :1 ./particles

CUDA Particles Simulation Starting...

grid: 64 x 64 x 64 = 262144 cells
particles: 16384
GPU Device 0: "GeForce RTX 2080 Ti" with compute capability 7.5

CUDA error at particleSystem_cuda.cu:79 code=30(cudaErrorUnknown) "cudaGraphicsGLRegisterBuffer(cuda_vbo_resource, vbo, cudaGraphicsMapFlagsNone)"

Any tips on how to progress?

Thanks, Dave

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

[DRC]

On Nov 19, 2019, at 8:36 PM, dave-ms <dave.j...@missionsystems.com.au> wrote:

Through a bit of trial and error I think I've got it working in both Direct and Raw modes.

OK, so the problem was not related to CUDA?

Using vglclient:

client> vglclient &
client> ssh -X <server>
server> export VGL_CLIENT=<client_ip>:0.0
server> vglrun -d :1 /opt/VirtualGL/bin/glxspheres64


This is on Ubuntu 18.04 which seems to create two displays when logged in on the server (one for gdm and one for the desktop).

It does that because Wayland is enabled. Recent versions of vglserver_config disable Wayland logins in GDM for that reason. Otherwise, if GDM is running in Wayland mode, the GDM scripts that vglserver_config modifies in order to grant users access to the 3D X server are never executed. Regardless, logging in locally when using the 3D X server for VirtualGL is not supported. When you log out, the X server will reset, which would have the effect of aborting every 3D application currently running with VirtualGL. All the more reason why I’m trying desperately to develop an EGL back end, but unfortunately it has turned into more of a 300-hour project than the 50-hour project I originally envisioned, and there will be some compatibility limitations to that back end once it is finished.

Using vncserver:

server> /opt/TurboVNC/bin/vncserver
Desktop 'TurboVNC: server:2 (dave)' started on display server:2
client> /opt/TurboVNC/bin/vncviewer server:2 &
client> ssh server
server> DISPLAY=:2 vglrun -d :1 /opt/VirtualGL/bin/glxspheres64
Polygons in scene: 62464
Visual ID of window: 0xad
Context is Direct
OpenGL Renderer: GeForce RTX 2080


App is rendering in the vnc window on the client so I think I'm good.

Just to check,is it correct to use "ssh server" (no "-X") to hop to the server to launch applications (in this case)?

Yes. -X is never needed with the official VirtualGL launch procedures. If you’re using the VGL Transport (which hasn’t been called “Direct Mode” for many years), then vglconnect will automatically enable X11 forwarding in the SSH connection (which is what -X does.) If you’re using the X11 Transport with an X proxy, then X11 forwarding is not needed.

Thanks,

Dave.

On Friday, November 15, 2019 at 3:47:01 PM UTC+11, DRC wrote:

I’ll try to repro it. It may require a similar fix to the one I made in 2.6.3 to support OpenGL/OpenCL interoperability.

On Nov 14, 2019, at 7:54 PM, dave <davi...@gmail.com> wrote:

I'm trying to run one of the NVidia CUDA sample programs on an application server and view it in vncviewer.

I start the vnc servine in one ssh session:

$ /opt/TurboVNC/bin/vncserver

and in another run the application but get the following error:

$ vglrun -d :1 ./particles

CUDA Particles Simulation Starting...

grid: 64 x 64 x 64 = 262144 cells
particles: 16384
GPU Device 0: "GeForce RTX 2080 Ti" with compute capability 7.5

CUDA error at particleSystem_cuda.cu:79 code=30(cudaErrorUnknown) "cudaGraphicsGLRegisterBuffer(cuda_vbo_resource, vbo, cudaGraphicsMapFlagsNone)"

Any tips on how to progress?

Thanks, Dave

--
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 virtual...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/09ad303d-2dd5-4143-a7e7-c67072afb9b0%40googlegroups.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/cd08376b-22e1-4ae6-8a13-672517ed859a%40googlegroups.com.

[DRC]

I wonder aloud whether you’re using an antiquated version of VGL, which would explain both your use of antiquated VGL terminology as well as why it isn’t working properly on Ubuntu 18.04.

[Dave Jennings]

On 20/11/19 5:04 pm, DRC wrote:

On Nov 19, 2019, at 8:36 PM, dave-ms <dave.j...@missionsystems.com.au> wrote:

Through a bit of trial and error I think I've got it working in both Direct and Raw modes.

OK, so the problem was not related to CUDA?

It would appear so, although I think I'm not at the bottom of it yet, just didn't want you wasting time on a red herring.

One difference is that last week I was working remotely, so my workstation (with the GPU) was sitting at the login window in the office. This week I am in the office with a laptop (client) next to the workstation (GPU) so the workstation is logged in to a desktop. I presume this means the displays change number (0 -> 1) as well as probably changing some authentication issues (since I'm targetting the desktop display - vglrun -d :1).

Using vglclient:

client> vglclient & client> ssh -X <server> server> export VGL_CLIENT=<client_ip>:0.0 server> vglrun -d :1 /opt/VirtualGL/bin/glxspheres64

This is on Ubuntu 18.04 which seems to create two displays when logged in on the server (one for gdm and one for the desktop).

It does that because Wayland is enabled. Recent versions of vglserver_config disable Wayland logins in GDM for that reason. Otherwise, if GDM is running in Wayland mode, the GDM scripts that vglserver_config modifies in order to grant users access to the 3D X server are never executed. Regardless, logging in locally when using the 3D X server for VirtualGL is not supported. When you log out, the X server will reset, which would have the effect of aborting every 3D application currently running with VirtualGL. All the more reason why I’m trying desperately to develop an EGL back end, but unfortunately it has turned into more of a 300-hour project than the 50-hour project I originally envisioned, and there will be some compatibility limitations to that back end once it is finished.

So best (only?) practice is to have a workstation booted to the login screen and use that display (:0) for vglrun.

Using vncserver:

server> /opt/TurboVNC/bin/vncserver
Desktop 'TurboVNC: server:2 (dave)' started on display server:2
client> /opt/TurboVNC/bin/vncviewer server:2 &
client> ssh server
server> DISPLAY=:2 vglrun -d :1 /opt/VirtualGL/bin/glxspheres64
Polygons in scene: 62464
Visual ID of window: 0xad
Context is Direct
OpenGL Renderer: GeForce RTX 2080


App is rendering in the vnc window on the client so I think I'm good.

Just to check,is it correct to use "ssh server" (no "-X") to hop to the server to launch applications (in this case)?

Yes. -X is never needed with the official VirtualGL launch procedures. If you’re using the VGL Transport (which hasn’t been called “Direct Mode” for many years), then vglconnect will automatically enable X11 forwarding in the SSH connection (which is what -X does.) If you’re using the X11 Transport with an X proxy, then X11 forwarding is not needed.

Thanks. I got the "Direct Mode" terminology from here: https://virtualgl.org/vgldoc/2_0/#hd007. I now see that there's a link to the up-to-date docs on the virtualgl.org page. If I can make a suggestion, it wasn't clear that the Documentation header in the left-hand sidebar was a link, I thought it was just a header (like About VirtualGL) with only two documents in that section. Perhaps make it a plain header and have a link below. I ended up in the old docs via google search, having looked for the official docs on the main page and failing to find them.

So vncserver and vncviewer use VGL Transport, and vglconnect is used implicitly (I'm not explicitly running that anywhere). Is that correct?

And, to get my terminology and understanding right, vncserver is an X proxy, correct?

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/339C09E1-21DB-427C-939B-51B4455BA221%40virtualgl.org.

[Dave Jennings]

I'm using VirtualGL 2.6.3 and TurboVNC 2.2.3, both from Sourceforge.

I presume you mean "Direct Mode" as antiquated terminology. As mentioned in the other post it looks like I got that from old docs (now fixed on my side).

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/0DDE072B-23CA-4725-955F-5D51598720A4%40virtualgl.org.

[DRC]

It would appear so, although I think I'm not at the bottom of it yet, just didn't want you wasting time on a red herring.

One difference is that last week I was working remotely, so my workstation (with the GPU) was sitting at the login window in the office. This week I am in the office with a laptop (client) next to the workstation (GPU) so the workstation is logged in to a desktop. I presume this means the displays change number (0 -> 1) as well as probably changing some authentication issues (since I'm targetting the desktop display - vglrun -d :1).

It shouldn’t be doing that if vglserver_config from VGL 2.6.2 or later was used.

So best (only?) practice is to have a workstation booted to the login screen and use that display (:0) for vglrun.

When using a 3D X server, yes.

Thanks. I got the "Direct Mode" terminology from here: https://virtualgl.org/vgldoc/2_0/#hd007. I now see that there's a link to the up-to-date docs on the virtualgl.org page. If I can make a suggestion, it wasn't clear that the Documentation header in the left-hand sidebar was a link, I thought it was just a header (like About VirtualGL) with only two documents in that section.

I specifically changed the CSS some time ago so that the Documentation link is underlined and appears in a different color. Also, the documentation is installed whenever you install a VirtualGL package. I strive to make everything as easy to understand as possible, but I can’t make everything immediately intuitive to everyone, because everyone’s knowledge and experience is different.

Perhaps make it a plain header and have a link below. I ended up in the old docs via google search, having looked for the official docs on the main page and failing to find them.

So vncserver and vncviewer use VGL Transport, and vglconnect is used implicitly (I'm not explicitly running that anywhere). Is that correct?

No. TurboVNC does not use the VGL Transport at all. It has its own image transport mechanism (as do other X proxies.) When used with an X proxy, VGL just draws the rendered frames into the X proxy using XShmPutImage() and lets the X proxy take care of delivering those pixels to the client.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/ada8483e-4d2f-3464-8241-7316625cf412%40missionsystems.com.au.