Re: Chromium acceleration

[Eric Nelson <eric.nelson@boundarydevices.com>]

Hi Carlos,

On 03/19/2014 02:00 PM, Carlos Rafael Giani wrote:
> Hello,
>
> I wrote a patch for VPU acceleration in Chromium months ago for a
> company project. I got the OK from the customer to cleanup and
> eventually opensource the patches, but didn't have the time yet.

You're the man!

What can we do to help find you the time?

> Together with other colleagues we also got HW-accelerated WebGL to work,
> though some other areas weren't running so well (multitouch for
> example). Also, Canvas remained unaccelerated. As the Chromium
> developers explained, there are conceptual problems with the Canvas API
> that make acceleration difficult.
>

Nice! I have to admit being a bit less interested in WebGL than in
video acceleration, but I'm sure others really want this.

 >
> What is also missing is a zerocopy method for displaying video frames.
 >
Do we really want zero copy? It seems that at some level, having
a single copy into a GPU accelerated rendering stack is more
convenient.

> In theory, the direct textures from the Vivante GPU could be used;
> however, this requires passing the physical buffers through to a
> modified renderer somehow.
 >
 > Chromium can use OpenGL ES for rendering everything, but does not
 > contain anything to introduce special video textures yet.
>

I'm not quite sure I'm grokking this.

The Vivante libraries can map the physical buffers produced by
the VPU directly, so they could do format conversion on their
way to the graphics stack if the Chromium bindings have access
to that (the "single copy" I referred to above).

Or, (he says instead of finding the code), is this handled by
ffmpeg-mt?

Using an IPU overlay (a.la. mfw_v4lsink) is nice, but makes
doing overlays and such more difficult, and you probably know
how web-developers can be ;).

Regards,


Eric