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 <[email protected]>
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
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
