Re: State of Linux graphics

From: Keith Packard (keithp_at_keithp.com)
Date: 08/31/05

  • Next message: Rik van Riel: "Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches" 
    To: Discuss issues related to the xorg tree <xorg@lists.freedesktop.org>
Date:	Wed, 31 Aug 2005 11:29:30 -0700

    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.

    I don't currently see any strong application motivation to provide this
    kind of functionality in a general purpose 2D API, and so it wouldn't
    make a lot of sense to push this into the 2D-centric X protocols either.

    When that changes, we'll want to explore how best to provide that
    functionality. One possibility is to transition applications to a pure
    GL drawing model, perhaps using glitz as a shim between the 2D and 3D
    worlds. That isn't currently practical as our GL implementations are
    missing several key features (FBOs, accelerated indirect rendering,
    per-component alpha compositing), but those things are all expected to
    be fixed at some point.

    The real goal is to provide a good programming environment for 2D
    applications, not to push some particular low-level graphics library.

    -keith

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Rik van Riel: "Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches"

    Relevant Pages

    • Re: stack, pop, push and min in o(1)
      ... printing the minimum value in the stack. ... Is there any way to provide min functionality in 0? ... you modify struct stack and push() as: ... C String APIs use too much memory? ...
      (comp.unix.programmer)
    • Re: stack, pop, push and min in o(1)
      ... printing the minimum value in the stack. ... Is there any way to provide min functionality in 0? ... you modify struct stack and push() as: ... Regular priority queues will not hit that sort of performance. ...
      (comp.unix.programmer)
    • Re: [PATCH 08/26] Add a secctx_to_secid() LSM hook to go along with the existing
      ... This is useful in its own right, and I would like to push it upstream for ... Isn't it a bit late in 2.6.24 to add new functionality, ... isn't an in-tree user for it in 2.6.24? ... I think the prudent thing to is to wait and push this ...
      (Linux-Kernel)
    • Re: [PATCH 08/26] Add a secctx_to_secid() LSM hook to go along with the existing
      ... This is useful in its own right, and I would like to push it upstream for ... Isn't it a bit late in 2.6.24 to add new functionality, ... isn't an in-tree user for it in 2.6.24? ... I think the prudent thing to is to wait and push this ...
      (Linux-Kernel)
    • Re: linux: detect application crash
      ... I was curious if such a functionality ... The app itself could do this (installing a signal handler for segfaults, ... etc.) but the problem is that whatever caused the program to crash may ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)