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



> 
> Yes, in coding up an example to send you all, this issue became clear to 
> me.  We need to define thread-local variables in libGL.so and reference 
> them from a dlopened driver backed.  The important functions that 
> reference these variables are often tiny (less than 10 instructions), so 
> a function call here is a killer.
> 
> However, here's a critical issue that came to my attention over the 
> weekend:  How do you generate code at runtime to reference __thread 
> variables?  Doing runtime code generation for the immediate mode API 
> calls in the driver backend is quite common (there's an example of this 
> in Keith's T&L driver for the Radeon, mentioned earlier in this thread). 
>  It's not clear to me how a library generating code to dereference a 
> __thread variable can know where that variable is.  Am I mistaken?
> 
> To give you an idea of how important runtime code generation is to 
> modern OpenGL drivers, my Viewperf scores are easily three or four times 
> faster with an online generated API front end (plus the optimizations 
> that this allows further down the pipe).

Gareth,

A simplified example of the dispatch & codegen layers sounds like an excellent 
way to get across the performance environment we're working in.  Let me know 
if I can help putting this together.

Keith


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