What copybit does and where image conversion from YUV to RGB is implemented?
 |
Should I send this message to this group? anyone can help answer my
question. thx very much
|
|
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
|
|
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.
On May 21, 3:51 am, Elvis Dowson <elvis.dow...@gmail.com> wrote:
|
|
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
On Thu, May 21, 2009 at 9:13 PM, Dave Sparks <davidspa...@android.com>wrote:
|
|
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:
|
|
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
On Fri, May 22, 2009 at 2:22 PM, pixelflinger <pixelflin...@google.com>wrote:
|
|
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
On May 22, 1:52 pm, pixelflinger <pixelflin...@google.com> wrote:
|
|
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
On May 25, 5:41 am, MS <manishsharm...@gmail.com> wrote:
|
|
Thanks Mathias
On Tue, May 26, 2009 at 8:43 AM, pixelflinger <pixelflin...@google.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?
Thanks,
Cemil
On May 22, 3:52 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 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
|
|
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:
|
|
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
|
|
|
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
