From owner-freebsd-threads@FreeBSD.ORG Tue Jun 17 02:13:06 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 0A0DA37B401 for ; Tue, 17 Jun 2003 02:13:06 -0700 (PDT) Received: from hqemgate00.nvidia.com (hqemgate00.nvidia.com [216.228.112.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D3743FB1 for ; Tue, 17 Jun 2003 02:13:05 -0700 (PDT) (envelope-from gareth@nvidia.com) Received: from mail-sc-0.nvidia.com (Not Verified[172.16.217.105]) id ; Tue, 17 Jun 2003 02:16:22 -0700 Received: by mail-sc-0.nvidia.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 02:13:00 -0700 Message-ID: <2D32959E172B8F4D9B02F68266BE421401A6D7EC@mail-sc-3.nvidia.com> From: Gareth Hughes To: 'Terry Lambert' , Alexander Kabaev Date: Tue, 17 Jun 2003 02:12:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain cc: threads@freebsd.org cc: zander@mail.minion.de cc: 'Julian Elischer' cc: Andy Ritger cc: 'Daniel Eischen' Subject: RE: 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: Tue, 17 Jun 2003 09:13:06 -0000 Terry Lambert wrote: > > Right now, he's said that he can't use %fs, because he has a > version of WINE that uses OpenGL to implement it's video, and > the threads people have said that he can't use %gs because it > points to a per-KSE value, not a per thread value, and there > are potentially many threads associated with each KSE, so it's > no good for TLS, only for KSELS. All versions of Wine use OpenGL for 3D graphics. > I've suggested that he use the compiler flags to reserve another > *different* register (not %fs and not %gs) for his purpose; the > compiler has explicit support for this. If he is wiling to burn > a register in order to get this functionality, it should be one > that's normally allocated for user programs to burn anyway. We're not willing to burn a register. Our libraries are not PIC for the same reason. > Julian has pointed out that the TLS data should probably be cached > following a return from a context switch as a result of the user > space threads scheduler, if there is one, scheduling the thread to > run; so far, it seems that Gareth has mistaken what Julian meant > by this (that the reload happen high up in the OpenGL code, using > an explicit call, to do the register switch, so that it's available > lower down; this would work with the %fs approach, without breaking > WINE). I must be completely misunderstanding you. What do you mean by "high level" and "low level" OpenGL code? > In addition, it seems that Gareth's Linux approach is assuming that > a thread which is involuntarily context switch will be run again, > when the next quantum becomes available. This is an invalid > assumption for libkse (though it's currently hacked, locally, by > most people to keep non-strict POSIX applications happy), and > could be an invalid assumption in Linux and libthr in FreeBSD, > should the scheduler code change in the future to recalculate > priority prior to giving the quantum to a particular thread. Why do you say that? -- Gareth Hughes (gareth@nvidia.com) OpenGL Developer, NVIDIA Corporation