State of Linux graphics

[Allen Akin]

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