Re: State of Linux graphics

From: Brian Paul (brian.paul_at_tungstengraphics.com)
Date: 09/01/05

  • Next message: Nathan Lynch: "Re: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)" 
    Date:	Thu, 01 Sep 2005 09:24:35 -0600
To: Discuss issues related to the xorg tree <xorg@lists.freedesktop.org>

    Just a few comments...

    Keith Packard wrote:

    > Again, the question is whether a mostly-software OpenGL implementation
    > can effectively compete against the simple X+Render graphics model for
    > basic 2D application operations, and whether there are people interested
    > in even trying to make this happen.

    I don't know of anyone who's writen a "2D-centric" Mesa driver, but
    it's feasible. The basic idea would be to simply fast-path a handful
    of basic OpenGL paths that correspond to the basic X operations:

    1. Solid rect fill: glScissor + glClear
    2. Blit/copy: glCopyPixels
    3. Monochrome glyphs: glBitmap
    4. PutImage: glDrawPixels

    Those OpenGL commands could be directly implemented with whatever
    mechanism is used in conventional X drivers. I don't think the
    overhead of going through the OpenGL/Mesa API would be significant.

    If Xgl used those commands and you didn't turn on fancy blending, etc.
    the performance should be fine. If the hardware supported blending,
    that could be easily exposed too. The rest of OpenGL would go through
    the usual software paths (slow, but better than nothing).

    It might be an interesting project for someone. After one driver was
    done subsequent ones should be fairly easy.

    >>| ... 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.
    >
    >
    > Not currently; the OpenGL we have today doesn't provide for
    > component-level compositing or off-screen drawable objects. The former
    > is possible in much modern hardware, and may be exposed in GL through
    > pixel shaders, while the latter spent far too long mired in the ARB and
    > is only now on the radar for implementation in our environment.
    >
    > Off-screen drawing is the dominant application paradigm in the 2D world,
    > so we can't function without it while component-level compositing
    > provides superior text presentation on LCD screens, which is an
    > obviously increasing segment of the market.

    Yeah, we really need to make some progress with off-screen rendering
    in our drivers (either Pbuffers or renderbuffers). I've been working
    on renderbuffers but we really need that overdue memory manager.

    >>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.)
    >
    > Yes, you *can*, but the amount of code needed to perform simple
    > pixel-aligned upright blends is a tiny fraction of that needed to deal
    > with filtering textures and *then* blending. All of the compositing code
    > needed for the Render extension, including accelerated (MMX) is
    > implemented in 10K LOC. Optimizing a new case generally involves writing
    > about 50 lines of code or so.

    If the blending is for screen-aligned rects, glDrawPixels would be a
    far easier path to optimize than texturing. The number of state
    combinations related to texturing is pretty overwhelming.

    Anyway, I think we're all in agreement about the desirability of
    having a single, unified driver in the future.

    -Brian
    -
    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: Nathan Lynch: "Re: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)"

    Relevant Pages

    • Re: State of Linux graphics
      ... | X server for simple 2D only environments or a GL driver for 2D/3D ... The point of OpenGL is to expose what the vast majority of current ... display hardware does well, ... if the apps aren't taking advantage of the functionality ...
      (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)
    • [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)
    • Re: 2008 SBS no longer boots
      ... driver issue initially, the fact that it seems to happen randomly now ... weird with a hardware problem that consistently doesn't get through boot ... other customer, even a 2 week old one, the problem immediately returned. ... There was a time when a server was fired up with a specialized OS and had a battery of tests run against each component to purposefully stress it. ...
      (microsoft.public.windows.server.sbs)