Re: Moving forward with the TLS work

[Brian P. <bri...@tu...>]

Ian Romanick wrote:
> Ian Romanick wrote:
> 
>> I'm getting back to the TSL work, and I'd like to wrap it up as much 
>> as possible by the end of the week.  I sent a patch out of the current 
>> state of things a little bit ago.  Performance testing has shown that 
>> the new dispatch functions and the old, non-thread safe dispatch 
>> functions perform equally.  The difference between the two is within 
>> the error margin of the test.  That's the good news.
>>
>> The bad news is that the combination of a multithreaded app, with an 
>> "old" driver, and a "new" libGL will result in a segfault.  The code 
>> sets _glapi_Dispatch to NULL in the multithreaded case as a signal to 
>> call _glapi_get_dispatch.  When the code is fully converted to TLS, 
>> the call to _glapi_get_dispatch will be replaced with a 'movl 
>> %gs:_gl_DispatchTSD, %eax' or something similar.
>>
>> I want to maintain compatibility across the whole matrix of old / new 
>> libGL with old / new drivers.  I may be willing to sacrifice new 
>> driver + old libGL, but that's the only combination I'd be willing to 
>> give on.  I think we need to do 3 things to get there:
>>
>> 1. Keep the old meaning of _glapi_Dispatch.  This means that all the 
>> _ts_* functions and their support mechanism will have to be kept. :( 
>> However, it will only be needed for the DRI libGL.  The software 
>> rendering Mesa version won't need it.
> 
> 
> This turned out to not be as bad as I thought.  There is still the extra 
> dispatch table, but all of the function pointers in it point to the 
> regular dispatch functions.  In the multithreaded case, if an old driver 
> does _glapi_Dispatch->Vertex3fv, it will end up calling glVertex3fv, 
> which will see _glapi_DispatchTSD is NULL, which will call 
> _glapi_get_dispatch to get the real dispatch and call the real function.
> 
> The _ts_* functions are still gone.  Everyone is happy. :)
> 
> The one catch is that glapitemp.h (and the Python generator scripts) 
> were modified.  If NAME is not defined, glapitemp.h will not generate 
> the dispatch functions.  If DISPATCH_TABLE_NAME is defined, it will 
> still generate the dispatch table.
> 
>> 2. For non-TLS "new" code, implement a new variable called 
>> _glapi_DispatchTSD that implements the new behavior.  There will be a 
>> "weak" version of that variable, that is always NULL in dri_util.c. 
>> This should allow non-TLS "new" code to work with old libGL binaries.
> 
> 
> This is done and works perfectly.  The only problem *I* have with it is 
> the use of a GCC specific feature.  Of course, the whole TLS thing is 
> pretty GCC specific, so I guess this is somewhat moot.
> 
>> 3. TLS "new" code can do whatever it wants.  I imagine this will be a 
>> __thread variable called _glapi_tls_Dispatch or something similar.
> 
> 
> This part isn't done yet, but should be easy enough.
> 
> This patch also still requires you to manually generate glapi_x86.S by 
> doing:
> 
> cd src/mesa/glapi
> python2 ./gl_x86_asm.py > ../x86/glapi_x86.S
> 
> The other new thing in this patch is the state variable ThreadSafe is 
> gone.  Instead, the code universally uses "_glapi_DispatchTSD == NULL" 
> to determine if it is in multi-threaded mode.  Some other code in 
> glapi.c changes as a direct result.
> 
> If nobody raises any concerns, my intention is to commit these changes 
> *tomorrow* afternoon (23-June-2004).
> 
> The next two steps will be to start adding in some of the 
> 'visibility("hidden")' stuff and (of course) the TLS support.  I plan to 
> mostly follow Jakub's lead with two exceptions.  Instead of using 
> 'hidden' as the macro for '__attribute__ ((visibility("hidden"))', I'm 
> going to take a cue from the PowerPC glibc code and use 
> attribute_hidden.  I'm also going to pick a different name than 
> GLX_USE_TLS to enable compilation of the TLS code.  I haven't decide 
> what to use, though.

Ian, I haven't had time to follow this too closely.  A few questions:

1. Is thread safety in the GL API layer going to require TLS now? 
What about people who want thread safety but aren't using a version of 
Linux that supports TLS?

2. Which common Linux distros support TLS?  I believe RH9 and later 
do, but that's all I'm aware of.

-Brian