[Mesa-dev] [PATCH v4 1/1] intel: add support for ANGLE_texture_compression_dxt.

[Ian Romanick]

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.