On Fri, May 17, 2002 at 12:30:56AM +0100, Keith Whitwell wrote:
> > BTW: Last time I looked at libGL (in March), these were things which I
> > came over:
> > 1) libGL should IMHO use a version script (at least an anonymous one
> >if you want to avoid assigning a specific GL_x.y symbol version
A question about the __thread stuff: does it require -fPIC? What
happens if you don't compile a library with -fPIC, and have __thread
variables declared in that library?
-- Gareth
___
Have big pipes? SourceForge.net is looking for d
Gareth Hughes wrote:
>
> Let's be clear about what I'm proposing: you agree to reserve an
> 8*sizeof(void *) block at a well-defined and well-known offset in the
> TCB.
Of course, I should add that space for such a block exists, and has
existed for some time. My proposal requires no real cha
Ulrich Drepper wrote:
>
> Everything which is not part of glibc is third-party. It's the same as
> if some program would require access to internal data structures of
> libGL. There are several different layouts of the thread descriptor and
> it's only getting worse. The actual layout doesn't
On Thu, 2002-05-16 at 17:54, Gareth Hughes wrote:
> What do you mean, a third party program? We're talking about a system
> library (libGL.so) here.
Everything which is not part of glibc is third-party. It's the same as
if some program would require access to internal data structures of
libGL
Ulrich Drepper wrote:
>
> This is the only way you'll get access to thread-local storage. It is
> out of question to allow third party program peek and poke into the
> thread descriptor.
What do you mean, a third party program? We're talking about a system
library (libGL.so) here. There is a
On Thu, 2002-05-16 at 15:41, Gareth Hughes wrote:
> I would like to propose a small change to the pthread_descr structure in
> the latest LinuxThreads code, to better support OpenGL on GNU/Linux
> systems (particularly on x86, but not excluding other platforms). The
> purpose of this patch is to
Jakub Jelinek wrote:
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
I should a
Gareth Hughes wrote:
>
> Keith Whitwell wrote:
> >>
> >>2) last time I looked, libGL.so was linked unconditionally against
> >> libpthread. This is punnishing all non-threaded apps, weak undefined
> >> symbols work very well
> >
> >
> > This is because we currently use the standard way of ge
Keith Whitwell wrote:
>>
>>2) last time I looked, libGL.so was linked unconditionally against
>> libpthread. This is punnishing all non-threaded apps, weak undefined
>> symbols work very well
>
>
> This is because we currently use the standard way of getting thread-local-data
> and detectin
Jakub Jelinek wrote:
>
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
> (ie. p
Jakub Jelinek wrote:
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
> (ie. prep
Hi!
What percentage of applications use different dispatch
tables among its threads? How often do dispatch table changes
occur? If both of these are fairly low, computing a dispatch table
in an awx section at dispatch table switch time might be fastest
(ie. prepare something like:
.section dispat
Leif,
On 2002.05.16 23:34 Leif Delgass wrote:
> Jose,
>
> In reading this it just occurred to me what the flaw in my code was. I
> was setting up the descriptor table for a new pass _before_ waiting for
> the last one to complete, so there was a race condition. If I wait for
> idle _before_, I
I would like to propose a small change to the pthread_descr structure in
the latest LinuxThreads code, to better support OpenGL on GNU/Linux
systems (particularly on x86, but not excluding other platforms). The
purpose of this patch is to provide efficient thread-local storage for
both libGL itse
Jose,
In reading this it just occurred to me what the flaw in my code was. I
was setting up the descriptor table for a new pass _before_ waiting for
the last one to complete, so there was a race condition. If I wait for
idle _before_, I get no lockups, but the framerate drops. So here's what
I
On Thu, 16 May 2002, Jens Owen wrote:
>Date: Thu, 16 May 2002 14:07:52 -0600
>From: Jens Owen <[EMAIL PROTECTED]>
>To: Mike Harris <[EMAIL PROTECTED]>
>Cc: dri-devel <[EMAIL PROTECTED]>
>Content-Type: multipart/mixed;
> boundary="DC5CF5F0FB9AF888B9E756FE"
>Subject: [Fwd: [Xpert][PATCH
On 2002.05.15 00:33 José Fonseca wrote:
> ... I still have to workout more details:
>
> a) check if there is no other buffering besides the FIFO going on.
> This can only be checked by making a full proof of concept example and
> check if nothing goes wrong.
>
I used one DMA buffer (as I do
Mike,
Can you test whether this patch fixes your problems w/V3 in high res
modes?
If this fixes it, then I like it better than the previous one you
sent--as it addresses the root of the problem.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /
Keith Whitwell wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi folks,
> >
> > Just a quick query about the state of the Radeon driver, as it appears
> > in XFree86-4.2. Seems to work like a dream, unless you have
> > simultaneous rendering to multiple contexts/windows, in which case
> > there's hu
On Thu, 2002-05-16 at 17:12, [EMAIL PROTECTED] wrote:
>
> Just a quick query about the state of the Radeon driver, as it appears
> in XFree86-4.2. Seems to work like a dream, unless you have
> simultaneous rendering to multiple contexts/windows, in which case
> there's huge corruption. It's easy
[EMAIL PROTECTED] wrote:
>
> Hi folks,
>
> Just a quick query about the state of the Radeon driver, as it appears
> in XFree86-4.2. Seems to work like a dream, unless you have
> simultaneous rendering to multiple contexts/windows, in which case
> there's huge corruption. It's easy to see, at lea
Hi folks,
Just a quick query about the state of the Radeon driver, as it appears
in XFree86-4.2. Seems to work like a dream, unless you have
simultaneous rendering to multiple contexts/windows, in which case
there's huge corruption. It's easy to see, at least on my system
(Mobility 7500/M7, XFree
On 2002.05.15 22:34 Jan Schmidt wrote:
>
>
> > ...
> >
> > The problem is that the existence of those dri-old files are the only
> > proof that anything was installed before. If we default to delete file
> > when there is no backup then someone mistakenly trying to restore with
> no
> > previous
On 2002.05.15 23:26 Sergey V. Udaltsov wrote:
> > Sergey, sorry for replying only now. For some time I was planning to
> apply
> That's OK. Everyone understands that actual work on the driver has
> incomparable higher priority.
>
> > The problem is that the existence of those dri-old files are th
On 2002.05.15 23:17 Ian Molton wrote:
> On Wed, 15 May 2002 22:42:25 +0100
> José Fonseca <[EMAIL PROTECTED]> wrote:
>
> > Ian,
> >
> > On 2002.05.15 21:39 Ian Molton wrote:
> > > ...
> > >
> > > Here are some things I think should be worked on:
> > >
> > > 1) I *NEED* info about what cards have
> Sergey, sorry for replying only now. For some time I was planning to apply
That's OK. Everyone understands that actual work on the driver has
incomparable higher priority.
> The problem is that the existence of those dri-old files are the only
> proof that anything was installed before. If we
27 matches
Mail list logo
