[RFC] compositor-drm: Add hardware accelerated capture of screen using libva

[Daniel Vetter]

On Fri, Aug 30, 2013 at 06:25:30PM +0300, Ander Conselvan de Oliveira wrote:
> On 08/30/2013 07:37 AM, Kristian Høgsberg wrote:
> >On Fri, Aug 23, 2013 at 05:15:48PM +0300, Ander Conselvan de Oliveira wrote:
> >>From: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira at intel.com>
> >>
> >>This patch adds a feature to the DRM backend that uses libva for
> >>encoding the screen contents in H.264. Screen recording can be
> >>activated by pressing mod-shift-space q. A file named capture.h264
> >>will be created in the current directory, which can be muxed into
> >>an MP4 file with gstreamer using
> >
> >I tried it out and it worked like a charm.  I have IvyBridge here and
> >I didn't get the hang you mention.  It's very cool how it encodes h264
> >direectly and doesn't seem to load the system very when doing so.
> >Newer Intel GPUs have a dedicated hw video encoder so it shouldn't
> >take away CPU or GPU resources from whatever weston and clients are
> >doing.  They're still competing for memory bandwidth of course.  I
> >wonder what the impact of capturing a GPU intensive app (like a modern
> >game, potentially under xwayland) might be.
> >
> >Anyway, I feel like we're better off merging this sooner rather than
> >later.  The feature is basically working and for all we know the
> >crasher could be SandyBridge specific.  Do you see a problem in
> >committing this now and fixing the rest of the issues incrementally?
> 
> Yeah, let's do that. Though, I'm not entirely sure if this plugs
> with the drm backend in an optimal way. The frame signal is sent
> just before a flip, and it is in that moment that the front buffer
> is read and sent to be encoded. I guess it would make more sense to
> do that just after a flip. But then we wouldn't use the frame signal
> at all, and instead hook things up with the page flip handler.

If this causes noticable stalls then we just need to teach the kernel that
different gpu engines are allowed to concurrently read fromt the same
buffer object. Atm the starting of the libva encoding will switch the
buffer object to the video ring, but the subsequent pageflip will then
switch it back to blitter/render rings. So you'll stall for the encoding
to finish right now. That ignores that libva itself isn't too great with
properly queueing up rendering :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch