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

On Tue, 14 Dec 1999, David S. Miller wrote:

> Date: Mon, 13 Dec 1999 23:54:15 -0800
> From: Jon Leech <ljp@oddhack.engr.sgi.com>
>
> 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 fork()'d processes store the graphics library shared state in
> a shared/writable mapping area.

If one fork/thread dies or goes to sleep for some reason. Then what since
that process has the lock to the video hardware. All the other process in
the pipeline have to wait. Perhaps indefinetly. Then you start to add a
bunch of what if code kernel side to handle this. I'm looking for a much
cleaner solution.

Second point. What would every happen if another graphics library like
inventor would be ported to linux. Then how do you get both libraries to
share their graphic context state. If other 3D graphics libraries are
ported over from other OS to linux this problem would get out of hand. Of
course we could force the linux user community to use just one API. To me
this is not a option.

> What you proposed is: threads + thread local mappings
> Linus is suggesting instead: processes + shared mappings
>
> The latter provides what you'd like to do without any of the
> overhead or complexity assosicated with the former. And I think
> that alone will make up for whatever performance advantages are
> obtained by the former.
>
> As someone who intern'd at SGI for a few months and also saw how the
> aforementioned IRIX mechanism works, I can definitely say this is
> something we never want in Linux. TLB miss trap handler changing
> based upon if the thread has thread-local mappings, all the special
> cases in vfault/pfault to find the correct page tables to lookup, no
> thanks.

The reality is both methods have their cost. I don't want to see a huge
amount of complex go in their. The idea is to bring a clean solution to
the table. Something I'm looking for.


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/

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