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 t_dd_ve
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 i
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?
>
>
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
>
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 loa
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
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
> > imp
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 th
On Wed, 2002-07-17 at 21:14, Henry Worth wrote:
> Michel Dänzer wrote:
>
> >
> >Thanks for testing. I've cleaned up the patch slightly to better fit
> >into the existing code and added a kludge for HOST_BIG_ENDIAN_EN:
> >
> >http://www.penguinppc.org/~daenzer/DRI/r128-dri-endianness.diff
> >
> >H
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' ma
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 t
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.
> >
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
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.
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
Michel Dänzer wrote:
>
>Thanks for testing. I've cleaned up the patch slightly to better fit
>into the existing code and added a kludge for HOST_BIG_ENDIAN_EN:
>
>http://www.penguinppc.org/~daenzer/DRI/r128-dri-endianness.diff
>
>Henry, if this works for you, I'll commit it.
>
I applied and ret
>
> 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 12
>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
20 matches
Mail list logo
