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
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
