[lkml]   [1999]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data
>     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".


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.130 / U:7.844 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site