[Mesa-dev] [PATCH 0/6] Some glapi clean-up releated to GLES

[Ian Romanick]

On 03/31/2014 02:48 PM, Ian Romanick wrote:
> On 03/27/2014 04:10 PM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>>
>>> Tomorrow or Friday I'm going to send out the last of the
>>> GL_ARB_separate_shader_objects patches.  Shortly after that, I will send
>>> out patches to enable GL_EXT_separate_shader_objects on GLES.  This EXT
>>> is the GLES subset of the ARB extension.
>>>
>>> In preparing for this new extension, I noticed the old problem that any
>>> extension function that aliases a core function (whether it is core in
>>> GLES or desktop GL) isn't hidden.  This series should fix that.
>>>
>>> Longer term, I'd like to change the generation of libGL*.  Right now all
>>> the information describing the interfaces and the information selecting
>>> the exposed interfaces in combined in a single XML database.  As patch 4
>>> shows, that makes it impossible to have a single function that is
>>> exposed in one API but hidden in another.  I'd like to pull all the
>>> "offset", "static_dispatch", "glx_ignore", and "exec" information out
>>> into separate files.
>>>
>>> This will mean that adding a new extension will require changes to
>>> multiple files.  The usual XML bits will need to be added.  Entries will
>>> need to be add to per-libGL* files, an "exec" file, and an "offsets".
>>> We can probably get rid of the offsets file since no functions will ever
>>> be added that have static offsets.
>>
>> If we're going to be doing major rework of the XML, I'd *really* like to
>> see us move to using the upstream XML for as much as possible.
> 
> Yeah, me too.  I think once we get a bunch of the Mesa-specific
> information out of the existing XML, that will be possible.

There may be one (at least temporary) roadblock to this plan.  There is
a LOT of information in our XML that is necessary to generate GLX
protocol code.  For example, our enums are decorated with information
about which Get functions can use them and how much data they return.

    <enum name="TEXTURE_RED_SIZE" count="1"  value="0x805C">
        <size name="GetTexLevelParameterfv" mode="get"/>
        <size name="GetTexLevelParameteriv" mode="get"/>
    </enum>

We have similar information for enums that are used for setter functions.

    <enum name="TEXTURE_PRIORITY" count="1"  value="0x8066">
        <size name="TexParameterfv"/>
        <size name="TexParameteriv"/>
        <size name="GetTexParameterfv" mode="get"/>
        <size name="GetTexParameteriv" mode="get"/>
    </enum>

The information about the setter and getter functions is indirectly
encoded in the Khronos XML.  The enums are put in named groups (e.g.,
"GetTextureParameter"), and function parameters are tagged with a group
name.

There's a bunch of other GLX information (image protocol) that is also
missing from the Khronos XML.  It's also missing information about which
render functions can use render_large.

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140402/e4e2aaeb/attachment.sig>