[Piglit] [Mesa-dev] [PATCH] piglit/general/texunits: fix to check the correct extension and be less pedantic

[Luca Barbieri]

> I think the real source of difficulty is that you don't have to opt-in
> to extensions.  This makes it easy for application developers to
> accidentally rely on extension behavior that is supported on their
> development machine.  When the code is run on a different system, it may
> mysteriously fail.

Yes, indeed.
Conceivably we could have a mechanism to let the developer force Mesa
extensions off.

> There's nothing artificial about it.  Without GL_ARB_vertex_shader, that
> query *does not exist*.  Without fragment shader (or program) support
> *and* either vertex or geometry shader (or program) support, there is no
> sense in "combined" texture units.  The fragment texture units are
> combined with nothing.

The fact is that at least Gallium does this unconditionally:
   c->MaxCombinedTextureImageUnits
      = _min(screen->get_param(screen, PIPE_CAP_MAX_COMBINED_SAMPLERS),
             MAX_COMBINED_TEXTURE_IMAGE_UNITS);

and even drivers like r200 do:
ctx->Const.MaxCombinedTextureImageUnits = ctx->Const.MaxTextureUnits

So we do have a driver-provided value for
MAX_COMBINED_TEXTURE_IMAGE_UNITS and could expose it.

Now thinking again about it, I see your point: it may best to not
expose the query if we don't expose any extension using it, so the
application does not rely on the query being always available, which
would not be guaranteed on other implementations.

However, there is also the other approach of exposing all possible
information via queries, even if the extensions that define them are
not completely supported and thus not exposed. This has the advantage
of being conceptually cleaner: the existence of hardware vertex
texture units, for instance, is conceptually independent of what
programming models OpenGL exposes.

It all depends on whether one sees the queries as mainly specifying
hardware properties or mainly as being values to be plugged in the
OpenGL specification (but obviously, the spec must be respected, so
you can't expose the hardware limit if you don't support it in any
programming model).