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.
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. > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
