trohling@uceng.UC.EDU (tom rohling) (10/11/90)
Is it possible to have a graphics process create child processes that
are still allowed to render to the parent process's graphics window?
A possible scenario would be something like this: The main graphics
program would fork a process to monitor some device so as
not to keep the main process all tied up with the little book-keeping
tasks. But at the same time, it would be nice if the child process could
update its information on the main process's window where all the status
information would be kept/displayed. The problem I forsee in this is
the event queue (mainly) and the matrix stack for that specific window.
Any hints/past experiences would be appreciated.
Thanks,
Tom Rohling
University of Cincinnati
bennett@sgi.com (Jim Bennett) (10/12/90)
In article <6353@uceng.UC.EDU> trohling@uceng.UC.EDU (tom rohling) writes: > > Is it possible to have a graphics process create child processes that > are still allowed to render to the parent process's graphics window? > > A possible scenario would be something like this: The main graphics > program would fork a process to monitor some device so as > not to keep the main process all tied up with the little book-keeping > tasks. But at the same time, it would be nice if the child process could > update its information on the main process's window where all the status > information would be kept/displayed. The problem I forsee in this is > the event queue (mainly) and the matrix stack for that specific window. > > Any hints/past experiences would be appreciated. > > Thanks, > > Tom Rohling > University of Cincinnati > Yes, this feature was added in 3.3. The major restrictions are: 1. The child process has to be created with sproc() and it must share at least the address space of the parent. 2. It is the application's responsibility to semaphore every graphics call to guarantee that every graphics call is atomic. The reason for #2 is that it would be possible to interrupt process A in the middle of a call, when not all of the tokens have been sent down, and schedule process B, which could then make a graphics call. The tokens from process B would go into the pipe in the middle of the tokens from process A, and get misinterpreted, with the probable result of crashing the microcode. Of course, the semaphores could (and probably should) be placed at a higher level than at the every graphics call level. But the idea is the same. Jim Bennett (bennett@esd.sgi.com)
trohling@uceng.UC.EDU (tom rohling) (06/20/91)
Is it possible to have multiple processes render to the same
graphics window?
The possible scenario would be something like this:
I start up a main process to do some rendering which controls
what rendering to do. Each of the available rendering routines will
be a separate process (executable). That way, I can add new routines
without having to recompile the main every time. Anyway, each of
the individual rendering processes should be able to render to the
same window in sequential order, one after the other, that way there
is no conflict in sending things down the graphics pipe.
Is something like this possible in any of the releases and how
about 4.0 under X?
Any hints/past experiences would be appreciated.
Thanks,
Tom Rohling
University of Cincinnati
micah@martika.csd.sgi.com (Micah Altman) (06/20/91)
In <1991Jun19.211639.22548@uceng.UC.EDU> trohling@uceng.UC.EDU (tom rohling) writes: > Is it possible to have multiple processes render to the same > graphics window? Yes. Use sproc(...,PR_SALL,...) . Do this _after_ you've done your first winopen() call ( winopen() causes a fork() if not foregrounded, which causes processes previously created to lose track of the windows ). However, this is usually not advisable. You'll need to synchronize, to make sure that the pipe is not addressed simultaneously. Each process will need to complete its bgn* end* group before the other process can access graphics legally. Furthermore, there is a lot of "state" associated with the graphics engine, and if you change state (current color, viewing matrix, etc, etc, ) with one process it will affect other. > The possible scenario would be something like this: > I start up a main process to do some rendering which controls > what rendering to do. Each of the available rendering routines will > be a separate process (executable). That way, I can add new routines > without having to recompile the main every time. Anyway, each of Can't see what this has to do with recompiling. You should be able to minimize your recompiling by modularizing your code and breaking it up into files, parallel processing shouldn't effect this. > the individual rendering processes should be able to render to the > same window in sequential order, one after the other, that way there > is no conflict in sending things down the graphics pipe. Probably a more efficient thing to do is to have one rendering process, and if you have cpu cycles to burn --- multiple computation and/or culling processes. -- "Entia non sunt multiplicanda sine necessitate." - William of Ockham Micah Altman, "Computational Juggler" micah@csd.sgi.com Phone (415) 335-1866 FAX (415) 965-2309 Disclaimer: Everything in this document is a lie.