[Mesa-dev] new dispatch generator broke with Marek's parallel compile commit

[Ian Romanick]

On 4/2/19 4:43 AM, Emil Velikov wrote:
> On Tue, 2 Apr 2019 at 04:55, Dave Airlie <airlied at gmail.com> wrote:
>>
>> On Tue, 2 Apr 2019 at 11:24, Dave Airlie <airlied at gmail.com> wrote:
>>>
>>> Marek's commit to add ARB_parallel_shader_compile broke some es1 tests
>>> in the Intel CI.
>>>
>>> It appears the whatever generates the es1api isn't consistent, for
>>> example glTranslatex on my local system is 1405 in es1api but is 1406
>>> in the gl api.
>>>
>>> I'm no expert on this area, Emil any ideas?
>>
>> This seems to be due the new registry xml parser, I'm not sure how
>> broken it is, but it seems like it's a bit busted, and nobody tested
>> the scenario where a new function gets introduced in the middle.
>>
>> It looks like static_data.py has a limit on the offsets it cares
>> about, I thought adding static offsets for these functions would help
>> here, but it appears currently it all just work by luck, that the
>> static offsets work out to be the same as ones generated by gl_XML.py
>> for values above MAX_OFFSETS.
>>
>> I've got a hacky patch that makes it work here, that increases
>> MAX_OFFSETS to 1420, adds a new entry to the end for the new APIs, but
>> really I think the current code is broken, and is happening to work
>> out, but I'm hoping I'm just missing something obvious and it'll be a
>> one line fix for Emil.
>>
> As you have noticed the old generator would add entries to the glapi
> table in arbitrary order.
> Meaning that the ABI between dri/glapi/libGL* would break every now and then.
> 
> In more detail - libGL* would expect glFooBar at offset X, while the
> function is at Y according to glapi and the dri module sets the
> dispatch at Y. Latter uses a combination of fixed offset and dynamic
> offset lookup.

This doesn't make sense to me.  Can you explain more?  There are only
two parts.  There's the loader, and there's the driver.  The loader
assigns locations either at compile-time or at run-time.  The driver
queries the locations of functions that it will provide.  All functions
that the loader knows about should realistically have a dispatch
location set at compile time.  The loader should only generate new
locations at run-time if the application or driver asks for a function
that it does not know.

For things that don't have a static dispatch location set in the XML,
the loader is free to assign any location is pleases, but that location
must be consistent across all APIs because a single application can
create contexts from every possible API in the same address space, but
glXGetProcAddress or eglGetProcAddress are API agnostic.

If there is any possibility for a single function to have different
dispatch locations in different APIs, then the single most fundamental
invariant of the entire dispatch table system is being violated.  That
is a pretty catastrophic failure.

> Currently ES* is ported to the new generator and I have some patches
> for libGL and glapi, but no DRI modules just yet.
> A reasonable short term fix is to update the old generator to honour
> the full static_data table.
> 
> I'll have a look at that and updating the libGL/libglapi patches.
> 
> Thanks
> Emil
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>