[Mesa-dev] Non-ELF-TLS (BSD/Haiku) Performance

[Jesse Natalie]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20210223/f4d456c1/attachment.htm>