one more thing Mathian I suppose that Android uses the OPENCORE from packet video to do all the stuffs related to video encoding and decoding. I want to use the built in capabilities of my processor which provides Standard level encoding/decoding of multiple content formats including MPEG4, H.263, H.264. How i will use the inbuilt hardware based encoding decoding instead of Android's software based opencore ?
On Nov 26, 2:38 pm, Mathias Agopian <[EMAIL PROTECTED]> wrote: > Hi Phil, > > As I said, all these questions will be answered when we do have the > framework to do this. I can try to answer some: > > > - With respect to integrating OpenGL ES - > > - What forms of OpenGL ES surfaces does Android use? (Window? PBuffer? > > NativePixmap?). > > Window only for now. Of course, a 3rd party GL application is free to > use whatever it wants. > > > - Does Android expect to allow accelerated rendering to a UI component AND > > to be able to draw to it directly? > > SurfaceFlinger expects to be able to do this. If this feature is not > available, it will revert to making copies. There are no clear gl > extensions to do this, so we expect "some" integration to have to > happen for each GL implementation. > > > - Which Android UI components translate into being EGL Surfaces of one > > shape or another? > > All windows in the system. > > > - 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 > > Yes I do. However, these integrations points will change and/or go away. > > > - 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). > > There are mainly 2 issues: one, the EGL implementation needs to know > about the platform's native types (NativeWindowType, this is defined > in egl_natives.h), and then there is the question of GPU management > (when to power it down, when to reset it (if an app goes berserk)) and > finally there is the question of passing surfaces across processes. > These are the "hard" problems that, currently, are not resolved in a > generic way. > > > - Is the source to libhgl around - or is this a third-party entity? > > Never. libhgl *is* the h/w accelerated gl. This is the library that > Android doesn't want to know about, shouldn't care about -- it just > needs to follow a certain protocol (namely EGL 1.0 at the bare > minium). By definition this cannot be part of Android, it is a "board" > dependent component (a user-space driver if you will). > > > - Does pixelflinger always use OpenGL for surface composition? > > pixelflinger never use h/w acceleration -- it is just a software > renderer used *when* there is no h/w acceleration. SurfaceFlinger, on > the other hand, android's composition engine uses OpenGL ES. > > > - 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). > > No. It would just not work at all. What would a "generic" driver > (whatever that means) do when eglCreateWindowSurface() is called on > it? > > Now if you *reallllllllly* want to use your h/w driver now, there is a > (non efficient, but probably good enough) way to do it. You could do > all the rendering in hardware in "private" buffers, and when > eglSwapBuffers() is called, you could make a copy (with memcpy). > > Have a look at libagl.so (it's part of core Android, and therefore is > opensource), it is our *software* OpenGL ES implementation. In > particular, look at egl.cpp, which is its EGL implementation. Yours > should look like something like it. If your GPU is able to render > into "regular" memory you're all set -- it will "just work". If it > doesn't (like most GPU), you'll need to make a copy. > > Note that what I describe here is a STOP GAP, until we get the HAL put > together. You won't get good performance with this. Also, be *assured* > that your driver will break when we roll out the new GPU framework and > that no effort will be made to maintain source or binary compatibility > -- you've been warned :-) > > I would strongly encourage you to try to make your h/w work with the > "trick" above where you make a copy of the framebuffer upon > eglSwapBuffers(), this will require you to do at least half of the > work needed for the "real thing". > > Mathias > > > > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
