> In article <82n991$aq9nm@fido.engr.sgi.com>,
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> [much elided]
> >You also rarely want thread private storage.
>
> I don't want to enter into the debate over kernel implementation
> details, but do want to bring up a use for thread-private mappings that
> may not be on people's minds. Most of the discussion so far seems to be
> assuming apps like web serving. Another area where multithreading is
> important is 3D. The OpenGL API relies on an implicit graphics context,
> so that multithreaded apps need to do some sort of thread-specific
> lookup at each call.
>
> Many GL calls can be just a few instructions long on suitable
> hardware (e.g. shove parameters into a DMA buffer or FIFO), so the
> lookup needs to be very fast. Brian Paul has done some preliminary
> testing demonstrating a roughly 3:1 performance hit for performing
> thread-specific lookup via pthread_getspecific() on an otherwise empty
> call, giving some guidance as to impact in a real driver.
>
> The fact is that many workstation apps using the OpenGL API rely on
> threadsafe GL support, and slow lookups would cripple their performance.
> We need to explore implementation options more, but the issue certainly
> could be addressed by thread-private mappings, as is done today on IRIX
> and other platforms.
>
> Finally, note that "solutions" requiring changes to the OpenGL API,
> such as passing a context pointer with each call (a suggestion that
> might come from a pure kernel-centric POV) would impose enormous coding
> and testing burdens on existing applications, invalidate all existing
> documentation, and make writing portable code far more difficult in the
> future. I doubt this would be a viable option.
>
> Jon Leech
> SGI
He is totally right.The DRE (Direct rendering engine) in
drivers/sgi/char/graphics.c is severly broken. First is the thread problem
he is discussing. If you have a app that uses DRE that creates three
threads and each thread preforms a different graphics operation. The
first thread will cause the page fault. The second and third thread
will NOT which is required for DRE to work right. Another problem here is
that if the other process (the one which owns the mapping) is threaded,
and if the g_user task dies leaving other threads running, then there will
be no callback to unmap that page --- the threaded application still has
the mapping. However, this leaves g_user pointing to an invalid task.
Also for the "solutions" now being presents to handle graphics on linux
requires a good amount of change to a threaded OpenGL library to handle
userland locking and unlocking.
I'm working on fixing DRE for linux. The above issue is being delt with
by me. I haven't setup the web page yet but a mailing list is avaliable
http://lists.sourceforge.net/mailman/listinfo/linuxgfx-dev. Code is
avaliable by CVS. The page with all the links is at
http://sourceforge.net/project/?form_grp=419
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
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/