| |||||||||||||
Bad and complex architectureBad and complex architecturePosted Jul 26, 2009 8:30 UTC (Sun) by tialaramex (subscriber, #21167)In reply to: Bad and complex architecture by astrand Parent article: Google releases Neatx NX server
How can X possibly lose for OpenGL ? You know that OpenGL is network transparent on X right?
Years ago I watched someone play my copy of GLQuake from their machine over GLX quite comfortably. It wasn't quite as fast as a local copy of the game, but it was very playable. The VNC solution, in addition to chewing all the CPU on both machines and _still_ requiring a fast OpenGL implementation on the machine running the game, would have also chewed up all the network bandwidth, and I'm not convinced it would even have been playable.
My own OpenGL software is much less pretty than Quake, but it has practical reasons to be used over a network. Runs fine, but in VNC it would definitely incur more or less fullscreen refreshes at 60Hz. That's a LOT more bandwidth and CPU than a few thousand vertices every so often and a set of transform matrices per frame.
Maybe you have a special definition of "outperform" but for me if you needed many times more resources to get the same result, that is less rather than more performance.
(Log in to post comments)
Bad and complex architecture Posted Jul 26, 2009 14:06 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Up until aiglx was merged, remote GL typically wasn't accelerated on Linux - the only real exception was the binary nvidia drivers. Things are much better now.
Bad and complex architecture Posted Jul 26, 2009 18:18 UTC (Sun) by astrand (guest, #4908) [Link]
OpenGL over the network (remote GLX) only works good for a small number of applications: those that are sending (datawise) small commands to the graphics card, and then letting it do all hard work, transforming these commands into many pixels. But most OpenGL apps nowadays doesn't work that they: they need to transfer large amounts of data to the graphics card. If it is remote, the data needs to transferred over the network, and things will be slow. So for remote 3D solutions, it's really much better to have the graphics card in the server; in the same machine that executes the applications. This is exactly what VirtualGL is about.
If you want to use VirtualGL with VNC, however, you'll need an accelerated implementation (TurboVNC/TigerVNC/Sun Shared Visualization/ThinLinc) to get good performance.
|
|||||||||||||