This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [Dri-devel] Re: OpenGL and the LinuxThreads pthread_descr structure
Jakub Jelinek wrote:
> On Fri, May 17, 2002 at 01:17:22PM +0100, Keith Whitwell wrote:
>
>>The __indirect stuff is rarely used.
>>
>
> Ok, fine. But if it is rarely used, why isn't it -fpic?
The dispatch table in libGL.so is used all the time - this thread was started
by Gareth with discussion of an optimization to that code (which also applies
to another thread-local variable used by the 'driver.so' backend).
The __indirect stuff is just along for the ride. It's a fallback for
network-transparent rendering, broken configs, and a couple of actual useful
cases.
I don't think it can be split out completely however as we still have to send
a few packets off to the X server.
The use of sections you described earlier sounds like we can get that code to
be PIC and still have a fast dispatch, which is nice.
It sounds like you haven't looked at the driver backends - this is where most
of the code is. Our most up-to-date driver illustrates some of Gareth's
concerns and is on the tcl-0-0-branch of DRI CVS in the
lib/GL/mesa/src/drv/radeon directory. This does some of the runtime
code-generation and dispatch-flipping that he is talking about.
> Few more random things which might help the drivers:
> 1) using fprintf (stderr, ...) all around is a bad idea,
> that means 2 runtime relocations for each when not -fpic, much better
> take it offline into a separate .hidden function which will call
> vfprintf
That's reasonable. In a lot of cases these aren't compiled into release or
non-debug drivers, but in the tcl version, I've found it very helpful to keep
them in there.
> 2) use __builtin_expect if you know better than the compiler what's likely
> and what is unlikely executed
I'll have to look this one up too.
Keith