On 09/28/2012 07:14 AM, Brian Paul wrote:
On 09/27/2012 05:41 PM, Ian Romanick wrote:
On 09/27/2012 06:28 AM, Brian Paul wrote:
If an extension like this is marked as being "ES2" in extensions.c why
do we need to check ctx->API==API_OPENGLES2? It seems to me that we
should only have to test ctx->Extensions.ANGLE_texture_compression_dxt
and not the API (as you did in the _mesa_choose_tex_format() change).
The controls in extensions.c only select whether or not the string is
advertised to the application. It doesn't control whether or not the
driver sets the flag in gl_context::Extensions. I can imagine a driver
always setting the ANGLE flags but not the EXT flags.
We could easily write a function that loops over the extension list and
disabled those which aren't applicable to the context's API. It would
be called after the driver's done enabling its extensions.
The problem is that some of this functionality is used internally
whether or not the API can expose it.
Awhile ago some of the Intel guys and I had a related discussion around
the GLES3 run-up at SIGGRAPH. We discussed having
gl_context::Extensions that the driver sets and a separate
gl_context::_Extensions that is the subset available in the current API.
The former could be checked for internal uses, the latter could be
checked in application-facing code.
There was some reason that we didn't pursue this at the time, but I
don't recall what it was. Paul, do you remember?
This would have several benefits:
1. Simplified feature checks. Instead of writing "if
(ctx->Extensions.FOO_bar && API==something)" it would just be "if
(ctx->Extensions.FOO_bar)". Quicker to write, easier to read, less
error-prone, etc. There's lots of places where we're checking the
Extensions flags, but not the API versions. Adding API checks (for ES
in particular) would be a lot of churn. I know you've done some of that
already.
2. If an existing extension is made available on a new API, we could
make the change with a single line of code (change the API flags in the
extension_table[] array).
We already mostly have that. The problem with this new extension is
that it's a subset of an existing extension.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
