This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Dri-devel] Re: OpenGL and the LinuxThreads pthread_descr structure


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.

In some ways this *is* appropriate, or at least there is justification for
giving libGL.so some special treatment:  It is probably the biggest user of
thread local storage (perhaps excluding glibc itself).  By biggest, I mean
performs the largest number of retrievals of thread-local variables.

Many or most GL applications sit in a tight loop calling tiny functions which
do little more than jump to a thread-local handler function which sets a
single value in a thread-local structure. The devil is in the details, but it
often looks like this.  

It's also worthwhile to consider the complexity of the graphics hardware in
relation to the rest of the computer (there are often more transistors in the
GPU than the CPU), and the efforts that have been taken to maximize the
bandwidth of the connection between the two.  Libgl.so is special compared to
other libraries for the same reasons that we have AGP rather than just another
PCI slot.  

Graphics is special, it seems.  Considering the fraction of the *hardware* of
modern computers dedicated to making graphics go faster, is it too much to ask
for a few bytes in the pthread descriptor, or some other mechanism which is as
fast?

Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]