Re: What copybit does and where image conversion from YUV to RGB is implemented?

[Wenlong Li]

Should I send this message to this group? anyone can help answer my
question. thx very much

On Wed, May 20, 2009 at 6:17 PM, Wenlong Li <wen...@gmail.com> wrote:
> Hello,
>
> Can anyone share some info about copybit? I saw there is a header file
> (copybit.h) under hardware directory, but don't know the detailed
> implementation. I guess the main operation is to copy image from
> source to destination, and scale image. Is my understanding correct?
>
> Besides these, can it support image format conversion, such as from
> YUV to RGB. Seems camera capatures image in YUV format, and does
> conversion before showing it in screen.
>
> The third question is which device is used for copybit? GPU or other devices?
>
> thx,
> Wenlong
>

[Elvis Dowson]

Hi,

     I too am curious to know the answer, I dont have this copybit.so file, and would like to know what it is supposed to do? Some sort of hardware accelerated bit-blit graphics hardware function?

Elvis

[Dave Sparks]

With the Cupcake release, by default we do software color conversion
in the video MIO. If your hardware supports it, you can override this
and use the hardware CC. This is the way it is done on the G1 and
other msm7k based devices.

In the release after Donut, you'll be able use a GL shader to do CC if
you don't have a hardware blitter. You'll start seeing these changes
being pushed out to master soon.

[Manish Sharma]

Hi Dave,

 

>> If your hardware supports it, you can override this and use the hardware CC. This is the way it is done on the G1 and other msm7k based devices.

Are you saying that hardware CC is done at Video MIO in G1?

 

Otherwise, Is it possible to send YUV data (without doing CC in VideoMIO) to SurfaceFlinger. And performing instead the Hardware CC in copybit?

 

Regards.

MS

[pixelflinger]

Hi,

copybit is just an abstraction for a basic 2D blitter with support for
rotation, scaling and color/pixelformat conversions. These features
can be supported in full or partially.

If the copybit module is present, then SurfaceFlinger will try to use
it instead of using OpenGL ES.

On the G1 copybit is used for all window compositions and video
playback (CC and scaling), on this h/w copybit is very fast and
provide very good up and down scaling.

HOWEVER, on the release after Donut, the copybit module won't be used
by SurfaceFlinger directly, instead it will be used as a back-end for
our software OpenGL ES 1.x and SurfaceFlinger will only use the OpenGL
ES API.
Eventually, the copybit module will be phased out, instead, we will
ask the ISV/OEMs to implement these features on their OpenGL ES
drivers, if they think it is necessary.


If your h/w doesn't have accelerated GL, but has some sort of decent
2D blitter, you can write a copybit HAL module for it, and it will be
used automatically by SurfaceFlinger -- at least under cupcake and
donut.


Mathias

On May 20, 8:57 pm, Wenlong Li <wenl...@gmail.com> wrote:
> Should I send this message to this group? anyone can help answer my
> question. thx very much
>

[Manish Sharma]

Thanks Mathias,

 

How soon we can see this change happening in Master branch?

We are in process of accelerating copybit. Is it worth putting effort in this direction or shall we go with OpenGL APIs for 2D accelerations without using copybit?

 

Regards,

Manish

[MS]

Hi Mathias,

>> HOWEVER, on the release after Donut, the copybit module won't be used
>> by SurfaceFlinger directly, instead it will be used as a back-end for
>> our software OpenGL ES 1.x and SurfaceFlinger will only use the OpenGL
>> ES API.

I have one doubt on the above statement.
You are saying copybit will be used as back-end for s/w OpenGL. Can we
pass YUV data directly to OpenGL for color conversion?
As I know YUV formats are not supported in standard OpenGL ES 1.x.
Where will CC be done in this scenario?
Sorry to ask you at the moment while this will be very helpful to
align our design with future android releases.

Regards,
MS

> > > Wenlong- Hide quoted text -
>
> - Show quoted text -

[pixelflinger]

Hi,

There will be a new SurfaceFlinger API for video playback; that API
will use copybit on the G1, could use real overlays on other devices.

Mathias

[Manish Sharma]

Thanks Mathias

[cemil]

Hi Mathias,

I'd like to clarify one point. If we implement copybit, will this only
benefit SurfaceFlinger and not the (Java) apps? AFAIK, java apps use
skia middleware. Does skia backend make use of copybit somehow? I
can't see this in the code, but want to confirm. If that's true, what
mechanisms are there for blit acceleration for apps?

Thanks,
Cemil


On May 22, 3:52 am, pixelflinger <pixelflin...@google.com> wrote:
> Hi,
>
> copybitis just an abstraction for a basic 2D blitter with support for

> rotation, scaling and color/pixelformat conversions. These features
> can be supported in full or partially.
>

> If thecopybitmodule is present, then SurfaceFlinger will try to use

> it instead of using OpenGL ES.
>

