Linux OpenGL ABI discussion

[Allen Akin]

On Thu, Sep 29, 2005 at 01:54:00PM -0400, Adam Jackson wrote:
| The deeper issue here is whether it's actually useful to require some minimum 
| level of functionality even when large swaths of it will be software.  If I 
| don't have cube map support in hardware, do I really want to try it in 
| software?  Is that a useful experience for developers or for users?

For OpenGL at least, history suggests the answer is usually "yes."  The
argument goes back to the pre-1.0 days, when texture mapping was only
available on fairly exotic hardware.  The decision was made to require
it in the standard, and it turned out to be valuable on pure software
implementations because (1) it was fast enough to be usable for a
surprisingly large range of apps; (2) people with older hardware still
had the option to use it, rather than having that option closed off
up-front by the people defining the standard, and they found uses that
were worthwhile; (3) development could occur on older hardware for
deployment on newer hardware; (4) it served as a reference for hardware
implementations and a debugging tool for apps.

This experience was repeated with a number of other features as OpenGL
evolved.

If there's no consensus in the ARB about the desirability of a given
piece of functionality, it tends to be standardized as an extension (or
very rarely as a subset, like the Imaging Operations).  Extensions are
optional, so they provide middle ground.  But eventually, if a piece of
functionality proves valuable enough to achieve consensus, it moves into
the OpenGL core and software implementations become mandatory.

OpenGL ES has taken a slightly different route (with API profiles).  I
don't have firsthand knowledge of how well that's worked out.

| Perhaps what I would like is a new set of glGetString tokens that describe 
| what version and extensions the hardware is actually capable of accelerating, 
| rather than what the software supports.

This question also goes back to the very earliest days of OpenGL.

The fundamental technical problem is that there is no tractable way to
define an "operation" so that you can make a simple query to learn
whether it's accelerated.  So much depends on the current graphics state
(how many TMUs are enabled, the size of image or texture operands vs.
the size of available video memory, whether colors are specified by
floats or unsigned chars, whether vertices lie in DMAable or
CPU-accessible address space, etc., etc., ad infinitum) that most of the
time you can't even express a simple question like "Is triangle drawing
accelerated?"  A number of other APIs have gone down this road in the
past, and none of them found a viable solution to the problem.

In practice, two approaches are used with OpenGL.  One is simply to
benchmark the operations you want to perform and determine whether a
given OpenGL implementation is fast enough.  (This is used by
"isfast"-style libraries and by game developers, always during
development but occasionally during installation or initialization.) The
other is to assume that if an extension is advertised (via glGetString),
then it's accelerated; if an extension is present but not advertised,
then it's probably not accelerated.

There was interest a couple of years ago in implementing a more
sophisticated mechanism.  One option was a query of the form "If I try
to execute a given drawing operation right now, with all the graphics
state that currently holds, will it be accelerated?" (D3D has a pipeline
validation mechanism that's something like this).  Another was a query
of the form "Have any software fallbacks occurred since the last time I
asked?" that you could make after you'd actually run one or more
operations.  There were unanswered questions about whether either of
these could be made worthwhile.  I haven't tracked the ARB since late
last year so I don't know if any progress has been made on this front.

Sorry for the long reply.  These questions come up from time to time,
and I wanted to make sure everyone had the background information.

Allen