Fast thread-local storage for OpenGL drivers
jakub at redhat.com
Sat Feb 22 13:08:56 CST 2003
On Sat, Feb 22, 2003 at 10:32:05AM -0800, Gareth Hughes wrote:
> Two or three pointers. I'm pretty sure we use less than 8 pointers all up,
> although many of those aren't performance critical. Three of ours most
> definitely are, and it would be nice if moving to a couple more didn't break
> things. We only ever use thread-local pointers, never whole structs or
> anything like that.
What actually matters is the size of PT_TLS segment of the shared library
which defines those 2-3 __thread variables (I assume it is libGL.so,
When at least one of STT_TLS symbols from some dlopened library is accessed
using IE or LE model relocs, then this whole PT_TLS segment must
be put into the surplus area.
If possible, keep this at 2-4 pointers, so that other libraries can use
it for their performance critical things too if needed.
It would be good if the rest of __thread variables which aren't performance
critical is provided by some other library (and accessed always through GD or
> Will this be okay, considering that two shared libraries will need access to
> the variables (libGL.so itself and the driver backend)? Can you use IE or
> LE with variables that live in another shared library?
See above, it doesn't matter what all libraries use IE/LE relocs, it matters
what shared library provides those TLS symbols those relocs resolve to.
> Sure, the code itself isn't hard to understand. The problem is, at runtime,
> how do I know what code to generate to access a given __thread variable? Do
> I have do disassemble a function that accesses the variable to know the
> right model to use? Fixed offsets make this trivial, but maybe this isn't a
> real problem after all.
Forgot to say, the offsets are obviously constant (until you dlclose the
library which declares them).
If they weren't, one couldn't keep pointers to __thread variables around
in IE/LE models.
More information about the wine-devel