> On the G1copybitis used for all window compositions and video
> playback (CC and scaling), on this h/wcopybitis very fast and

> provide very good up and down scaling.
>

> HOWEVER, on the release after Donut, thecopybitmodule won't be used

> by SurfaceFlinger directly, instead it will be used as a back-end for
> our software OpenGL ES 1.x and SurfaceFlinger will only use the OpenGL
> ES API.

> Eventually, thecopybitmodule will be phased out, instead, we will

> ask the ISV/OEMs to implement these features on their OpenGL ES
> drivers, if they think it is necessary.
>
> If your h/w doesn't have accelerated GL, but has some sort of decent

> 2D blitter, you can write acopybitHAL module for it, and it will be

> used automatically by SurfaceFlinger -- at least under cupcake and
> donut.
>
> Mathias
>
> On May 20, 8:57 pm, Wenlong Li <wenl...@gmail.com> wrote:
>
> > Should I send this message to this group? anyone can help answer my
> > question. thx very much
>
> > On Wed, May 20, 2009 at 6:17 PM, Wenlong Li <wenl...@gmail.com> wrote:
> > > Hello,
>

> > > Can anyone share some info aboutcopybit? I saw there is a header file

> > > (copybit.h) under hardware directory, but don't know the detailed
> > > implementation. I guess the main operation is to copy image from
> > > source to destination, and scale image. Is my understanding correct?
>
> > > Besides these, can it support image format conversion, such as from
> > > YUV to RGB. Seems camera capatures image in YUV format, and does
> > > conversion before showing it in screen.
>

> > > The third question is which device is used forcopybit? GPU or other devices?
>
> > > thx,
> > > Wenlong

[pixelflinger]

Hello,

On Jun 8, 2:13 pm, cemil <cemil_azizo...@yahoo.com> wrote:
> Hi Mathias,
>
> I'd like to clarify one point. If we implement copybit, will this only
> benefit SurfaceFlinger and not the (Java) apps? AFAIK, java apps use
> skia middleware. Does skia backend make use of copybit somehow? I
> can't see this in the code, but want to confirm. If that's true, what
> mechanisms are there for blit acceleration for apps?

Copybit is only used in SurfaceFlinger when OpenGL ES cannot be used
or when it's software.
Actually in the current implementation (cupcake), SurfaceFlinger
always uses copybit instead of GL if copybit is available -- but
that's an oversight.

There are no mechanism to accelerate applications at the moment. Skia
is a purely software renderer. It can greatly benefit from newer CPUs
though, which have SIMD instructions, often, it'll be able to operate
at bus speed in that case. We're working on optimization in that area.

If a device has a GPU, it makes no sense to implement copybit, because
(1) it won't be used by apps and (2) SurfaceFlinger already uses the
GPU for its work. Now, if the device has an additional 2D part (like
the G1), it is useful to implement copybit, this way application won't
have to share the GPU with SurfaceFlinger.


Mathias

[cemil]

Makes sense...

Excuse my poor english, does the following comment mean copybit
backend for SF be released as part of Donut or is this a post-Donut
feature?

"HOWEVER, on the release after Donut, the copybit module won't be used
by SurfaceFlinger directly instead it will be used as a back-end for

our software OpenGL ES 1.x"

Thanks,
Cemil

On Jun 9, 12:33 am, pixelflinger <pixelflin...@google.com> wrote:
> Hello,
>
> On Jun 8, 2:13 pm, cemil <cemil_azizo...@yahoo.com> wrote:
>
> > Hi Mathias,
>

> > I'd like to clarify one point. If we implementcopybit, will this only

> > benefit SurfaceFlinger and not the (Java) apps? AFAIK, java apps use

> > skia middleware. Does skia backend make use ofcopybitsomehow? I

> > can't see this in the code, but want to confirm. If that's true, what
> > mechanisms are there for blit acceleration for apps?
>

> Copybitis only used in SurfaceFlinger when OpenGL ES cannot be used

> or when it's software.
> Actually in the current implementation (cupcake), SurfaceFlinger

> always usescopybitinstead of GL ifcopybitis available -- but

> that's an oversight.
>
> There are no mechanism to accelerate applications at the moment. Skia
> is a purely software renderer. It can greatly benefit from newer CPUs
> though, which have SIMD instructions, often, it'll be able to operate
> at bus speed in that case. We're working on optimization in that area.
>

> If a device has a GPU, it makes no sense to implementcopybit, because

> (1) it won't be used by apps and (2) SurfaceFlinger already uses the
> GPU for its work. Now, if the device has an additional 2D part (like

> the G1), it is useful to implementcopybit, this way application won't

[vishal bhoj]

Is there a document describing what functionalities need to be implemented in Copybit.

Is there any reference implenetation ? Has anyone tried to implement it .

--
with regards vishal

[vishal bhoj]

--
with regards vishal