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