Re: State of Linux graphics

From: Jim Gettys (jg_at_freedesktop.org)
Date: 08/31/05

  • Next message: Jeff V. Merkey: "[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 13:48:11 -0400
    
    

    Certainly replicating OpenGL 2.0's programmability through Render makes
    no sense at all to me (or most others, I believe/hope). If you want to
    use full use of the GPU, I'm happy to say you should be using OpenGL.
                                    - Jim

    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.
    >
    > Allen
    > _______________________________________________
    > xorg mailing list
    > xorg@lists.freedesktop.org
    > http://lists.freedesktop.org/mailman/listinfo/xorg

    -
    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: Jeff V. Merkey: "[ANNOUNCE] DSFS Network Forensic File System for Linux Patches"

    Relevant Pages

    • Re: avoiding glTranslatef*
      ... So memory bandwidth is in critical role, ... and you can still render with a single display list command. ... Let's not forget in these discussions, that OpenGL is not, and in my ... just a graphics hardware driver exposed to ...
      (comp.graphics.api.opengl)
    • glClipPlane precision
      ... My OpenGL application has a requirement to render a number of triaxial ... ellipsoid and grid, as if illuminated from a point light source. ... Then, between enabling and disabling this plane, ...
      (comp.graphics.api.opengl)
    • Re: State of Linux graphics
      ... > addressed fully or partly in the OpenGL world. ... to write some more interesting compositing managers. ... Using OpenGL instead of X Render might very well be the way we end up ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: How can you render any arbitary letter/word in 3D using polygons only
      ... 3D image of it using polygons. ... To me this seems impossible to do unless there are OpenGL API's that I ... I have extensively used VRML to render scenes,etc,etc. ... I have looked at display lists, is this on the right track ?? ...
      (comp.graphics.api.opengl)
    • Re: Is Direct3D a rip-off of OpenGL?
      ... >> DirectX is used to make games. ... DirectX is used to render in ... OpenGL is used in rendering ... > games, where they are the defacto standard. ...
      (comp.graphics.api.opengl)