[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: State of Linux graphics
    On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
    > On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
    > | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
    > | > In general, the whole concept of programmable graphics hardware is
    > | > not addressed in APIs like xlib and Cairo. This is a very important
    > | > point. A major new GPU feature, programmability is simply not
    > | > accessible from the current X APIs. OpenGL exposes this
    > | > programmability via its shader language.
    > |
    > | ... I don't
    > | see why this can't be exposed through the Render extension. ...
    > What has always concerned me about this approach is that when you add
    > enough functionality to Render or some new X extensions to fully exploit
    > previous (much less current and in-development!) generations of GPUs,
    > you've essentially duplicated OpenGL 2.0. You need to identify the
    > resources to be managed (framebuffer objects, vertex objects, textures,
    > programs of several kinds, etc.); explain how they're specified and how
    > they interact and how they're owned/shared; define a vocabulary of
    > commands that operate upon them; think about how those commands are
    > translated and executed on various pieces of hardware; examine the
    > impact of things like graphics context switching on the system
    > architecture; and deal with a dozen other matters that have already been
    > addressed fully or partly in the OpenGL world.
    > I think it makes a lot of sense to leverage the work that's already been
    > done: Take OpenGL as a given, and add extensions for what's missing.
    > Don't create a parallel API that in the long run must develop into
    > something at least as rich as OpenGL was to start with. That costs time
    > and effort, and likely won't be supported by the hardware vendors to the
    > same extent that OpenGL is (thanks to the commercial forces already at
    > work). Let OpenGL do 80% of the job, then work to provide the last 20%,
    > rather than trying to do 100% from scratch.

    Sounds sane. This is actually what I've done in Xgl to make it possible
    to write some more interesting compositing managers. I implemented
    GLX_MESA_render_texture so that a compositing manager can bind
    redirected windows to textures and draw the screen using OpenGL.

    Using OpenGL instead of X Render might very well be the way we end up
    doing things. The current X Render API is sufficient for even more
    complex cairo applications and that's good as they can then be
    accelerated on servers without GL support. But you're probably right,
    the next time we think of extending X Render we might want to reconsider
    if that's such a good idea. If it's not likely that anything but a
    OpenGL based server will accelerate it, then it might be a bad idea to
    add it to X Render.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-08-31 19:26    [W:0.022 / U:19.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site