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

[Karl Tomlinson]

This reduces the cost of software fallback in
https://bugs.freedesktop.org/show_bug.cgi?id=27139

It changes video rate from 2 seconds per frame with 100% CPU in
Xorg to something close to 24 fps with 40% CPU in Xorg.  (Of
course, CPU usage drops to 10% when Firefox uses RepeatPad, but
this patch is useful so that fallback is not so punishing.)  "ATI
Mobility Radeon X1400" (ChipID = 0x7145)

AFAIK migrating the BO from VRAM to GTT in PrepareAccess doesn't
seem to be a good idea without more information.  Only EXA really
knows whether a read is necessary, and only EXA knows which
portions of the pixmap will be read, so DownloadFromScreen when
EXA knows it is necessary seems the best solution.  (EXA doesn't
always get this right but that's how things are meant to work and
usually it gets there in the end.)

Perhaps something else to consider in the future is moving the
BO from VRAM to GTT in DFS, but that also has pros and cons.
This approach seems to work well enough so far.

In this patch, RADEONPrepareAccess_CS still proceeds if it knows
that the BO is not going to be in VRAM.  EXA will release its
system memory copy, so that there is only one copy in system
memory.

 (Maybe, in some ways, it might be better to fail so that EXA can
  keep a copy and won't have to refetch if the BO gets moved to
  VRAM, but it seems pointless to keep around two copies in system
  memory and memcpy between them for GPU reads.)

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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0006-RADEONPrepareAccess_CS-fallback-to-DFS-when-pixmap-i.patch
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20100823/fdd8c4ad/attachment.ksh>