Pepper: Refactor cpu feature attributes.

Pepper: Refactor cpu feature attributes.

We'll want to break up ppb_nacl_private_impl.cc instead of lumping things into
one large file. This change makes the method for getting CPU feature attributes
easier to reuse, and renames the sandbox_arch.{cc,h} files in the process.

This is split off from a larger change to remove FileDownloader in the trusted
plugin.

BUG=370556
R=bbudge@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=283861

[bbudge, 2014-07-17 17:57:55]

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/pla...
File components/nacl/renderer/platform_info.h (right):

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/pla...
components/nacl/renderer/platform_info.h:16: std::string GetCpuFeatureAttrs();
Since this now returns a string, perhaps it could be called GetCpuFeatures?

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/ppb...
File components/nacl/renderer/ppb_nacl_private_impl.cc (right):

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/ppb...
components/nacl/renderer/ppb_nacl_private_impl.cc:1600:
&ExternalGetCpuFeatureAttrs,
If you rename the components/nacl function, you could keep the old name here.

[teravest, 2014-07-17 18:01:40]

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/pla...
File components/nacl/renderer/platform_info.h (right):

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/pla...
components/nacl/renderer/platform_info.h:16: std::string GetCpuFeatureAttrs();
On 2014/07/17 17:57:55, bbudge wrote:
> Since this now returns a string, perhaps it could be called GetCpuFeatures?

Done.

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/ppb...
File components/nacl/renderer/ppb_nacl_private_impl.cc (right):

https://codereview.chromium.org/399983002/diff/1/components/nacl/renderer/ppb...
components/nacl/renderer/ppb_nacl_private_impl.cc:1600:
&ExternalGetCpuFeatureAttrs,
On 2014/07/17 17:57:55, bbudge wrote:
> If you rename the components/nacl function, you could keep the old name here.

Done.

[bbudge, 2014-07-17 18:05:16]

Some information from an internal email thread on issues with a PPAPI
VideoEncoder:

----------------

On Wed, Jul 16, 2014 at 9:13 AM, Bill Budge <bbudge@google.com> wrote:
Hi Antoine,

An external contributor is proposing a PPB_VideoEncoder API and we're reviewing
his CL.

https://codereview.chromium.org/365153003/

One thing that came up is that Chrome encoders (hardware accelerated and not)
take VideoFrames as input. The CL proposes using GL textures to transport
pictures from the plugin to the renderer. I have two questions I'm hoping you
can answer:

1) Does the savings from avoiding a copy of frame data offset the cost of
downloading the contents of the texture into a VideoFrame, or is it possible to
avoid this?

My understanding is that while a VideoFrame can encapsulate a GL texture, today
none of the accelerated encoders support using that as an input (at least as
implemented in Chrome. It is possible that they support it in hardware). Reading
back from a GL texture is going to be slow no matter what.
Given that, I think it's a mistake to expose the encoder uniquely based on GL
textures:
1- if the source of data is in software, using the API means uploading to a
texture (costs at least one if not 2 copies), and then reading back from it
(depending on where it's done, an extra 1 or 2 copies, plus synchronization,
plus a potentially slow GPU->CPU readback).
2- if the source of data is in a texture, we have to readback anyway, it doesn't
really matter if it's done by the plugin or by the API, it will be slow anyway.

It does make sense to expose GL textures once the accelerated encoders can take
them as an input. The savings then would be significant.
 
2) Is this a good API from the plugin perspective (does a plugin normally want
to encode a series of GL textures, or would VideoFrame be more useful)?

I'm not sure of the use case. The main use cases for encoding today are:
1- video conference, the source is in software, coming from the camera (note
that the Pepper video capture API gives you software bits)
2- tab casting, the source can be either in hardware or software, but it's all
done inside of chrome today. I'm not sure about a similar use case from within a
plugin, I guess why not in theory, though a follow-up question is whether or not
we believe such a use case is important enough that we want the maintenance
burden. I don't think there is any similar API exposed to the web, which is a
good sniff test of whether or not we should expose to pepper.

