[PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM

[xmail at karlt.net]

Michel Dänzer writes:

> On Mit, 2010-09-01 at 10:37 +1200, Karl Tomlinson wrote: 
>> 
>> Michel Dänzer writes:

>> >> I wondered whether PrepareAccess could fail for the visible screen
>> >> with mixed pixmaps as suggested here
>> >> http://www.mentby.com/maarten-maathuis/exa-classic-problem-with-xv.html
>> >> When I tried that, however, I ended up with pixels in the wrong
>> >> places, a bit like what I would expect if the pitch were wrong.
>> >
>> > I thought I tried that before and it worked. If the problem isn't a
>> > straightforward pitch bug, it sounds like it might be tiling related?
>> 
>> Could be.  I have color tiling enabled.  I expect you know better
>> than I whether this is likely.
>> 
>> Things worked fine for a while, then suddenly, on some apparently
>> random activity, the whole screen got upset.  Colors looked
>> reasonable AFAICT, though I wasn't sure which bits of the screen I
>> was looking at.  IIRC lines bordering regions weren't perfect
>> diagonals but more staircases, and it felt like there as a lot of
>> repeating going on.
>
> Have you tried if it also happens with tiling disabled? Is the effect
> captured in a screenshot?

Also happens with tiling disabled, and, with no tiling, the lines
are (close-to-horizontal) diagonals (instead of staircases) as
would be expected from a pitch bug.

The effect is not captured in a screenshot.
Screenshots look correct.

I couldn't reproduce with compositing enabled in kwin, but gtkperf
triggered the corruption with compositing disabled.
Re-enabling compositing did not correct the corruption.

The initial corruption was limited to portions of the screen,
consistent with the portions being damaged, only in the wrong
position (i.e. consistent with a pitch bug).