Hi all,
While debugging an issue impacting OpenGLOn12 support for the Dolphin emulator
on Windows (https://gitlab.freedesktop.org/mesa/mesa/-/issues/4050), I
discovered a bug in Mesa's non-ELF-TLS path. I've got a merge request which
will fix it (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9222),
but I wanted to get input from maintainers for non-Windows platforms that it
would also impact. From the root meson.build, it looks like this is BSD
(FreeBSD/OpenBSD) and Haiku.
The bug is:
#define GET_DISPATCH() \
(likely(_glapi_Dispatch) ? _glapi_Dispatch : _glapi_get_dispatch())
#define GET_CURRENT_CONTEXT(C) struct gl_context *C = (struct gl_context *) \
(likely(_glapi_Context) ? _glapi_Context : _glapi_get_context())
The idea is that as an optimization, if the app is single-threaded, a global is
used instead thread-local data. Once the app uses a second thread, that global
is nulled out and we fall back to using thread-local data for the
dispatch/context storage.
However if the app calls anything which attempts to look up the current
dispatch/context before entering this multi-threaded mode, it can get the wrong
value, and this can result in hard-to-track-down bugs (like a thread that
should issue no-op commands actually affecting another thread). In
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7280, Erik fixed the
getter functions to correctly handle a thread which isn't using GL in the
single-threaded mode, and return NULL or a dummy dispatch, but these macros
still have the same exact bug. As a side note, I don't understand why the
macros and functions both had the same short-circuit logic...
So here's the tradeoff: a correctness fix which should almost never be needed
but causes hard-to-debug problems when it is needed, vs a minor performance
impact (getting the current thread ID) for single-threaded GL applications,
only on BSD/Haiku platforms - since I also plan to take Windows off of this
path. I think this is the right change to make, but I'd love to get an ack from
folks who care about Mesa on these platforms.
Thanks,
-Jesse
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
