AGP has become very stable here since the radeon driver doesn't update
the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
Seems updating it 'too often' is no good, for whatever 'too often' may
mean.
I hate that. It should be fully stable or I would consider it
unuseable :(
On Thu, 2002-07-18 at 18:20, Benjamin Herrenschmidt wrote:
AGP has become very stable here since the radeon driver doesn't update
the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
Seems updating it 'too often' is no good, for whatever 'too often' may
mean.
I hate
On Wed, 2002-07-17 at 03:32, Henry Worth wrote:
Michel Dänzer wrote:
On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
Attached are patches for r128 on ppc. Rather little change to the r128 code
was needed once I gave up on the char arrays for the vertex colors, and
embraced the hw
On Wed, 2002-07-17 at 05:15, Henry Worth wrote:
Henry Worth wrote:
I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit
set and with the PACK*LE macros. And, the 2-d stuff seems to be working
and the textures do need the PACK*LE macros. So, perhaps the bit only
impacts the
On Tue, 16 Jul 2002, Leif Delgass wrote:
These look very good to me, I'll commit them. Leif, can you verify they
don't break x86? I'd be very surprised, but it wouldn't be the first
time. :)
I'll give these a try once I've updated my tree, I was testing from
binaries before.
The
On Wed, 2002-07-17 at 16:50, Leif Delgass wrote:
On Tue, 16 Jul 2002, Leif Delgass wrote:
These look very good to me, I'll commit them. Leif, can you verify they
don't break x86? I'd be very surprised, but it wouldn't be the first
time. :)
I'll give these a try once I've updated
Michel Dänzer wrote:
AGP has become very stable here since the radeon driver doesn't update
the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
Seems updating it 'too often' is no good, for whatever 'too often' may
mean.
Does this also involve the differences between the
I applied and retested it, looks good. One pedantic little change to
the diff
that I missed is attached, it might avoid future problems.
Another version to fix a typo.
Henry
--- r128-dri-endianness.diff.orig Wed Jul 17 12:02:48 2002
+++ r128-dri-endianness.diffWed Jul 17
On Wed, 2002-07-17 at 20:03, Henry Worth wrote:
Michel Dänzer wrote:
AGP has become very stable here since the radeon driver doesn't update
the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
Seems updating it 'too often' is no good, for whatever 'too often' may
mean.
Michel Dänzer wrote:
The intermediate variable isn't needed if one changes the macro argument
from v to e.g. v0. I've now basically copied those macros from the
radeon driver and updated the above patch to what I just committed.
Thanks for your fixes!
Took a look at the archive, I had tried
On Wed, 2002-07-17 at 23:15, Henry Worth wrote:
Michel Dänzer wrote:
The intermediate variable isn't needed if one changes the macro argument
from v to e.g. v0. I've now basically copied those macros from the
radeon driver and updated the above patch to what I just committed.
Thanks
On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
Attached are patches for r128 on ppc. Rather little change to the r128 code
was needed once I gave up on the char arrays for the vertex colors, and
embraced the hw specific ordered named fields provided in the *_color_t
provided by
Michel Dänzer wrote:
On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
Attached are patches for r128 on ppc. Rather little change to the r128 code
was needed once I gave up on the char arrays for the vertex colors, and
embraced the hw specific ordered named fields provided in the *_color_t
Michel Dänzer wrote:
Thank you for breaking the radeon and mach64 drivers on big endian
machines. ;) We've got to find a better solution here, I must confess I
still don't understand how it can not work with PACK*LE though. Maybe
the HOST_BIG_ENDIAN_EN bit in the DP_DATATYPE register (set in
Henry Worth wrote:
I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit
set and with the PACK*LE macros. And, the 2-d stuff seems to be working
and the textures do need the PACK*LE macros. So, perhaps the bit only
impacts the DMA blits used to load the texture subimages?
If
On Wed, 2002-07-17 at 03:57, Henry Worth wrote:
Michel Dänzer wrote:
Thank you for breaking the radeon and mach64 drivers on big endian
machines. ;) We've got to find a better solution here, I must confess I
still don't understand how it can not work with PACK*LE though. Maybe
the
On 17 Jul 2002, Michel Dänzer wrote:
On Wed, 2002-07-17 at 02:10, Henry Worth wrote:
Attached are patches for r128 on ppc. Rather little change to the r128 code
was needed once I gave up on the char arrays for the vertex colors, and
embraced the hw specific ordered named fields
Henry Worth wrote:
Henry Worth wrote:
I gave the driver a quick try without the HOST_BIG_ENDIAN_EN bit
set and with the PACK*LE macros. And, the 2-d stuff seems to be working
and the textures do need the PACK*LE macros. So, perhaps the bit only
impacts the DMA blits used to load the
18 matches
Mail list logo
