Re: [Dri-devel] Re: r128 PPC patches
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 my side, I've temporarily given up trying to understand what was going on. Does anybody have useful contacts at ATI that could help ? I have 2 possible ideas: - Some athlon-like cache aliasing issues, though I don't think PPCs do that aggressive prefetch accross page boundaries - Some magic skew value to set in the chip to compensate for some bus arbitration issues when mixing AGP master transfers and PCI slave transfers. Or maybe just disabling some of the AGP features like Fast Write... Ben. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
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 that. It should be fully stable or I would consider it unuseable :( Define 'fully stable' - no crash to infinity and beyond? ;) I can run for days without crashes on this TiBook, I consider that quite good. On my side, I've temporarily given up trying to understand what was going on. Does anybody have useful contacts at ATI that could help ? I have 2 possible ideas: - Some athlon-like cache aliasing issues, though I don't think PPCs do that aggressive prefetch accross page boundaries And in that case, I'd expect the problem to be (mostly) independent from driver changes. - Some magic skew value to set in the chip to compensate for some bus arbitration issues when mixing AGP master transfers and PCI slave transfers. Or maybe just disabling some of the AGP features like Fast Write... Something like that seems much more likely to me, seeing as throttling the ring write pointer updates helps a great deal. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
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 changes don't seem to break anything on x86. I tried with and without the texutil.c changes. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
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 my tree, I was testing from binaries before. The changes don't seem to break anything on x86. I tried with and without the texutil.c changes. 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. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: r128 PPC patches
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:03:34 2002
-120,7 +120,7
-} while (0)
+#define VERT_SET_RGBA( v, c ) \
+ do {\
-+ r128_color_t *vc = (r128_color_t *)v-ui[coloroffset]; \
++ r128_color_t *vc = (r128_color_t *)(v)-ui[coloroffset]; \
+ vc-blue = (c)[2]; \
+ vc-green = (c)[1]; \
+ vc-red = (c)[0]; \
Re: [Dri-devel] Re: r128 PPC patches
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 provided in the *_color_t provided by t_dd_vertex.h. 1) Revert PACK*LE from texutil.c as per previous emails. 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 R128EngineInit() in the 2D driver) is interfering, causing the texture data to be byte-swapped in the HOST_DATA registers? If so, your changes should not be really correct for 16 bit anyway. I've been there while playing with the various possibilities of fixing endianness in the radeon driver, it looked mostly good but e.g. the floor texture in armagetron showed the problem. I don't have r128 docs, so I'm not sure if it's analogous, but for mach64 we don't set HOST_BIG_ENDIAN_ENABLE in HOST_CNTL, and as far as I know the DDX doesn't either, so that could make the difference. 2) t_dd_vbtmp.h has color assignments in the emit functions that use char arrays for non-RGBA without attention to endiness. Changed to use the correctly ordered named fields from the t_dd_vertex.h definition of the hw vertex color_t. Added VERTEX_COLOR_T macro so hw driver can pass in its hw vertex *_color_t; so the assignments can be made in correct order. Added macro definition to *_vb.c of the various drivers. 3) Changed r128_tris.c VERT_* macros for t_dd_tritmp.h to use the named fields instead of an char array. 4) Added some casts to r128_ioctl.c to eliminate compile warnings. 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. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
