NVIDIA and TLS

[Gareth Hughes]

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 at nvidia.com)
OpenGL Developer, NVIDIA Corporation