Messages in this thread | | | Date | Tue, 14 Dec 1999 12:10:13 -0500 (EST) | From | James Simmons <> | Subject | Re: 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/
| |