[FreeNX-kNX] Forcing the graphical applications to use the server-side graphics abilities

[Mario Becroft]

Prakash Velayutham <prakash.velayutham at cchmc.org> writes:

> These are my experimental numbers.
>
> Client X (using NoMachine client)
> FreeNX server Y
> Graphics node Z
>
> I connect via the NX client from X to Y (using SSH tunneling and X  
> proxy)
> I then SSH -X to the graphics node (this is needed in my setting as  
> the graphics node Z is in a private network reachable only from Y)
> Then I startup Matlab on the node. This, if I am correct, streams all  
> the OpenGL rendering commands through the tunnel back to my client and  
> uses the client-side X (which is the X server here) to render it. And,  
> by the very definition, this cannot use hardware acceleration as it  
> can only do indirect rendering. My Matlab startup time, as I see it,  
> is about 27 seconds in this case.

If you were directly running X protocol without using NX, or using
nxproxy without nxagent, this would be at least partly true. The GL
commands would be sent via GLX protocol to the X server, which, as I
understand it, should still be able to use the accelerated graphics
hardware to do rendering if it wants to. However, in practice the
performance can be very poor. I am hazy on the details of direct
vs. indirect rendering in GLX, so I may not be quite right about this.

However, if you are using nxagent, which is the usual way NX is used
since it provides round-trip suppression, then this will not be the
case, since nxagent does not support forwarding GLX requests (as far as
I know).

> What I have read thus far says that a VNC connection renders the  
> graphics on the application side, instead of the interaction side. So,  
> if, after connecting to node Z, I start up a VNC server on, say  
> display 1, and then connect to Z from Y using a VNC viewer, and start  
> up Matlab, the startup time, is about 10 seconds.

Yes, if you use ordinary VNC, then the Mesa software renderer built into
Xvnc will do the GL rendering, and bitmap data (compressed using normal
VNC protocols) will be sent to the VNC client.

Where something like VirtualGL comes in is that it enables the graphics
rendering to be done on OpenGL hardware other than the video hardware
the VNC client is displaying on. Typically this is used to do rendering
on a host close to the one running the GLX client (possibly the same
host), while sending the resulting images through VNC or NX protocol to
a remote host. The remote host need not have accelerated graphics
hardware.

Assuming you were using nxagent in your NX test, it is not clear to me
why there is a performance difference between NX and VNC in this
case. Maybe you were not using an nxagent session, and your GLX commands
were being sent all the way to the NX client.

> I am trying to understand which is the best way to extract the
> rendering power of the graphics node and still get the best
> interactive experience using NX.

Assuming you are using nxagent, which does not forward GLX to the remote
X server, your options are twofold:

1. use NX in the normal way. Rendering for GLX clients will be done by
the Mesa library in the nxagent running on the nxagent host's CPU.

2. use NX in combination with VirtualGL or similar, and configure
VirtualGL to use a video adapter locally attached to the host running
nxagent (or possibly another host on a fast LAN).

In both cases, the rendering is done on the server side of the NX
connection and the resulting images are sent to the client using normal
NX image compression. 1. will be slow since the rendering is done on the
host's general-purpose CPU. 2. will be much faster since rendering is
done on accelerated graphics hardware.

There is actually a third way: if you link your GLX-using client against
Mesa, then the client can do all the rendering itself and just send
images to the X server. If the X client and the nxagent are running on
the same host, the end-result of this will be much the same as 1.

Whether you need to use hardware acceleration or software rendering will
be sufficient depends on the type and amount of rendering work being
done.

-- 
Mario Becroft <mb at gem.win.co.nz>