On Wed, Jun 23, 2004 at 10:18:32AM -0600, Brian Paul wrote:
> 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.
I think Mandrake 10 also supports it.
Alan.
-------------------------------------------------------
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
