On 21 Apr 2002, Michel Dänzer wrote: > On Sat, 2002-04-20 at 20:26, Mark Vojkovich wrote: > > On 20 Apr 2002, Michel Dänzer wrote: > > > > > On Fri, 2002-04-12 at 02:23, Andrew P. Lentvorski wrote: > > > > Okay, after tracking this, it turns out to be a pixmap cache bug. At > > > > least, I can stop the problem from occurring by adding the "Option > > > > "XaaNoPixmapCache"" line to my XF86Config file. > > > > > > That's coincidence, the same is true for "XaaNoScreenToScreenCopy". > > > > > > The problem is that RADEONCPSetClippingRectangle() is called between > > > RADEONSetupForScreenToScreenCopy() and > > > RADEONSubsequentScreenToScreenCopy() and messes up the > > > DP_GUI_MASTER_CNTL register. > > > > > > I don't see a proper solution to this problem so the attached patch just > > > disables hardware clipping for screen to screen copies. I wonder what > > > impact on performance this has, if any - Mark? > > > > Hard to say. In some hardware implementations, hardware clipping > > is slower and it's fastest to clip in software. It depends on how well > > the hardware optimizes away the unrendered pixels. > > Can you recommend any benchmarks?
There aren't any. x11perf with the window half offscreen would test that though. It's only used in "one-rect" situations. If we don't have a complex cliplist (many rects) we know that we don't need to software clip any geometry, we can just set the hardware clip rect and send it all down without checking any of the primitives at all. With smart hardware this is a win on a slow CPU. It's less important as the CPU gets faster. Mark. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert