lkml.org 
[lkml]   [1999]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[OFF-TOPIC] Re: Linux Graphics Architecture (format fixed)
    On Mon, 8 Feb 1999, Shawn Leas wrote:

    You still want to go the way of DOS. I remember downloading a JPG
    veiwer called QPEG, and it had video drivers bundled with it.

    Sounds a little like X, eh?

    then again, use the right tool for the right job, and don't let
    principles get in the way of practicalities.

    Is the hassle of implementing full-blown, accelerated, concurrent
    access, graphics drivers in kernel worth the effort?

    how many people really need to have several processes
    concurrently writing to the graphics hardware? As it stands i can
    think of only two: X and a direct render graphics layer - which
    would have to co-operate with each other to be of practical use
    anyway.

    [X is the de facto UNIX graphics standard for the foreseeable
    future, for better of worse. {better imho}.]

    If it was for a single platform with a reasonably limited range
    of graphics hardware - then maybe yes. But for an OS that covers
    so many platforms? and those platforms cover how many weird and
    wonderful different graphics hardware?

    And which cards are capable of what? How do you present a uniform
    interface? How would a uniform, rich, in-kernel, 3d & graphics
    implementation run on my P133 with Trident TGUI graphics card?
    Keep it too simple and you're wasting the more exotic hardware.

    So perhaps it's best to let the kernel stick to a limited
    knowledge of the graphics hardware, so that it can always
    clean-up if needs be. And let the higher level stuff sort it out
    between themselves as to what they want to do.

    If needs be, some basic functions can always be migrated from the
    higher level into the kernel. but let X and co worry about
    concurrency and arbitration and things like that. The kernel has
    enough of that kind of stuff to worry about already.

    Eg, DEC faced this issue when they tried to go head to head with
    SGI with their PowerStorm graphics card. Their solution was to
    implement direct rendering with the X server handling concurrency
    issues. X can then arbitrate between multiple X protocol and
    direct render clients, as it sees fit. Only that with direct
    render clients the X server doesn't need to do any rendering
    work, the direct render client and the X server just need to set
    things up via the X protocol.

    X is already an arbitrator, why reinvent the wheel when it can
    just be extended to arbitrate between more types of clients?

    (Direct render clients can be anything by the way. Doesn't have
    to be OpenGL.)

    This way, we keep a standard and already uniform graphical
    interface, X. And we can write extensions to it to support a
    uniform high-performance graphics layer, "direct render" for more
    advanced graphics cards. And we don't clutter the kernel with
    highly complicated code that could run in user-space.

    [eg: why can't the kernel do sound mixing? - so that 2 or more
    processes could write to /dev/dsp concurrently and produce a real
    mixed sound? the implementation itself exists.....]

    regards,

    Paul Jakma.

    (perhaps this thread should be on another list.).

    --
    Paul Jakma paul@clubi.ie
    PGP5 key: http://www.clubi.ie/publickey.txt
    -------------------------------------------
    Fortune:

    [FORTRAN] will persist for some time -- probably for at least the next decade.
    -- T. Cheatham


    -
    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:50    [W:0.031 / U:59.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site