[Mesa-dev] [PATCH] mesa: Restore functionality to dispatch sanity test
brianp at vmware.com
Fri May 15 08:13:12 PDT 2015
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
>>> 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.
More information about the mesa-dev