[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