[PATCH 6/6] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM
xmail at karlt.net
xmail at karlt.net
Wed Sep 1 16:44:25 PDT 2010
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?
I can try that.
> Is the effect captured in a screenshot?
It had slipped my mind that I could switch vt to take a shot.
I might be able to try these out today, or in the near future.
> There's no question that direct VRAM access is very slow if the
> operation needs to read a large number of the pixels. However that isn't
> always the case, e.g. consider a 0-width line spanning a diagonal of a
> large pixmap.
That might be right.
Unfortunately we don't have the info to distinguish.
DFS could perhaps have a fast path for small pixmaps.
I have no idea what would define "small".
>> > Have you made any measurements with e.g. gtkperf or x11perf to
>> > see if there are any bad regressions?
> , still it would be good to make some additional measurements
> to make sure there aren't any bad regressions.
I'll look into it. Let me know if there is a subset of x11perf
tests that is interesting here. I just saw "This may take a
while" and I don't have "a while" today, but I guess running all
the tests is better anyway.
> ... I wanted to give some background about how the code
> came to be in its current form.
Thanks very much.
More information about the xorg-driver-ati
mailing list