Mailinglist Archive: radeonhd (307 mails)

[Alex Deucher <alexdeucher@xxxxxxxxx>]

On Mon, Feb 9, 2009 at 6:01 PM, Mark van Doesburg
<mark.vandoesburg@xxxxxxxxx> wrote:
>        The current code works breaking the overlapping region down into
>        regions the size of the non-overlapping part and copying them
>        over one by one.  That way you never have to worry about raster
>        direction since you are always copying a non-overlapping part.
>
> That's what the code said, I just didn't want to believe that was actually
> happening.  So dragging a 1000x1000 window by one pixel diagionally
> results in a 1000000 operations, no wonder my Matrox G400 felt faster.
> (And the cpu load reaches 95% when dragging a window)

if you move it one pixel, but more often than not, the region is
bigger than one pixel.

>        Those primitives were designed for that purpose, but they don't
>        work like the other primitives.  The VGT and vertex setup setup is
>        completely different.  They were implemented for the 2D emulation
>        in the CP microcode on r6xx chips.  They aren't really supposed
>        to be usable by software according to the hw folks.
>
>        Alex
>
> So there was supposed to be a better solution, but it doesn't work,
> too bad. Sorry for wasting your time, I guess I'll have to wait until
> the rest of the documenation is available.
>
> Thanks for the info (and the driver of course).

That solution works if you use the CP 2D emulation, but it's only
available on r6xx chips so we can't use it for r7xx.  With more and
more movement towards composited desktops this becomes less of a
issue.

Alex
-- 
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx