Re: OpenGL and the LinuxThreads pthread_descr structure

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

Jakub Jelinek wrote:
> Hi!
> 
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
> (ie. prepare something like:
> .section dispatch, "awx"
>   .align 8
> .globl glFoobar
> glFooBar:
>   jmp something
>   nop; nop; nop
> 
> and <something> would be changed whenever a dispatch table switch happens
> for all dispatch table members).

That's not really feasible, as the tables can change very frequently (as 
often as every glBegin/glEnd, or maybe even every function call between 
glBegin and glEnd).

Also, dispatch tables will *always* be different between threads, that's 
why they need to be accessed in a thread-safe manner.

Finally, rewriting the instructions like this will have very bad trace 
cache behaviour on the Pentium 4, where touching instructions that have 
already been decoded causes the entire trace cache to be flushed.

> BTW: Last time I looked at libGL (in March), these were things which I
> came over:
> 1) libGL should IMHO use a version script (at least an anonymous one
>    if you want to avoid assigning a specific GL_x.y symbol version to it),
>    that way you get rid of thousands of expensive run-time relocations

Can you explain this in more detail?  I'm not sure I understand what 
you're saying.

> 2) last time I looked, libGL.so was linked unconditionally against
>    libpthread. This is punnishing all non-threaded apps, weak undefined
>    symbols work very well

I agree.

> 3) I don't think building without -fpic is a good idea, 1) together with
>    other tricks might speed things up while avoiding DT_TEXTREL
>    overhead

Again, could you explain this in more detail?  Thanks.

-- Gareth