Hi Mathias,
- With respect to integrating OpenGL ES -
- What forms of OpenGL ES surfaces does Android use? (Window? PBuffer?
NativePixmap?).
- Does Android expect to allow accelerated rendering to a UI component AND
to be able to draw to it directly?
- Which Android UI components translate into being EGL Surfaces of one
shape or another?
- Do you have a list of where the integration 'hacks' need to be made in
the Android code to ease integration issues? (This would be *really* useful
- a driver writer knows and understand ths EGL/Integration issues, but will
be much less aware of any 'engineering modifications' that need applying to
different parts of the Android code).
- Is the source to libhgl around - or is this a third-party entity?
- Does pixelflinger always use OpenGL for surface composition?
- I imagine that hooking up to a 'generic' OpenGL ES driver (requiring no
integration) would result in ugly uploads/downloads being performed (unless
all of the surfaces used for rendering were derived from EGL surfaces).
Mathias Agopian
<[EMAIL PROTECTED]
gle.com> To
Sent by: [email protected]
[EMAIL PROTECTED] cc
ooglegroups.com
Subject
[android-porting] Re: Use of 3D
26/11/2008 08:01 Hardware Accelerator
Please respond to
[EMAIL PROTECTED]
ooglegroups.com
On Tue, Nov 25, 2008 at 10:54 PM, Pivotian <[EMAIL PROTECTED]> wrote:
>
> sorry for some confusing questions. I was supposed to ask the 3D
> accelerator stuffs ans codec stuffs separately but got mixed up both
> the things together in the end. but the things is clear that Currently
> Android won't support 3D hardware acceleration and its work is in
> progress.
Android can support h/w accelerated 3D (the G1 does), however, it is
not easy to integrate an h/w accelerated OpenGL ES driver at the
moment, because there is no "hardware abstraction layer" for it.
The first thing you need to do is write an OpenGL ES driver. Nobody
will do that for you, it is h/w dependent -- this driver consists of a
kernel module and a libhgl.so library which is a full OpenGL
implementation (with EGL), *you* must provide this (or you h/w
vendor). Once you have that, you need to integrate it with Android's
EGL; but there are no documentation (and frankly no clear way to do it
other than "hacking" in various places (mainly libui and
surfaceflinger).
In hopefully the near future, there will be a framework to allow you
to integrate your own OpenGL drivers with Android (more) easily; this
is simply not ready now.
mathias
> The next thing is about the video codecs which i have just pointed in
> the previous question?
>
> On Nov 26, 11:26 am, Pivotian <[EMAIL PROTECTED]> wrote:
>> hi Mathian
>>
>> The point is that the processor features a built-in, state-of-the-art
>> 3D, 4M triangles/sec hardware accelerator with OpenGL ES 1.1/ 2.0 and
>> D3DM API support.Also Built-in hardware and Multi-Format Codec to
>> enhance the multimedia experience: Supports Standard Definition (SD)
>> level encoding/decoding of multiple content formats including MPEG4, H.
>> 263, H.264 and VC1.
>>
>> I didn't knew that its a complicated thing to use the capabilities of
>> our processor which contains inbuilt encoding/decoding of multiple
>> formats instead of opencore provided by Android.
>> So you mean to say that with above configuration of hardware its not
>> currently possible to enable Android to use hardware accelerator
>> instead of android software codecs.
>>
>> On Nov 26, 10:42 am, Mathias Agopian <[EMAIL PROTECTED]> wrote:
>>
>> > On Tue, Nov 25, 2008 at 9:16 PM, Pivotian <[EMAIL PROTECTED]> wrote:
>>
>> > > Also Mathias, i was unable to find any information related to
>> > > "libhgl.so", could you please guide me regarding that too. Where i
can
>> > > get that file?
>>
>> > There are not information about it at the moment because, as I said,
>> > Android cannot handle arbitrary OpenGL h/w accelerators. This is being
>> > worked on though.
>>
>> > I should have been more clear; the short answer is "it is not possible
>> > to use h/w accelerated GL with version 1.0".
>>
>> > Mathias
>>
>> > > On Nov 26, 10:04 am, Pivotian <[EMAIL PROTECTED]> wrote:
>> > >> thanks Mathias & Markus for your quick responses.
>> > >> Mathias, currently the system/lib folder doesn't contain the
>> > >> "libhgl.so" specified by you. Do you mean to say that we have to
add
>> > >> this file extra into this folder so that libGLES_CM.so, will load
it
>> > >> at runtime and defer to it for 3D h/w acceleration ? If this is
case i
>> > >> will try that stuff. And one more thing is, how i am going to make
>> > >> sure that android will use the hardware codecs rather software
codecs
>> > >> because currently I have no board, so with out the real hardware,
how
>> > >> i am going to know that? As i specified earlier do i have to make
any
>> > >> changes anywhere in the android code to support hardware
acceleration
>> > >> apart from adding the "libhgl.so" file?
>>
>> > >> On Nov 26, 3:03 am, Mathias Agopian <[EMAIL PROTECTED]>
wrote:
>>
>> > >> > Hi,
>>
>> > >> > You need to supply "libhgl.so", which must be a regular OpenGL ES
>> > >> > library. libGLES_CM.so, will load it at runtime and defer to it
for 3D
>> > >> > h/w acceleration.
>>
>> > >> > implementing your own h/w accelerated libhgl.so right now is very
>> > >> > difficult because Android is not ready for this just yet. this is
an
>> > >> > area we're working on as we speak.
>>
>> > >> > mathias
>>
>> > >> > On Tue, Nov 25, 2008 at 1:55 PM, Markus <[EMAIL PROTECTED]> wrote:
>>
>> > >> > > Hi,
>>
>> > >> > > are you sure, that you need 3D acceleration to enable those
codecs? Or
>> > >> > > does your platform offer specialized chips for doing that codec
job? I
>> > >> > > do not know any OpenGL related stuff, that provides access
hardware
>> > >> > > codecs, but I am not familiar with OpenGL-ES. Do you know, how
you
>> > >> > > access on your original platform to those codecs in low level?
Are
>> > >> > > there special libs, which you could recompile for Android?
>> > >> > > If you really need libGLES_CM.so, you must find a way to
replace it by
>> > >> > > our vendor specific implementation, which must also be
converted to
>> > >> > > Android and might require a kernel module to get fast hardware
access.
>> > >> > > So you have to port that kernel module and all the OpenGL
related
>> > >> > > stuff, that is vendor dependent in you case. Maybe it is just
enough
>> > >> > > to integrate hardware support to your kernel, as OpenGL is
something
>> > >> > > like a client/server system. Did you already check, which
libraries/
>> > >> > > devices does libGLES_CM.so access? At the moment, I cannot give
you
>> > >> > > more details about hardware 3D on Android, it is something that
I will
>> > >> > > investigate in the future again.
>>
>> > >> > > bye
>> > >> > > Markus
>>
>> > >> > > On 25 Nov., 13:31, Pivotian <[EMAIL PROTECTED]> wrote:
>> > >> > >> I got to know that in Android OPEN_GL ES is configured by
default for
>> > >> > >> software thats why it uses the software packages of android.
How I can
>> > >> > >> configure the OPEN_GL ES for hardware. Is it just a case of
replacing
>> > >> > >> the
"android/out/target/product/generic/system/lib/libGLES_CM.so" with
>> > >> > >> a new one build with hardware configuration? or any thing more
than
>> > >> > >> that. If I replace the shared object file "libGLES_CM.so" with
the new
>> > >> > >> one configured for hardware, will it work fine ? How I will
know
>> > >> > >> whether its working fine with top level application to whom it
>> > >> > >> provides the interface. Please put some light on it if anyone
has any
>> > >> > >> idea regarding that.
>>
>>
> >
>
ForwardSourceID:NT000039F6
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
