NVIDIA and TLS

[Gareth Hughes]

On Mon, 16 Jun 2003, Daniel Eischen wrote:
> 
> I see this as a problem with the OpenGL API.  You're trying
> to make something thread-safe that isn't by its nature.
> I would rather see OpenGL-MT with new interfaces that
> are by nature thread-safe.

Sorry, but this simply isn't going to happen.  People smarter
than you or I designed the API this way to allow for high
performance implementations on a wide variety of platforms.
There are very good reasons each API call doesn't take a
context parameter.  Imagine you have a bunch of threads, each
rendering part of a scene (and thus, executing the same code).
What you're suggesting amounts to the application having to
track the current context in a thread-safe manner (using
thread-local storage), and passing the current context into
each and every OpenGL API routine.  In complex scenes, made up
of many millions of vertices, that can add up to a huge amount
of overhead.  Instead, the designers split the window-system
specific part of the graphics library into its own module, and
this module handles all the context management stuff (like
creating, binding and deleting contexts).  The OpenGL core API
operates in conjuction with this window-system specifc library,
but does not need to worry about the details of this side of
things.

Without going into a huge amount of detail, the fact that
OpenGL is a state machine means things get very messy if the
current context can change with every API call.  The amount of
validation required is prohibitive -- imagine if you were
building a display list in one context, while rendering a scene
with the other context, with interleaved API calls.  This kind
of thing prevents direct-to-hardware fastpaths.  Many
implementations of OpenGL (particularly the really good ones)
write the data they receive from the application directly to
a DMA buffer or, in the early days, directly into the graphics
subsystem registers.  Imagine if we have a full hardware
implementation of the OpenGL machine -- a context switch
probably means reading out the current values of all the state
registers, saving them off somewhere, and reloading the new
context's state.  Not something you want to have to do on every
API call you receive.

A new graphics API is not the solution.  As we've said, this is
a well-studied and essentially solved problem.  The ELF TLS
standard is exactly that: a standard.  It is supported by
multiple operating systems on a wide variety of architectures,
probably all the architectures that FreeBSD supports.  Again, I
urge you to look at Ulrich Drepper's document if you haven't
done so already.

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