> 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/