From owner-freebsd-threads@FreeBSD.ORG Mon Jun 16 17:30:11 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 1370037B401 for ; Mon, 16 Jun 2003 17:30:11 -0700 (PDT) Received: from sccrmhc13.attbi.com (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C17443F75 for ; Mon, 16 Jun 2003 17:30:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (sccrmhc13) with ESMTP id <20030616220005016001jerte>; Mon, 16 Jun 2003 22:00:05 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA21769; Mon, 16 Jun 2003 15:00:01 -0700 (PDT) Date: Mon, 16 Jun 2003 14:59:59 -0700 (PDT) From: Julian Elischer To: Gareth Hughes In-Reply-To: <2D32959E172B8F4D9B02F68266BE421401A6D7CD@mail-sc-3.nvidia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: zander@mail.minion.de cc: Daniel Eischen cc: Andy Ritger 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 00:30:11 -0000 On Mon, 16 Jun 2003, Gareth Hughes wrote: > On Mon, 16 Jun 2003, Andy Ritger wrote: > > > > So from an OpenGL point of view, here are several alternatives that > > I see for atleast the near term: > > > > - make NVIDIA's OpenGL implementation not thread-safe (just > > use global data rather that thread-local data) > > > > - accept the performance hit of using pthread_getspecific() > > on FreeBSD. From talking to other OpenGL engineers, > > conservative estimates of the performance impact on > > applications like viewperf range from 10% - 15%. I'd like > > to quantify that, but certainly there will be a performance > > penalty. > > And these are *very* conservative estimates -- you're essentially adding a > function call into a path that is, on average, less than ten instructions > per OpenGL API call, where the number of API calls per frame is upward of 3 > million (3 calls per vertex, over a million vertices for some Viewperf > benchmarks). The API was designed this way for a reason, and fast > thread-local storage is a fundamental part of a high performance > implementation. Unfortunatly you are making an assumption about the threads that you are only able to make in Linux "by chance" as they did something else for their TLS. I gather that you don't keep a local variable pointed to your local drawing context, but just use the 'global' style of programming but using %gs as a 'roll-your-own' version of 'local context'. Can you just grab %gs on Microsoft? I thought they were going to be using it for their TLS too. BTW Have you looked at the speed of that? At one time it was a lot slower to dereference things through %gs than it was to simply have a normal register allocated to the task (e.g. %esi) as would be done normally. I don't know if that is true with any modern machines though. HOWEVER.. as far as we know we still have %fs unused.... Maybe we could just switch registers :-) (that too is of course non portable too but.....) BTW what do you do for ia64/alpha/amd64 archtectures? > > -- > Gareth Hughes (gareth@nvidia.com) > OpenGL Developer, NVIDIA Corporation > _______________________________________________ > 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" >