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
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 what features supported
On 2002.05.15 22:34 Jan Schmidt wrote:
quote who=Jos? Fonseca
...
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
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,
[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 least on
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 to
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 huge corruption.
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] /
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 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
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
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. prepare
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. prepare
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 detecting
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 also
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 getting
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
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 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.
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
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
21 matches
Mail list logo
