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
[Dri-devel] Re: r128 PPC patches
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 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. You're welcome. At least with the mesa demos it works the same in 16 and 32 bpp... I did see some oddness in 16bpp before fixing the copies in the t_dd_vbtmp.h emit funcs. I was going to explain how 16 bit textures break with CONVERT_TEXEL instead of CONVERT_TEXEL_DWORD, but that was before APPEND16, which fixes the texel order. With this, it seems we could get away without PACK*LE in the radeon and r128, maybe even mach64 drivers. But can we assume that any chip can swap texel bytes? As chips likely will be little endian internally in the foreseeable future, I think defaulting to that is safest. But, if it is due to a hw capability, then the sw arch needs to handle that, i.e. make the PACK*LE configurable. Which would probably mean texutil would need to be compiled at the driver level, rather than the common level. That would be a possibility, maybe a texutil driver template. I don't think the current code is really bad though. -- 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
[Dri-devel] Re: r128 PPC patches
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 DMA blits used to load the texture subimages? If someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. Found a big pro and con for running without that bit set--- XV! Xine playing a DVD requires 40% less cpu time on dual 450 G4's. That's likely from reduced byte-swapping and would hold the promise of most G3's with Rage 128's finally being able to play DVD's without dropped frames. (For the archives: As you've found out, that's not due to that bit but DMA transfers for Xv) The con... it's very unstable and subject to server and system hangs. Concurrently trying to move windows is impossibly slow and jerky, and may cause artifacts and momentary (multi-second) hangs. In one case the server and system (telnet session wouldn't respond) hung till I moved the mouse. Trying to run glxgears causes an instant server hang. For comparison, with 4.2.0 I can load up the system with makes and seti's to 99+% and then start xine and glxgears. And while xine is dropping a lot of frames, playback has only a slight flutter and X is still responsive enough to fireup and use mozilla. BTW, I'm in forced PCI mode, which has been needed for XV and DRI to run concurrently, but will have to give AGP mode a try. 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. Looks like some nasty DMA contention problems, perhaps the kernel drivers need some compensating changes? Something else which is done better in the radeon driver than in r128 is synchronization between the 2D and 3D streams. Lack of that can cause lockups. -- 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
[Dri-devel] Re: r128 PPC patches
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 radeon_cp_* and r128_cce_* functions involving the dirty and discard bits, and DMA_COPY_FROM_USER's? Which versions of the kernel drivers are considered most current, dri CVS or kernel.org? Or is some merging possibly needed? --- 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]; \
[Dri-devel] Re: r128 PPC patches
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. Does this also involve the differences between the radeon_cp_* and r128_cce_* functions involving the dirty and discard bits, and DMA_COPY_FROM_USER's? Not sure what you mean exactly, the difference in the ioctl interfaces? I don't think those are important for stability, the radeon interfaces were the same as they are now when it was less stable. Which versions of the kernel drivers are considered most current, dri CVS or kernel.org? DRI Development happens in DRI CVS. Or is some merging possibly needed? Possibly, but I don't expect anything but fixes for changes in the kernel and the like in the kernel trees. -- 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
[Dri-devel] Re: r128 PPC patches
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 that, but it won't work because not all of the VERTEX union's variants have the color field at the same offset , depending upon whether or not there is a depth field, thus the vi[coloroffset]. You can get rid of the intermediate with some repeated casting, but why not just code it once and let the compiler do the work? Henry --- 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
[Dri-devel] Re: r128 PPC patches
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 for your fixes! Took a look at the archive, I had tried that, but it won't work because not all of the VERTEX union's variants have the color field at the same offset , depending upon whether or not there is a depth field, thus the vi[coloroffset]. Right, I had missed that, thanks for pointing it out. -- 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
[Dri-devel] Re: r128 PPC patches
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. 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. :) -- 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: 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
[Dri-devel] Re: r128 PPC patches
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. You're welcome. At least with the mesa demos it works the same in 16 and 32 bpp... I did see some oddness in 16bpp before fixing the copies in the t_dd_vbtmp.h emit funcs. I don't have the HW docs, so someone else will have to address that. Any byteswapping at that level would have to be aware of the texel size or it'd also be swapping sub-32bpp texels out of order. But, if it is due to a hw capability, then the sw arch needs to handle that, i.e. make the PACK*LE configurable. Which would probably mean texutil would need to be compiled at the driver level, rather than the common level. --- 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
[Dri-devel] Re: r128 PPC patches
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 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 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 someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. --- 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
[Dri-devel] Re: r128 PPC patches
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 someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. Found a big pro and con for running without that bit set--- XV! Xine playing a DVD requires 40% less cpu time on dual 450 G4's. That's likely from reduced byte-swapping and would hold the promise of most G3's with Rage 128's finally being able to play DVD's without dropped frames. The con... it's very unstable and subject to server and system hangs. Concurrently trying to move windows is impossibly slow and jerky, and may cause artifacts and momentary (multi-second) hangs. In one case the server and system (telnet session wouldn't respond) hung till I moved the mouse. Trying to run glxgears causes an instant server hang. For comparison, with 4.2.0 I can load up the system with makes and seti's to 99+% and then start xine and glxgears. And while xine is dropping a lot of frames, playback has only a slight flutter and X is still responsive enough to fireup and use mozilla. BTW, I'm in forced PCI mode, which has been needed for XV and DRI to run concurrently, but will have to give AGP mode a try. Looks like some nasty DMA contention problems, perhaps the kernel drivers need some compensating changes? Henry --- 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
[Dri-devel] Re: r128 PPC patches
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 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 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? Possibly. The HOST_DATA registers are used for other stuff but HOST_BIG_ENDIAN_EN seems to be sensitive to the advertised format and the other users maybe set formats which don't cause bytes to get swapped. If someone with the docs can confirm what that bit is suppose to do, we The register reference isn't very clear, it just says the bit causes bytes to be swapped according to the 'pixel width'. No mention where they get swapped (I assume in the HOST_DATA registers) or how the pixel width is determined (I assume from the data type set in the DP_GUI_MASTER_CNTL register). may get be able to getaway with eliminating that bit. I'm convinced that's the only way, as I'll explain in a followup to your other post. But first, I have to get some sleep... -- 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: 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
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
[Dri-devel] Re: r128 PPC patches
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 texture subimages? If someone with the docs can confirm what that bit is suppose to do, we may get be able to getaway with eliminating that bit. Found a big pro and con for running without that bit set--- XV! Ack, I'll have to retract both the pro and con. I forgot that I was working from a fresh src tree that didn't have Michel's indirect buffering and XV dma fixes that are required for stable XV with SMP linuxppc. Stablility with SMP linuxppc kernels requires disabling XV dma and forcing PCI mode. With the patches performance and stability are back where they were before. --- 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
