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
