From: Brian P. <bri...@tu...> - 2006-01-16 22:00:42
|
David Rose wrote: > Brian Paul wrote: > >> I'm afraid I don't quite understand this. I think you need to be more >> careful with "window" and "context", etc. > > > OK, let me try again. By "graphics context", I mean an OpenGL context: > a graphics state, including a collection of texture objects, buffer > objects, and so on. All OpenGL commands are issued within a particular > graphics context, and will have an effect only on that particular context. > > I'm also talking about the "Chromium context": all of Chromium's > internal state, its collection of SPU's, hosts, and the mothership. I > guess I should call this a "Chromium session" to reduce overloading of > the word "context". > > I understand that a Chromium session usually presents a single graphics > context to the user. Chromium maintains a virtual graphics context, > which it then distributes to a number of remote PC's. (Each PC, of > course, has its own internal OpenGL context--but Chromium makes them all > appear to the user to share a single context.) > > By "window", I mean the visible presentation of a rendered framebuffer. > For this discussion, I am particularly interested in remote windows: > those windows that are opened on a different PC than the one that is > running the main application. > > Our rendering engine is perfectly capable of creating and managing > multiple different graphics contexts. We can open multiple different > windows, each using a different graphics context if we like, and with > slightly different points of view on the same world. Our engine will > send the appropriate subset of textures and vertices to each different > graphics context. Of course, this capability is of limited usefulness > on a single PC with a single graphics card. > > But this would be very useful if we had a way to deliver an unfiltered > OpenGL stream to a remote PC. In particular, if we had a way to deliver > a number of unfiltered OpenGL streams, each representing a different > graphics context on a different remote PC. > > This, then, is my hope: all we need is a way to create a unique Chromium > session for each PC we would like to render to, and configure that > session to open a graphics context and a window on its PC and deliver > OpenGL commands to it. To render to multiple different PC's, we will > create multiple unrelated Chromium sessions. Do you mean there'll be multiple instances (processes) of the application running? > To reconfigure a window on > a particular PC, we will destroy a Chromium session and create a new one. > > So, it follows that all we need is this subset of Chromium's > functionality: to open a graphics context and a window on a single > remote PC and deliver OpenGL commands to it. Sounds like the pack SPU would do the trick. See crdemo.conf. > (We also need the ability > to run multiple unrelated Chromium sessions from the same host PC, but I > don't imagine this would be difficult.) You can run multiple applications at once with Chromium as long as they each use a different mothership. >> Well, the packer and unpacker are the main modules for sending command >> streams around. Plus the network layer of course. And the crserver >> does command dispatching at the receiving end. >> >> I'm not sure how practical it would be to extract just those pieces. > > > I'm not sure if it's necessary to *extract* those pieces; but I do want > to be able to *use* them. Surely it is possible to configure Chromium > to do such a relatively simple task, using the normal mothership > configuration interface-- Dynamic configuration aside, I think Chromium as-it-is can do what you describe there. If you try the crdemo.conf configuration with the pack SPU, that's the simplest way to send rendering to a remote machine. But I get the impression that what you're really fishing for might be a new SPU that lets an application connect to any number of remote rendering servers and explicitly send OpenGL commands to the particular servers under application/engine control. We don't have that. The tilesort SPU sends an application's OpenGL stream to one or more servers, but the GL command routing is totally controlled by the SPU, not the application. > so the question is really, is it possible to > fake out the mothership with a virtual "mothership" running within our > engine? And to do this again, for n different remote PC's? I don't think a virtual mothership running inside your app/engine's process would work today. The mothership is a running python process that has to accept messages on a number of sockets from a number of places (the app faker, crserver and SPUs). You can think of the mothership as operating like a kind of web server. I know that the python interpreter can be used from within a C program, but I don't know how your engine and the mothership could both do their responsiblities short of forking/exec'ing the mothership. -Brian |