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

[Michel Dänzer]

First of all, thanks a lot for splitting up the patch from the bug
report, this was very helpful for review. Unfortunately though, the
split isn't quite perfect:

      * Patch 4 introduces a big endian build break (typo, pSrc instead
        of pDst in RADEONUploadToScreenCS) which is silently fixed in
        patch 5. 
      * The r600 changes aren't split up properly, so changes to one
        patch may require changing an otherwise unrelated patch as well.

Would be great if you could clean that up further.


On Mon, 2010-08-23 at 19:25 +1200, Karl Tomlinson wrote: 
> 
> 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?

Basically, the reason why these paths were so far limited to big endian
(and even there excluded the screen pixmap, as that doesn't require
byte-swapping thanks to the surface registers) is that I thought other
people like Dave were opposed to using them everywhere based on the
belief that it was an overall loss compared to direct CPU access even in
VRAM. If that turns out to be wrong, or at least the worst case
behaviour is better, we should be able to make these paths work for all
pixmaps. Have you made any measurements with e.g. gtkperf or x11perf to
see if there are any bad regressions?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer