NVIDIA and TLS

[Gareth Hughes]

On Mon, 16 Jun 2003, Julian Elischer wrote:
> 
> I think what Dan is saying is that there is a lot more to making 
> a program thread-safe than just banging __thread before global 
> variables.

No question.  But, the __thread keyword is the best way to access
thread local data that I've seen.

> I think that it is sad that OpenGL has been implemented this way rather
> than passing an "our state" variable to each API call as is usually
> done.  Because in the real world the market leader decides the rules
> and because Linux has decided to make the TLS hack standard, that means
> that many peolpe will use it. This means that the posix standard
> basically goes into the trash basket of history.

Please have a little faith, and trust me when I say some of the
top people in the field of computer graphics, each with (now)
decades of experience with software and hardware implementations
of the 3D graphics pipeline, knew what they were doing when they
designed the OpenGL API.  It didn't become the only non-Microsoft
graphics API by accident (and at the time of its release, every
vendor basically had their own API).  I've been working on OpenGL
implementations for years, so please trust me when I say it's
done this way for very, very good reasons.  It seems like it'll
take a lot longer for me to convince you of this, so please just
take my word for it.

> If the lowest level calls took the 'current drawing context' (or
> whatever you call it) as an argument, then it wouldn't matter so much
> how it was originally derived. An occasional function call to 
> derive it
> would be ok. it's the fact that you decide to derive it from first
> principles every time rather than caching it that is the problem.

I have no idea what you're trying to say here.  It's critical that
an implementation of OpenGL be able to "cache away" the current
context.  Context switching is a very heavy-weight operation in
OpenGL.  There are very good reasons why this is so, as I touched
upon in an earlier email.  Here's another example: what if every
time you switched contexts, you had to free up your video memory
heap, to make room for the back/depth/stencil buffers and textures
for the new context?  Do you want to do this after you render every
triangle?  I can go on and on about why the design decisions were
made.

> __thread can easily be derived in an efficient manner in a library 
> independent manner using an entrypoint, but making it 
> important to do it in 1 machine instruction is not possible in a
> library independent manner. I think that this is a BAD THING
> even if we end up having to do it somehow..

If FreeBSD supported __thread variables (ELF TLS), then the NVIDIA
driver would use them, period.  If you can't provide a single
instruction access model like Linux and other platforms can, then
you'll simply have a slower implementation of OpenGL on your
platform.  It's disappointing that you're designing a system that
can't support the fastest TLS access model, but, so be it.

> BTW in my previous comment re: wine and OpenGL
> does wine link with openGL? If not I'd just go for using %fs
> for now :-)

Yes, Wine uses OpenGL.

-- 
Gareth Hughes (gareth at nvidia.com)
OpenGL Developer, NVIDIA Corporation