Date: Wed, 18 Jun 2003 00:40:36 -0400 (EDT) From: Andy Ritger <ARitger@nvidia.com> To: Julian Elischer <julian@elischer.org> Cc: 'Daniel Eischen' <eischen@pcnet.com> Subject: RE: NVIDIA and TLS Message-ID: <Pine.LNX.4.44.0306180029550.22572-100000@stravinsky.nvidia.com> In-Reply-To: <Pine.BSF.4.21.0306171721190.31025-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Jun 2003, Julian Elischer wrote: > > > On Tue, 17 Jun 2003, Andy Ritger wrote: > > > > > > > On Tue, 17 Jun 2003, Julian Elischer wrote: > > > > > > > > > > > On Tue, 17 Jun 2003, Gareth Hughes wrote: > > > > > > > Terry Lambert wrote: > > > > > > > > > > > > [a lot of stuff] > > > > > > Gareth, thanks for puting up with us and showing considerable patience. > > > > And thanks for putting up with Gareth ;) > > > > > I think we can make an 'efficient (though possibly not quite the 1 > > > instruction possible in a static linked linux binary) __thread > > > implimentation. > > > > Sure. > > > > > We can possibly do 1 instruction in the 1:1 library but that would leave > > > binary compatibility with the other libraries out the window. > > > > I'll try to keep on eye on the technical discussion (looks like it > > moved to current@freebsd.org), but please keep us in the loop. > > > > For the short term, I'll probably leave the NVIDIA libGL as is > > (hijacking %gs), and document it as such in our README. Once the > > TLS decisions are worked out on FreeBSD, we'll propogate the > > appropriate changes to the NVIDIA OpenGL driver. > > It seems to me that what you have done is to "roll-your-own" TLS for > FreeBSD. Can you detail in such a way that we don't have to read the > entire source, what you have done (e.g. with %gs). The way the "home-brewed" TLS in the NVIDIA FreeBSD OpenGL driver currently works is that for each thread we allocate a structure to store all the thread local data we need, plug it into a selector in the LDT by calling i386_set_ldt(), and then set that thread's selector index in %gs. Retrieving the appropriate TLS data is done by looking up the structure from %gs, and looking at the offsetof the relevant field in the structure. Of course, this assumes that %gs is context-switched per thread. I assume the 1:1 threading library does something similar, plugging a structure into an LDT, and then setting the LDT index in %gs? One stopgap would be to designate some padding at a fixed location in your structure, which an OpenGL implementation can "hijack" to store its own TLS data. There were earlier objections to this hack, so I'm not sure if this is something you'd consider as a stopgap... I also don't see how this stopgap could be implemented in the other thread libraries. Thanks, - Andy > We may be able to make a "stopgap" version that can co-exist with the > threading libraries if we know exactly how you were thinking when you > did it.. (i.e. maybe we can 'co-operate' on %gx instead of > just exploding).. Real TLS may take a while if we need to rewrite parts > of our run-time linker. > > > > > > Thanks, > > - Andy > > > > > I think that it is a pitty that the openGL ABI doesn't carry around a > > > 'context' argument on all calls but it's not going to change and > > > we have to use what is there. > > > > > > > > Julian > > > > > > > > > > > > > > > > > _______________________________________________ > > freebsd-threads@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0306180029550.22572-100000>