Date: Sat, 14 Jun 2003 18:45:59 -0400 (EDT) From: Andy Ritger <ARitger@nvidia.com> To: threads@freebsd.org Cc: Gareth Hughes <gareth@nvidia.com> Subject: NVIDIA and TLS Message-ID: <Pine.LNX.4.44.0306141841260.29979-100000@stravinsky.nvidia.com>
next in thread | raw e-mail | index | archive | help
I'd like to add a few comments to what has recently been said here
and on freebsd-current to clarify what the %gs register is used
for by the NVIDIA driver and what ideally would be done to allow
the NVIDIA driver to coexist with FreeBSD threading implementations.
The NVIDIA driver does not need %gs to maintain internal state in the
kernel; rather, it uses it to maintain fast thread local data for the
OpenGL implementation, where it is critically important to have fast
(single instruction) access to such data.
When the NVIDIA driver was initially ported to FreeBSD, two
threading implementations were available (linux-threads, libc_r),
but neither of them supported static thread local storage or made
use of it internally.
The situation was similar to what it had been on Linux for some
time. On Linux, the NVIDIA driver today deals with three possible and
incompatible configurations: the original pthreads without fast TLS
support, pthreads with internal TLS support, and current implentations
which use static TLS internally and provide a mechanism to allow
both applications and libraries to store their own thread local data.
The linux_sysvec.c change which Christian Zander made available
on his website is related to the mechanism built into the NVIDIA
Linux driver that decides which configuration is used; without this
change, this mechanism fails from within the Linux ABI compatibility
environment. This is not related to the native NVIDIA FreeBSD
OpenGL implementation.
The current NVIDIA FreeBSD driver only supports one threading library
on FreeBSD for thread-safe, multi-threaded OpenGL applications: the
FreeBSD port of linux-threads. The NVIDIA FreeBSD OpenGL driver uses
both the i386_set_ldt system call and %gs to support high performance
native OpenGL applications.
This obviously conflicts with new FreeBSD threading implementation(s)
if they are also making use of %gs to store and access thread local
data. To solve this problem, ideally support for static TLS similar
to that recently added to glibc would be implemented by FreeBSD
threading libraries and supported by the NVIDIA FreeBSD driver.
A good reference and source for ideas is Ulrich Drepper's ELF
TLS paper:
http://people.redhat.com/drepper/tls.pdf.
If this or a comparable model were implemented on FreeBSD, both
applications and libraries could be ported more easily between
Linux and FreeBSD. Admittedly, I am not yet familiar with libkse
or libthr... perhaps such a mechanism already exists? (where could
I learn more about libkse and libthr?)
If you are interested, I can provide more details on why fast thread
local storage is so important to an OpenGL implementation.
Thanks,
- Andy Ritger
(Gareth, Christian, and I are not subscribed to this list, so please
CC us)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0306141841260.29979-100000>