lkml.org 
[lkml]   [1999]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread-private mappings and graphics (was Re: Per-Processor Data Page)

On 13 Dec 1999, Linus Torvalds wrote:

> In article <Pine.LNX.4.20.9912132229460.10986-100000@imperial.edgeglobal.com>,
> James Simmons <jsimmons@edgeglobal.com> wrote:
> >>
> >> 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.
>
> It will never happen on Linux.
>
> I'm suprised an SGI person hasn't learnt from past mistakes. IRIX is
> unstable, and unmaintainable, and please just face it - it's because SGI
> had the "cool feature of the day" disease.

Because IRIX has certain design flaws doesn't mean the entire OS is
crap. I have heard nothing but good things about XFS.

> Thread-private mappings WILL NOT HAPPEN. You can obviously do them in
> SGI Linux, but that way lies madness, and it's something I'll keep
> pointing out in public.

I'm not talking about implementing Thread-private mappings for the
entire system. What I have done is when the process mmaps the accel region
set a flag. This way if the process creates new threads or forks it will
have a private mapping. The impact of private mapping is thus minimized.
Once a process unmaps the accel region the flag is turned off. The only
way preformance can be killed on the system is if the process that
mmapped the accel region creates a bunch of threads and none of the
threads use the accel region. I just don't see that happening. Also how
many threads will a well designed OpenGL library have. You don't want to
go crazy here creating a bunch of threads.

The question we have to ask why do we want private mapping. The reason
DRE (Direct Rendering Engine) needs this is to ensure a page fault
happens. If you don't want private mapping for thread in this case then
tell me a way to ensure every thread or forked process that uses the
accel engine page faults. Why do you need a page fault? Because the page
fault is what I used to serialize access to the accel engine on SMP
machines and to save and restore the graphics context. As Jon Leech
pointed out each threads need to refer to *different* graphics contexts.
OpenGL is based on the graphics pipeline. Ideally each part of the
pipeline would be used by a different process. Say we have SMP machine
with one video card. Ideally a different process on each CPU would be in
different places in the graphics pipeline. The problem is one thread
could have the hardware in a state that could alter the desired results
for the other threads since the other threads most likely need the
hardware in another state.
Also as Jon pointed out 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. Either
the threaded OpenGL API is broken or DRE for linux-SGI is. If this the
case then linux will need its own special threaded OpenGL library
compared to all the other platforms which don't require this special
rewrite.

> However, thread-private mappings are FUNDAMENTALLY broken. They
> completely break the whole point of having a thread in the first place,
> and I can only suggest that if you want them you should look at this
> great concept that was invented, oh, thirty years ago by people more
> intelligent than you or I.
>
> Namely "fork()". Which gives you the tread-private mapping you want.

So are you suggesting if anyone wants to program DRE to have a
README.nothreads warning file. Also we should have to rewrite the native
threaded OpenGL library for SGI machines to use just fork instead of
easly porting over to linux-SGI.

> again, but the short and sweet of it is that you CANNOT do
> thread-private mappings without losing most of the performance advatages
> of a thread in the first place.

One I'm suggesting this only for process that mmap the accel region not
the entire system. The ratio of these special private mapped for DRE
with OpenGL to total shared threads in the system will be small.
Second the small performace decrease for private mapping threads in DRE
is worth it for stability on SMP machines. Its along the same lines as
having a virtual file system. If you wanted maximum performace from a
hard driver you could just write and read from the hard driver directly.
Instead we have virtual filesystem that provides stablility and security
in a mulituser SMP machine.

> And once you lose the performance-advantage of threads, not all that
> much else remains. Threads certainly aren't any easier to program than
> processes...

All I do inside fork that if the process creating children mmaped the
accel region be treated as a regular fork even if its a thread.

The bottom line is once the code is done I will test to see how it
compares to the other graphics soultions out. If DRE is a poorer soultion
then DRE will die away. If not then it should become the standard way to
handle graphics in linux.


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

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.096 / U:0.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site