<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While debugging an issue impacting OpenGLOn12 support for the Dolphin emulator on Windows (<a href="https://gitlab.freedesktop.org/mesa/mesa/-/issues/4050">https://gitlab.freedesktop.org/mesa/mesa/-/issues/4050</a>), I discovered a bug
in Mesa’s non-ELF-TLS path. I’ve got a merge request which will fix it (<a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9222">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9222</a>), 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The bug is:<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">#define GET_DISPATCH() \<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> (likely(_glapi_Dispatch) ? _glapi_Dispatch : _glapi_get_dispatch())<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">#define GET_CURRENT_CONTEXT(C) struct gl_context *C = (struct gl_context *) \<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> (likely(_glapi_Context) ? _glapi_Context : _glapi_get_context())<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7280">
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7280</a>, Erik fixed the getter
<u>functions</u> 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…<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">-Jesse<o:p></o:p></p>
</div>
</body>
</html>