[Mesa-dev] [PATCH 00/20] glapi yak shaving and GLES 3.1 enabling

Emil Velikov emil.l.velikov at gmail.com
Fri May 15 15:37:08 PDT 2015

On 15/05/15 18:29, Ian Romanick wrote:
> On 05/14/2015 03:01 PM, Emil Velikov wrote:
>> Hi Ian,
>> On 13/05/15 19:44, Ian Romanick wrote:
>>> We've known for a long time that having all those tags in the <function>
>>> entries in the XML is bad.  For example, people cut-and-paste for
>>> everything, and, as a result, we export a bunch of functions that we
>>> should not.  We also really want to just use the Khronos XML.
>>> This series takes a couple small steps towards that.
>>> Patches 1 and 2 are just a couple of clean-ups to prevent regressions in
>>> later patches.
>>> Patches 3, 13, 14, 15, 16, and 17 remove the offset= tags from the XML.
>>> Patch 15 was quite large, so it was trimmed.
>>> Patches 4, 5, and 6 remove the static_dispatch= tags from the XML.
>>> Patch 5 was quite large, so it was trimmed.
>>> Patches 7 through 12 un-export a bunch of static dispatch functions.  At
>>> the end, we only export the functions that Mesa 10.3 and NVIDIA and AMD
>>> export (with a couple minor exceptions noted in patches 8 and 11.
>> What are your thoughts on having patches 01-17 for 10.6 ? I would
>> _really_ love if they make it, plus I'm open on picking them after the
>> branch point.
> I'd prefer to land the whole lot, but I'll take what I can get. :)
It seems that shoving both GL and GLES version overrides under
MESA_GL_VERSION_OVERRIDE won't be as flexible plus it might backfire.
Won't the things be simpler if MESA_GLES_VERSION_OVERRIDE is introduced ?

>> Other than the comment in patch 02 I did not spot anything wrong with
>> the yak. Admittedly I did stay away from the mapi magic for quite some time.
> With the changes to the commit message of patch 2, is that a R-b on the
> series?
My python-foo is a bit short, although I checked the catalyst + mesa
10.3 10.4 and 10.5 lists. FWIW you can add to 01-17 incl.

Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>


More information about the mesa-dev mailing list