Antoine

----------------

Pawel Osciak <posciak@google.com>

Antoine is correct on all points.

VideoFrame can encapsulate shared memory and dmabufs as well, and those are
actually used for encode in camera capture/webrtc cases. The texture path is
used for casting, when we do do a download, but then use shared memory in VF
again and then copy out from it to codec buffers. The only path where we
actually do use VF textures is for decode output.

The problem with casting is that we don't setup the textures that we may have to
cast from (we don't know what may get casted), so we can't prepare "special
shareable" buffers beforehand. We definitely want to improve this situation, one
issue is though that not all textures allocated by DRM/GPU can be shared with
codecs, for example on some ARMs (Exynos), which may have special requirements
for the memory used by the codec.

I definitely agree having textures as encoder input is not good. We need a
universal transport for shareable buffers though and at one point the idea was
to use textures, which, as Antoine mentioned, were supposed to be shareable with
the codec via EGL_EXT_image_dma_buf_import (this is not good for casting though,
because it's backing a texture with EGLImage created from dmabuf, not exporting
dmabufs from an existing texture). Then we wanted to use dmabufs, but right now
it seems that we end up using GLimage, which will be able to encapsulate dmabufs
among other things. 

 
2) Is this a good API from the plugin perspective (does a plugin normally want
to encode a series of GL textures, or would VideoFrame be more useful)?

I'm not sure of the use case. The main use cases for encoding today are:
1- video conference, the source is in software, coming from the camera (note
that the Pepper video capture API gives you software bits)
2- tab casting, the source can be either in hardware or software, but it's all
done inside of chrome today. I'm not sure about a similar use case from within a
plugin, I guess why not in theory, though a follow-up question is whether or not
we believe such a use case is important enough that we want the maintenance
burden. I don't think there is any similar API exposed to the web, which is a
good sniff test of whether or not we should expose to pepper.

This is correct. The goal is to back VideoFrames with dmabufs of HW buffers (on
CrOS at least, and maybe something else on Android and elsewhere). If the source
is coming from a CPU buffer, we'd upload to a codec buffer backed by a dmabuf,
mmapping its dmabuf fd.

So I think the goal should be to have an abstract entity like GLImage as the
input to the codec.

I'm sure others will like to add to this.

Thanks,
Pawel

[bbudge, 2014-07-17 18:06:01]

