Re: OpenGL and the LinuxThreads pthread_descr structure

[Gareth Hughes <gareth dot hughes at acm dot org>]

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