Hi,
Any good resources available for setting up an OpenGL client/server environment?
This topic has been mentioned in the Red Book, but does not go beyond that.
Many thanks for any useful information.
lobstah…
I believe that in your very own PC, the motherboard/CPU is regarded as the server and the graphicscard/GPU is regarded as the client.
I think it may be more than that.
I recall reading that opengl commands could be sent off, over a network, to another computer (server) that would process these commands. Subsequently, the results of processing these commands would be sent back to the caller (client in this case).
This may be related to the use of glFlush vs. glFinish.
But then again, I could be wrong in my interpretation client / server use in OpenGL.
No, you are not wrong. The client/server can mean different machines in OpenGL. It is a standard feature in SGI machines to have server and client on different machines.
Idea is keeping the display lists on the server, and the client can execute the lists remotely. I doubt many real applications are using this though.
I also don’t think you can do it on Windows.
Bummer about the potential windows limitation.
I was hoping to offload some serious processing to a “hearty machine” and send the results to a “whimpy machine”.
Is OGL client / server used in Render Farms?
[This message has been edited by lobstah (edited 05-24-2002).]
In that case, you can write your own DCOM server\render and send it commands from your local machine.
Sounds like an interesting (and perhaps useful) project. Especially if you support DX as well. I can imagine this becomming a popular library.
You’re right, an interesting project indeed.
However, I’m still not clear on a fundemental:
At the end of ogl command processing, why can’t I just send the contents of the back buffer (the one rendered to) to another machine? I think the answer to my question is: the contents are dependent upon some of the machines hardware configuration. I think this is why display lists (higher level data) are used (mentioned earlier in this post).
I think I may be aimleesly floating around the depth buffer.
Send the back buffer? There is an SGI system that does exactly that. It depends on several things: namely, are the commands used to generate a scene larger than the raster representation of the scene? Think about the data used to generate a scene: usually some vertex arrays and some textures, whereas the back buffer is just an image. This data needs to be sent over a network. There are cases where one is better than the other, although surprisingly with more detailed geometry and bigger textures, the latter (with some form of rudimentary fixed-ratio compression) can be better. It also depends on if the server machine is more/less powerful than the client machine.
Now here would be a truly bizarre thing: OpenGL immediate mode is basically an RPC (remote-procedure call) API. Like HTTP. OpenGL over HTTP anyone? 
-Won
I never done any serious calculations on this.
The client\server thing on SGI has been around for years. It is probably impractical/impossible to have 30Hz update
on buffer through network.
With the display lists on the server, it is possible to have decent update rate.
Serious calculations? Very simple ones indicate that it most certainly is, particularly on gigabit ethernet with 8:1 compression ratios.
30 frames, 1024x768@24-bits w/ 8:1 compression is less than 9 MB/sec. With gigabit, you can have higher resolution in space/time and less compression.
-Won
Has anyone worked with or setup a render farm?
Also, I recall seeing a news article where SGI, I think it was them, have the ability to send imaging data anywhere in the world.
Data was processed at one location then disseminated (transmitted) to other locations.
I think the military was hot for the technology.