On 2014/07/17 18:05:16, bbudge wrote:
> Some information from an internal email thread on issues with a PPAPI
> VideoEncoder:
> 
> ----------------
> 
> On Wed, Jul 16, 2014 at 9:13 AM, Bill Budge <mailto:bbudge@google.com> wrote:
> Hi Antoine,
> 
> An external contributor is proposing a PPB_VideoEncoder API and we're
reviewing
> his CL.
> 
> https://codereview.chromium.org/365153003/
> 
> One thing that came up is that Chrome encoders (hardware accelerated and not)
> take VideoFrames as input. The CL proposes using GL textures to transport
> pictures from the plugin to the renderer. I have two questions I'm hoping you
> can answer:
> 
> 1) Does the savings from avoiding a copy of frame data offset the cost of
> downloading the contents of the texture into a VideoFrame, or is it possible
to
> avoid this?
> 
> My understanding is that while a VideoFrame can encapsulate a GL texture,
today
> none of the accelerated encoders support using that as an input (at least as
> implemented in Chrome. It is possible that they support it in hardware).
Reading
> back from a GL texture is going to be slow no matter what.
> Given that, I think it's a mistake to expose the encoder uniquely based on GL
> textures:
> 1- if the source of data is in software, using the API means uploading to a
> texture (costs at least one if not 2 copies), and then reading back from it
> (depending on where it's done, an extra 1 or 2 copies, plus synchronization,
> plus a potentially slow GPU->CPU readback).
> 2- if the source of data is in a texture, we have to readback anyway, it
doesn't
> really matter if it's done by the plugin or by the API, it will be slow
anyway.
> 
> It does make sense to expose GL textures once the accelerated encoders can
take
> them as an input. The savings then would be significant.
>  
> 2) Is this a good API from the plugin perspective (does a plugin normally want
> to encode a series of GL textures, or would VideoFrame be more useful)?
> 
> I'm not sure of the use case. The main use cases for encoding today are:
> 1- video conference, the source is in software, coming from the camera (note
> that the Pepper video capture API gives you software bits)
> 2- tab casting, the source can be either in hardware or software, but it's all
> done inside of chrome today. I'm not sure about a similar use case from within
a
> plugin, I guess why not in theory, though a follow-up question is whether or
not
> we believe such a use case is important enough that we want the maintenance
> burden. I don't think there is any similar API exposed to the web, which is a
> good sniff test of whether or not we should expose to pepper.
> 
> Antoine
> 
> ----------------
> 
> Pawel Osciak <mailto:posciak@google.com>
> 
> Antoine is correct on all points.
> 
> VideoFrame can encapsulate shared memory and dmabufs as well, and those are
> actually used for encode in camera capture/webrtc cases. The texture path is
> used for casting, when we do do a download, but then use shared memory in VF
> again and then copy out from it to codec buffers. The only path where we
> actually do use VF textures is for decode output.
> 
> The problem with casting is that we don't setup the textures that we may have
to
> cast from (we don't know what may get casted), so we can't prepare "special
> shareable" buffers beforehand. We definitely want to improve this situation,
one
> issue is though that not all textures allocated by DRM/GPU can be shared with
> codecs, for example on some ARMs (Exynos), which may have special requirements
> for the memory used by the codec.
> 
> I definitely agree having textures as encoder input is not good. We need a
> universal transport for shareable buffers though and at one point the idea was
> to use textures, which, as Antoine mentioned, were supposed to be shareable
with
> the codec via EGL_EXT_image_dma_buf_import (this is not good for casting
though,
> because it's backing a texture with EGLImage created from dmabuf, not
exporting
> dmabufs from an existing texture). Then we wanted to use dmabufs, but right
now
> it seems that we end up using GLimage, which will be able to encapsulate
dmabufs
> among other things. 
> 
>  
> 2) Is this a good API from the plugin perspective (does a plugin normally want
> to encode a series of GL textures, or would VideoFrame be more useful)?
> 
> I'm not sure of the use case. The main use cases for encoding today are:
> 1- video conference, the source is in software, coming from the camera (note
> that the Pepper video capture API gives you software bits)
> 2- tab casting, the source can be either in hardware or software, but it's all
> done inside of chrome today. I'm not sure about a similar use case from within
a
> plugin, I guess why not in theory, though a follow-up question is whether or
not
> we believe such a use case is important enough that we want the maintenance
> burden. I don't think there is any similar API exposed to the web, which is a
> good sniff test of whether or not we should expose to pepper.
> 
> This is correct. The goal is to back VideoFrames with dmabufs of HW buffers
(on
> CrOS at least, and maybe something else on Android and elsewhere). If the
source
> is coming from a CPU buffer, we'd upload to a codec buffer backed by a dmabuf,
> mmapping its dmabuf fd.
> 
> So I think the goal should be to have an abstract entity like GLImage as the
> input to the codec.
> 
> I'm sure others will like to add to this.
> 
> Thanks,
> Pawel

whoops, wrong bug. Sorry!

[bbudge, 2014-07-17 18:06:40]

LGTM

[teravest, 2014-07-17 18:07:56]

The CQ bit was checked by teravest@chromium.org

[commit-bot: I haz the power, 2014-07-17 18:10:21]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/teravest@chromium.org/399983002/20001

[teravest, 2014-07-17 20:40:17]

Committed patchset #2 manually as r283861 (presubmit successful).