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

[Alex Deucher]

2010/9/1  <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?
>
> 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.

Probably gtkperf would be more useful since lots of x11perf tests
measure stuff that's never used in most desktops.  Still, would useful
to see how things are affected overall even if many of them aren't
used much.

Alex

>
>> ... I wanted to give some background about how the code
>> came to be in its current form.
>
> Thanks very much.
> _______________________________________________
> xorg-driver-ati mailing list
> xorg-driver-ati at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>