There was good discussion of the acceleration-query extension on today's
IRC session. We didn't come to a definite conclusion, but we did flush
out a lot of the issues.
The subject of this extension has come up repeatedly, practically since
the day OpenGL was first specified. The (still most accurate) response
has always been that it's extremely difficult to pose a meaningful query
due to the complexity and non-orthogonality of graphics hardware, and
that the only safe approach is to actually benchmark the operations you
want to use to see if they meet your performance goals. However,
hardware isn't getting any simpler, and developers are still complaining
about the benchmarking approach, so it's probably worthwhile to address
the problem directly.
One open question is the usage model for such an extension. Keith
suggested that developers will write a small number of code paths, and
then the app will choose one of these at runtime. Typically it'll
choose the "grooviest" path that is accelerated. I think Ian and I
mostly agree with this; I don't remember whether Brian went along with
it.
There are at least three ways we could structure an extension to allow
the app to determine whether a path is accelerated. (I'm going to use
different numbers for these than the ones we used during the IRC
session, so that I can put the simplest first and work up to the more
complex ones.)
1. We could enumerate a set of features that represent big
chunks of functionality. The app can test for the features it
needs at a very high level. For example:
GLenum glIsAccelerated(GLenum feature);
// returns GL_ALWAYS, GL_SOMETIMES, GL_NEVER
if (glIsAccelerated(GL_TEXTURE_3D) == GL_ALWAYS
&& glIsAccelerated(GL_CUBE_MAPPING) == GL_ALWAYS)
// use rendering code path A
else
// use rendering code path B
This is very similar in concept to the "caps bits" in D3D.
Pros: Simple to use. Probably closest in concept to what
developers really want.
Cons: Because there are lots of interactions between state and
the primitives that can be drawn, it seems likely that nearly
every query is going to return GL_SOMETIMES. It may be
difficult to come up with a clean set of "features" to test; for
example, even very fine-grained things like individual blending
functions might need to be tested to prevent any possibility of
a software fallback. Some features may be accelerated when used
individually, but can't be accelerated when used together. D3D
is moving away from caps bits for these and other reasons.
2. We could keep state information that determines whether a
fallback occurred. The app could reset it, perform a few
operations, then test it to see if any of those operations
caused a fallback. For example:
void glResetFallbackState();
GLbool glWasThereAFallback();
glResetFallbackState();
// Try stuff from rendering code path A:
glEnable(...);
glVertexPointer(...);
glDrawElements(...);
if (!glWasThereAFallback())
// use rendering code path A
else
// use rendering code path B
I've written this example to use a simple Boolean query, but
it's possible to extend this to return a list of "reasons" for
the fallback, or even counts of the various possible reasons for
the fallback. It could also be structured like glGetError, so
that each call returns one fallback reason. We talked about
this very briefly during the IRC session, but didn't reach
consensus.
Pros: Fully general, handles pretty much any possible
combination of state and drawing primitives. Not too hard for
driver developers to implement.
Cons: If an app wants to know *exactly* why a fallback
occurred, it essentially has to perform a search procedure
testing smaller and smaller subsections of its rendering code.
(This is a lot like using glGetError() to find the portion of
code that's causing a GL error.) Coming up with a list of
"reasons" for fallback could mitigate the difficulty of the
search, but might be hard for driver developers to do.
3. D3D allegedly uses a "pipeline validation" scheme in which you
set up the rendering pipeline according to the code path you
want to use, then query the driver to see if that path is
accelerated. We could do something similar, though we might
want to generalize the query to include the type of drawing
operation you want to perform; otherwise there's no way to
distinguish between the behavior of, say, drawing triangles vs.
glDrawPixels().
void glIsAccelerated(GLenum operation);
// Set up rendering code path A:
glEnable(...);
glVertexPointer(...);
// Can we draw triangles with it?
if (glIsAccelerated(GL_OPERATION_DRAW_ELEMENTS))
// use rendering code path A
else
// use rendering code path B
As with option #2, this could be generalized to return more
information than a simple Boolean.
Pros: Very nearly as general as option #2. Doesn't require
that anything actually be drawn, so it can be run at app startup
without showing any odd images to the user.
Cons: Slightly more difficult to specify and implement than
option #2. Otherwise, similar to #2.
I think that covers the options we discussed. The other folks can chime
in with corrections.
Allen
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
