Re: State of Linux graphics

From: Allen Akin (akin_at_pobox.com)
Date: 09/01/05

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

    On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
    | On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
    | > ...
    |
    | Right, the goal is to have only one driver for the hardware, whether an
    | X server for simple 2D only environments or a GL driver for 2D/3D
    | environments. ...

    I count two drivers there; I was hoping the goal was for one. :-)

    | ... I think the only questions here are about the road from
    | where we are to that final goal.

    Well there are other questions, including whether it's correct to
    partition the world into "2D only" and "2D/3D" environments. There are
    many disadvantages and few advantages (that I can see) for doing so.

    [I'm going to reorder your comments just a bit to clarify my replies; I
    hope that's OK]

    | ... However, at the
    | application level, GL is not a very friendly 2D application-level API.

    The point of OpenGL is to expose what the vast majority of current
    display hardware does well, and not a lot more. So if a class of apps
    isn't "happy" with the functionality that OpenGL provides, it won't be
    happy with the functionality that any other low-level API provides. The
    problem lies with the hardware.

    Conversely, if the apps aren't taking advantage of the functionality
    OpenGL provides, they're not exploiting the opportunities the hardware
    offers. Of course I'm not saying all apps *must* use all of OpenGL;
    simply that their developers should be aware of exactly what they're
    leaving on the table. It can make the difference between an app that's
    run-of-the-mill and one that's outstanding.

    "Friendliness" is another matter, and it makes a ton of sense to package
    common functionality in an easier-to-use higher-level library that a lot
    of apps can share. In this discussion my concern isn't with Cairo, but
    with the number and type of back-end APIs we (driver developers and
    library developers and application developers) have to support.

    | ... GL provides
    | far more functionality than we need for 2D applications being designed
    | and implemented today...

    When I look at OpenGL, I see ways to:

            Create geometric primitives
            Specify how those primitives are transformed
            Apply lighting to objects made of those primitives
            Convert geometric primitives to images
            Create images
            Specify how those images are transformed
            Determine which portions of images should be visible
            Combine images
            Manage the physical resources for implementing this stuff

    With the exception of lighting, it seems to me that pretty much all of
    that applies to today's "2D" apps. It's just a myth that there's "far
    more" functionality in OpenGL than 2D apps can use. (Especially for
    OpenGL ES, which eliminates legacy cruft from full OpenGL.)

    | ... picking the right subset and sticking to that is
    | our current challenge.

    That would be fine with me. I'm more worried about what Render (plus
    EXA?) represents -- a second development path with the actual costs and
    opportunity costs I've mentioned before, and if apps become wedded to it
    (rather than to a higher level like Cairo), a loss of opportunity to
    exploit new features and better performance at the application level.

    | ...The integration of 2D and 3D acceleration into a
    | single GL-based system will take longer, largely as we wait for the GL
    | drivers to catch up to the requirements of the Xgl implementation that
    | we already have.

    Like Jon, I'm concerned that the focus on Render and EXA will
    simultaneously take resources away from and reduce the motivation for
    those drivers.

    | I'm not sure we have any significant new extensions to create here;
    | we've got a pretty good handle on how X maps to GL and it seems to work
    | well enough with suitable existing extensions.

    I'm glad to hear it, though a bit surprised.

    | This will be an interesting area of research; right now, 2D applications
    | are fairly sketchy about the structure of their UIs, so attempting to
    | wrap them into more structured models will take some effort.

    Game developers have done a surprising amount of work in this area, and
    I know of one company deploying this sort of UI on graphics-accelerated
    cell phones. So some practical experience exists, and we should find a
    way to tap into it.

    | Certainly ensuring that cairo on glitz can be used to paint into an
    | arbitrary GL context will go some ways in this direction.

    Yep, that's essential.

    | ...So far, 3D driver work has proceeded almost entirely on the
    | newest documented hardware that people could get. Going back and
    | spending months optimizing software 3D rendering code so that it works
    | as fast as software 2D code seems like a thankless task.

    Jon's right about this: If you can accelerate a given simple function
    (blending, say) for a 2D driver, you can accelerate that same function
    in a Mesa driver for a comparable amount of effort, and deliver a
    similar benefit to apps. (More apps, in fact, since it helps
    OpenGL-based apps as well as Cairo-based apps.)

    So long as people are encouraged by word and deed to spend their time on
    "2D" drivers, Mesa drivers will be further starved for resources and the
    belief that OpenGL has nothing to offer "2D" apps will become
    self-fulfilling.

    | So, I believe applications will target the Render API for the
    | foreseeable future. ...

    See above. :-)

    Allen
    -
    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: jmerkey: "Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches"

    Relevant Pages

    • Re: State of Linux graphics
      ... Those OpenGL commands could be directly implemented with whatever ... After one driver was ... >>display hardware does well, ... on renderbuffers but we really need that overdue memory manager. ...
      (Linux-Kernel)
    • Re: Xlib or OpenGL ?
      ... hardware to do 2D blitting) than the drivers used by XLib. ... then either your hardware is weird or your app is ... The wierdness changes from driver version to driver ... OpenGL I'm disagreeing with. ...
      (comp.windows.x)
    • Re: [RFC] Small PCI core patch
      ... > On the hardware front, there are some signs of hope. ... > building X, DRI, and openGL from source isn't something I do casually. ... > radeon driver I mentioned above, it only seems to get touched every 2 months ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: OpenGL-based framebuffer concepts
      ... that a low level driver handles nicely. ... state is loaded into the hardware still exists too. ... I would instead start by making fbdev the low level driver. ... Later it would use a collection of apps like ...
      (Linux-Kernel)
    • [opensuse] openSUSE 10.3 not detecting SATA HD
      ... the sata_sis driver. ... I've tried turning off ACPI in bios and acpi=off which ... openSUSE 10.2 and all my hardware is working fine. ... info.product = 'USB Raw Device Access' ...
      (SuSE)