Hi, On Thu, Jan 15, 2009 at 9:53 AM, F H <[email protected]> wrote: > I have a few questions regarding integration of an accelerated capability > into Android.
Before we go further, I would like to point out that there are no OpenGL ES driver model in Android 1.0. We're trying very hard to finalize it for the cupcake release but there are no garantees. You must understand that the work you'll be doing for h/w integration before that happens, will become obsolete and we will not try to ensure backward compatibility. > I understand that Android must draw to surfaces in Software. In our > environment we can create a buffer that can be drawn to both by Hardware and > software, but it is one of our components that must allocate the memory in > order to do this. > I've been looking at some various components in SurfaceFlinger that may be > of help (or possibly red-herrings) and have a few questions: > - Do *all* surfaces which can be drawn to instances of one particular class > and if so which one? (I'd like to hook in our own memory surface class at > this point rather than a raw memory allocation). Is there a single point for > which this allocation is done? The allocation is done in SurfaceFlinger. The current scheme is very messy. Look at Layer.cpp and LayerBitmap.cpp. They eventually acquire an allocator object. In fact, on the G1, there is the same issue, all the surfaces need to be allocated in a certain way (look for the Pmem allocator). > - Does a layer have a 1:1 correspondence with a drawable Surface? Or are > multiple Surfaces placed into a Layer? The naming conventions are not always consistent, but in short: A Layer is something that can be composited by SurfaceFlinger (should have been called LayerFlinger). There are several types of Layers if you look in the code, in particular the regular ones (Layer.cpp) , they are backed by a Surface, and the LayerBuffer (very badly chosen name) which don't have a backing store, but receive one from their client. A Surface has a certain number of Buffers, usually 2. Note that the GGLSurface type, should have been called GGLBuffer. > - Presumably multiple layers are just composited to the final buffer in > their Z order? Yes. > - What's the GPUHardware class for? - is it there just for chip access > arbitration or debugging (It looked for example like the allocator was only > used if the debug.egl.hw property were set). Is this needed if arbitration > is handled through EGL/GL? GPUHardware will go away. It is used for managing the GPU (Arbitration) and allocating the GPU memory, so that GL Surfaces can reside on the chip. > - Is it true that for surfaces only one allocator will be used either GPU, > /dev/pmem or heap in that order? Under what circumstances is /dev/pmem > needed? The current implementation deals only with the emulator and the G1. The g1 needs pmem memory for using h/w acceleration for the compositing. So pmem is always used on the G1 (which doesn't use ashmem at all). > - Is the 8Mb SurfaceFlinger allocation per process or a one-off for the > system? Depends. On the G1 it's for everyone. and it's physical. On the Emulator we have 8MB of *address space* per process/ > - Presumably there is only one compositor (running in a system thread)? When > a surface is allocated is it done through the applications thread or the > thread that looks after the composition? (Is there an accompanying call > somewhere to map memory from one process into another?) Memory is always allocated in Surfaceflinger, it is stuffed into an IMemory object, which takes care of mapping it to the destination process automatically (see IMemory.cpp, if you want to hurt your brain). > - When the compositor is refreshing the display what mechanisms is it using > to access buffers that are in a different address space? They're all in shared memory. The SurfaceFlinger mmaps the surface heaps (which is different from the main heap) of each of its client processes into its own address space. This consumes 8MB of address space per client process inside surfaceflinger. > - On the off-chance is there any porting documentation related to surface > flinger and how it works? Sorry. :) You should be able to implement basic 2D h/w acceleration though the copybit hal module. I hope this helps. Mathias --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
