[Mesa-dev] [PATCH] Add support for GL_EXT_unpack_subimage on GLES2

[Neil Roberts]

On Thu, 22 Mar 2012 10:56:09 -0700, Ian Romanick <idr at freedesktop.org> wrote:

> I'm not a fan of the wrappers generated from APIspec.xml.  It allowed 
> quick implementation of the extra enum rejection required by ES, but 
> it's a real hassle.

I don't track the Mesa development that much but I'm not sure what
you're getting at here. The API spec file seems quite nice to me or at
least it's much better than writing the error checks by hand which I
think would be quite error-prone.

> Is there any chance you could code up a quick piglit test that verifies 
> that 1, 2, 4, and 8 can be used if the extension is available but are 
> rejected if it is not?

The 1, 2, 4 and 8 parts don't relate to the extension but instead are
values for GL_{UN,}PACK_ALIGNMENT. The alignment settings were already
there as they are a core part of the GLES2 spec. The patch makes a
duplicate of these checks because previously these were the only valid
values for the 'param' argument regardless of the 'pname' argument.
However now there there is a third enum accepted for the pname argument
so the error checks need to be restricted to the previous two enums.

I guess it might be useful to write a piglit test to verify that
GL_UNPACK_ROW_LENGTH and friends throw an error if the extension is not
available.

> When planning some of our work for the next couple months we talked
> about enabling some desktop-GL-on-ES extensions, but we eventually
> tabled the idea. Are there other of these extensions that you would
> find useful?

I had a quick skim through the extensions listed on khronos.org and I
couldn't see anything that we particularly need. However one thing that
is quite annoying on GLES2 for Cogl is that it doesn't support unsized
arrays in the GLSL. I'd be surprised if there is an extension for that
though.

> I want to make sure I understand this code. This causes additional
> checks for 1, 2, 4, and 8 to be generated. The assumption is that the
> other values are already invalid, and the core implementation will
> reject them (as it already does for desktop GL). Is that right?

The list of values is a whitelist of values so anything other than those
4 values will generate a GL_INVALID_VALUE error. This doesn't actually
generate any extra checks than were already there except for allowing
GL_UNPACK_ROW_LENGTH and the two skip enums. The generated code even
seems to coalesce the two sets of checks for valid alignment values into
one. Presumably it is comparing the sets of valid values and noticing
that they are the same?

Regards,
- Neil