[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.031 / U:155.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site