[Mesa-dev] Feature testing

[Ian Romanick]

On 08/24/2012 02:12 PM, Brian Paul wrote:
> On 08/24/2012 09:46 AM, Ian Romanick wrote:
>
>> @@ -372,6 +380,8 @@ _mesa_set_enable(struct gl_context *ctx, GLenum
>> cap, GLboolean state)
>>         case GL_LIGHT5:
>>         case GL_LIGHT6:
>>         case GL_LIGHT7:
>> +         if (ctx->API != API_OPENGL&&  ctx->API != API_OPENGLES)
>> +            goto invalid_enum_error;
>
> [..]
>
>>     case GL_BUFFER_MAP_OFFSET:
>> -      if (!ctx->Extensions.ARB_map_buffer_range)
>> +      if ((!_mesa_is_desktop_gl(ctx) ||
>> !ctx->Extensions.ARB_map_buffer_range)
>> +          && !_mesa_is_gles3(ctx))
>>           goto invalid_pname;
>>        *params = (GLint) bufObj->Offset;
>>        return;
>
> I think there's opportunity to simplify a bunch of these feature checks.

I had thought about doing something similar.  My original idea was

static inline bool
_mesa_have_fixed_function(const struct gl_context *ctx)
{
     return ctx->API == API_OPENGL || ctx->API == API_OPENGLES;
}

The problem I encountered is the large number of (usually ES1 related) 
exceptions.  This was especially annoying in enable.c.  It made me 
worried about copy-and-paste bugs and people coming along later and 
"simplifying" (i.e., adding bugs) code that didn't use the helper to use 
the helper.

To be honest, I don't feel very warm inside about having it either way.

> How about helper macros like:
>
> /** Is fixed-function lighting supported? */
> static inline GLboolean
> _mesa_have_lighting(const struct gl_context *ctx)
> {
>     return ctx->API == API_OPENGL || ctx->API == API_OPENGLES;
> }
>
>
> /** Is map-buffer-range supported? */
> static inline GLboolean
> _mesa_have_map_buffer_range(const struct gl_context *ctx)
> {
>     return (_mesa_is_desktop_gl(ctx) &&
> ctx->Extensions.ARB_map_buffer_range)
>      || _mesa_is_gles3(ctx);
> }
>
>
> I know this isn't practical everywhere, but it would improve the
> readability in many places and if we get the logic wrong for some
> feature (or it changes with a new GL version/ext in the future) it can
> be fixed in one place, easily grepped for, etc.
>
> -Brian