[FreeNX-kNX] NX performance issue

[Fabian Franz]

> I did give that a try, but there are two issues with the approach in
> general.  The first is that it forces the application to use an indirect
> GLX
> context (all of the OpenGL commands have to be sent over a local socket to
> nxagent -- they can't be sent directly down to the 3D hardware.) 

Ah, I do understand.

> One of
> the
> benefits of using VirtualGL is that, since it redirects the GLX commands
> in-process, it can establish a direct rendering context with the 3D
> hardware.  

Sure.

>Many features of OpenGL don't work with indirect contexts. 
> When
> you use indirect contexts, you're limited to using only the subset of
> OpenGL
> that is supported by the X server (Mesa, in this case.)  The second issue
> is
> that VirtualGL has to monitor a handful of X11 commands from the
> application
> to determine when window resize events have occurred so it can know when
> to
> resize the Pbuffer associated with that window.  So VGL has to be
> preloaded
> into the application process in order to perform this monitoring.

Okay.

> One idea that we're investigating is adding a compressed PutImage()
> extension to the NX agent, so VirtualGL could do the image compression
> itself and NX could hand off the pre-compressed images to the proxy (via.
> NXPutPackedImage().) 

Ah, I see. Then you could also set the glxtrap in that extension ...

> Since VGL only does JPEG and raw RGB encoding
> anyhow,
> the NX client already knows how to decode those formats without any
> additional modification. 

Sure.

> But before I go to the trouble of implementing
> the
> X extension, I wanted to make sure that the system could deliver the
> compressed images fast enough -- which is why I'm doing these initial
> experiments.

Ah, I see.

> I've added the same TurboJPEG codec to NX that I added to TurboVNC, which
> improves the JPEG encoding/decoding speed by about 3X vs. the plain
> libjpeg
> codec. 

Yeah, I saw it. That is really pretty cool speedup.

> But in the case of NX, the performance issue described above is
> limiting the frame rate to about 30-50% of what TurboVNC can achieve, even
> though they're now using the same accelerated codec.  I think that if I
> can
> work past this performance issue, I can make NX perform at least as fast
> as
> TurboVNC.  There's no theoretical reason why it shouldn't.

Sounds really great. As far as I've seen including TurboJPEG could in general be helpful for NX or not?

There are two things you can try:

- Start nxagent directly and not via proxy like:

local $ ssh -X user at remote
remote $ LD_LIBRARY_PATH=/usr/NX/lib/ /usr/NX/bin/nxagent :1 &
remote $ DISPLAY=:1 vgl glxgears

If it has the same performance issues, problem is in nxagent and the idea of the trap could help ...

- Connect two nxproxies directly together, like:

remote $ LD_LIBRARY_PATH=/usr/NX/lib DISPLAY="nx/nx,opt=foo:1" /usr/NX/bin/nxagent -B :1

local $ LD_LIBRARY_PATH=/usr/NX/lib/ /usr/NX/bin/nxproxy -S remote:1

remote $ DISPLAY=:1 vgl glxgears

Perhaps that helps finding _where_ exactly the problem is ...

(nxproxy can be build quite easy by building first nxcomp then nxproxy, if you don't have it ...)

A last idea would be to always set glxtrap=1 in nxagent and see what it does.

cu

Fabian