[Bug 27139] html5 ogg video playback in firefox unusable

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27139

--- Comment #19 from Karl Tomlinson <bugs.freedesktop at karlt.net> 2010-08-16 07:34:49 PDT ---
Created an attachment (id=37900)
 View: https://bugs.freedesktop.org/attachment.cgi?id=37900
 Review: https://bugs.freedesktop.org/review?bug=27139&attachment=37900

Avoid CPU reads of VRAM

This 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.)

The key is avoiding reading from VRAM via CPU, but using instead
the RADEONBlitChunk path in RADEONDownloadFromScreenCS.

Modifications to RADEONUploadToScreenCS and RADEONDownloadFromScreenCS include:

* Completing the operation even when a scratch BO is not necessary
  (like the big endian byte-swap paths).

* Flushing CS before mapping the pixmap BO for read, if CS references the BO
  for writing.  (I don't know exactly which situations lead to an unflushed CS
  here, but RADEONPrepareAccess_CS ensured a flush, so it seems consistent to
  do so here.)

* Completing the operation even when scratch BO space allocation fails.

  This sometimes requires a flush even in UploadToScreen.

  Currently, this just falls back to a similarly slow CPU read even from VRAM.
  I guess scratch allocation could be retried after flushing CS, but I haven't
  added that support here.  I don't know what leads to an unflushed CS here so
  don't really know how much space might be freed by doing that.

* If radeon_bo_is_busy doesn't set src_domain (and it stays zero), then the
  scratch BO path is taken because the pixmap BO might be in VRAM.

Making RADEONUploadToScreenCS and RADEONDownloadFromScreenCS reliable means
that RADEONPrepareAccess_CS can choose when to proceed (succeed).

In this patch, RADEONPrepareAccess_CS proceeds if it knows that the BO is not
going to be in VRAM.  Maybe, in some ways, it might be better to fail so that
EXA can consider migrating the pixmap out.  However, if the BO is in GTT, then
proceeding in PrepareAccess saves some memcpy and leaves the BO available for
future GPU reads.

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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.