Messages in this thread | | | Date | Wed, 15 Dec 1999 13:04:49 -0500 (EST) | From | "Benjamin C.R. LaHaise" <> | Subject | Re: Thread-private mappings and graphics (was Re: Per-Processor Data Page) |
| |
On Wed, 15 Dec 1999, Jim Gettys wrote:
> OK, the SGI folks went to town to do 3D (having done it before), and make > it run FAST, this time under X.
> So OpenGL does (conceptually): > SetContext(display, graphicscontextg, window) > ODraw(args) > ODraw(args) > ODraw(args) > > This interface style clearly presents hard problems for threaded systems, > unless there is thread specific data (at which point it works ok).
No it doesn't. Proper locking done in the ODraw call can be accomplished in 6 instructions on x86 (2 instructions to aquire the spinlock and 2 to verify that the context owner is still the current thread, and two to release the spinlock). OTOH, if one insists on using page table tricks, why not simply have separate contexts for each thread? You can already get a separate piece of thread specific data off of the top of the thread's stack (using the %esp & ~STACK_SIZE trick), so why not simply store the hardware context pointer there and use that in ODraw? By using multiple mappings of the device (once per thread), you don't loose the advantage of the single shared address space. Thread address space semantics DO NOT need to be changed.
-ben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |