[Mesa-dev] [PATCH] mesa: Restore functionality to dispatch sanity test

[Brian Paul]

On 05/04/2015 12:32 PM, Ian Romanick wrote:
> On 04/29/2015 02:44 PM, Brian Paul wrote:
>> On 04/29/2015 02:53 PM, Ian Romanick wrote:
>>> On 04/29/2015 12:07 PM, Ian Romanick wrote:
>>>> From: Ian Romanick <ian.d.romanick at intel.com>
>>>>
>>>> Along with a couple secondary goals, the dispatch sanity test had two
>>>> major, primary goals.
>>>>
>>>> 1. Ensure that all functions part of an API version are set in the
>>>>      dispatch table.
>>>>
>>>> 2. Ensure that functions that cannot be part of an API version are not
>>>>      set in the dispatch table.
>>>>
>>>> Commit 4bdbb58 removed the tests ability to fulfill either of its
>>>
>>> This commit also breaks binary compatibility between old libGL and new
>>> DRI driver.
>>>
>>> $ EGL_LOG_LEVEL=debug es2_info
>>> libEGL debug: Native platform type: x11 (autodetected)
>>> libEGL debug: EGL search path is /opt/xorg-master-x86_64/lib64/egl
>>> libEGL debug: added egl_dri2 to module array
>>> libEGL debug: failed to open
>>> /home/idr/devel/graphics/Mesa/BUILD/10.4-64/lib64/i965_dri.so:
>>> /home/idr/devel/graphics/Mesa/BUILD/10.4-64/lib64/i965_dri.so:
>>> undefined symbol: _glapi_set_nop_handler
>>>
>>> That's not ok. :(
>>>
>>> Brian: Can you propose an alternate solution to your original problem
>>> that doesn't break compatibility?  Otherwise, I'm going to have to just
>>> revert 4bdbb58.
>>
>> Please hold off on that.  I'm going to be off-line until next week and
>> won't have time to work on this until then at the earliest.
>
> As it turns out, I spent the rest of the week sick in bed, so I held off
> on it. :)
>
>>>> primary goals by removing anything that used _mesa_generic_nop().  It
>>>> seems like the problem on Windows could have been resolved by adding the
>>>> NULL context pointer check from nop_handler to _mesa_generic_nop().
>>
>> Unfortunately, no.  The problem is the the OpenGL API uses __stdcall
>> convention on Windows (the callee has to restore the stack).  That means
>> plugging a single, generic no-op handler into all dispatch slots will
>> not work.  The no-op function will not properly clean up the stack and
>> we'll crash.  We found this with a professional CAD app on Windows so
>> the fix is critical to those users.
>
> Oh... that's annoying, but makes sense.
>
>> A temporary work-around may be to only call _glapi_set_nop_handler() for
>> Windows.  Then, maybe remove the #ifdef _WIN32 at some point down the road.
>
> Either that or condition it on DRI builds.  Other Mesa builds won't have
> this particular issue.  Other loader / driver interfaces are dynamic.
> If we really want to enable this feature in DRI builds, we can do it.
> It will just require someone to do a bunch of typing.
>
>> How often do you test mixing old libGL with newer drivers?  I've always
>> suspected this is a bit fragile.  Nobody else seems to have noticed.
>
> Periodically.  I generally have a bunch of Mesa branches built at once
> that I test for various things.  I mostly end up using mismatched
> libraries when I have to use EGL because, for some reason, using
> non-installed libEGL is really painful.

I've (finally) got a patch for this.  I'd appreciate it if you could 
test in your particular set-up, Ian.

-Brian