Boyd Stephen Smith Jr. put forth on 1/12/2010 11:41 AM: > On Monday 11 January 2010 23:45:12 Stan Hoeppner wrote: >> Boyd Stephen Smith Jr. put forth on 1/11/2010 12:23 PM: >>> 4. I had to switch VTs to the X server that was handling the OpenGL >>> commands for the GLX calls to complete. Likely, the video driver I am >>> using requires exclusive access to the hardware to process some GLX >>> requests. >> >> This is my point. The Linux OpenGL architecture has been optimized for >> local hardware rendering. It's impossible to get "usable" remote OpenGL >> today, mainly because textures are such an integral component of 3D >> rendering today. Trying to push texture data over ethernet (even GigE) >> for real time rendering is not really doable. > > That's not due to any Linux (kernel) limitation that "multiuser 3D OpenGL > would no longer be supported" and a far cry from having "to eliminate over > the > network OpenGL completely".[1] > > It takes time to push data across the network -- always has. In fact, > network > speed on (on average) faster today than when SGI or SUN workstations were big > sellers. While an apples-to-apples comparison is probably impossible, I'd > wager that using GLX on a remote X session is actually faster now than "back > in '02 or '03" or even the SGI workstations. > > Multi-pass rendering of a scene with 1G of textures and several megs of > compiled shader programs in 1/60th of a second is tough, but if your X server > hardware is good enough, your bands wide enough, and your round-trip times > low > enough, standard Xorg will do it without missing a beat. > > [1] If you don't recognize the quotes, they are from your earlier messages in > this thread.
I recognize it. As a test of your theory, fire up your favorite ID Software OpenGL Linux game on one Debian PC piping its GL calls over the network to another PC's X server. Run the game at 640x480x16bpp windowed. Le me know how this works, or doesn't, and what errors you generate. Also report how many hours/days you spend troubleshooting it to make it work. ;) -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
