Re: Thread-private mappings and graphics (was Re: Per-Processor Data

Alan Cox (alan@lxorguk.ukuu.org.uk)
Tue, 14 Dec 1999 15:41:57 +0000 (GMT)

> This doesn't address the problem. First, the threads need to refer
> to *different* graphics contexts. Second, the API requires that these
> contexts be identified by some thread-specific mechanism available to
> the graphics library, not by explicit stack pointers in the application
> - whether that mechanism is private mappings or tarot cards matters not,
> so long as it's extremely fast.

So OpenGL with threads is going to pay a small penalty for that. Why should
other apps pay a penalty for an OpenGL design wart ?

What you need to be doing instead IMHO is to be saying "OpenGL has this
awkward limitation". It may be that OpenGL genuinely should have been designed
with that thread storage idea. If so then you need to figure out how to make
the kernel handle it well at _ZERO_ cost to anybody else. If you end up
not being able to use CLONE_VM for opengl apps so be it, but dont break
the speed of CLONE_VM for other apps.

> really occasion for a rant about how "unstable and unmaintainable" IRIX
> is, but whatever - so long as in the end Linux allows apps to issue
> vertices at least as fast as other OSes on the same hardware.

You forgot "and continues to be able to do so for years to come".

Alan

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