Date: Mon, 16 Jun 2003 15:43:53 -0700 From: Gareth Hughes <gareth@nvidia.com> To: 'Daniel Eischen' <eischen@pcnet.com>, Julian Elischer <julian@elischer.org> Cc: Andy Ritger <ARitger@nvidia.com> Subject: RE: NVIDIA and TLS Message-ID: <2D32959E172B8F4D9B02F68266BE421401A6D7D8@mail-sc-3.nvidia.com>
next in thread | raw e-mail | index | archive | help
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@nvidia.com) OpenGL Developer, NVIDIA Corporation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D32959E172B8F4D9B02F68266BE421401A6D7D8>