lkml.org 
[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
    Date
    From
    >     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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.022 / U:124.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site