Jakub Jelinek wrote:
> On Thu, May 16, 2002 at 08:08:02PM -0700, Gareth Hughes wrote:
>
>>Let's be clear about what I'm proposing: you agree to reserve an
>>8*sizeof(void *) block at a well-defined and well-known offset in the
>>TCB. OpenGL is free to access that block, but only that block.
>
>
> But you define no way how libraries can acquire some offset in
> it for its exclusive use, so basically you want a libGL private TCB block.
Yes, that's exactly what I'm proposing.
Having a fixed-size block at a well-known location allows both libGL.so
and the driver backends to reference things like the current context at
p_libgl_specific[0] (p_header.__padding[8] today), or in assembly:
movl %gs:32,%eax
Other variables like the dispatch pointer, GLX context and so on would
be referenced in the same manner.
The thing is, this works on all implementations from glibc-2.2 onwards.
It doesn't require a bleeding-edge binutils or glibc, and it's faster
than the __thread support. It requires no functional code changes in
LinuxThreads (you could even implement the reservation of space with a
comment specifying that p_header.__padding[8-15] in pthread_descr are
for libGL internal use only).
You may argue that this places an unmanageable maintenance burden on
glibc. This side of the problem boils down to the following: you could
completely reimplement LinuxThreads, changing the contents of the
pthread_descr structure (even redo the regular pthreads TLS storage), if
you just start with the following:
struct _pthread_descr_struct {
union {
/* use this space if required */
void *__padding[8];
} p_header;
/* libGL.so internal use only */
void *p_libgl_specific[8];
/* go crazy from here down */
...
};
You'll always have some form of TCB, all I'm asking for is that you
reserve that chunk of space for libGL at the start.
Don't get me wrong -- I think the __thread stuff is great and certainly
a step in the right direction. However, as I described in my original
posting, OpenGL has special requirements when dealing with thread local
storage. In such a performance-critical setting, I'd agree with Keith
when saying a little bit of special treatment goes a long way.
-- Gareth
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
