From owner-freebsd-threads@FreeBSD.ORG Sat Jun 14 15:14:47 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD91F37B401 for ; Sat, 14 Jun 2003 15:14:47 -0700 (PDT) Received: from hqemgate00.nvidia.com (hqemgate00.nvidia.com [216.228.112.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32CA643FA3 for ; Sat, 14 Jun 2003 15:14:45 -0700 (PDT) (envelope-from ARitger@nvidia.com) Received: from mail-sc-0.nvidia.com (Not Verified[172.16.217.105]) id ; Sat, 14 Jun 2003 15:18:02 -0700 Received: by mail-sc-0.nvidia.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Jun 2003 15:14:44 -0700 Received: from nvidia.com (BERNSTEIN [172.16.224.128]) by mail-sc-0.nvidia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MJR34166; Sat, 14 Jun 2003 15:14:36 -0700 From: Andy Ritger To: threads@freebsd.org Date: Sat, 14 Jun 2003 18:45:59 -0400 (EDT) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: zander@mail.minion.de cc: Gareth Hughes Subject: NVIDIA and TLS X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2003 22:14:48 -0000 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)