Thanks Mathias, that helps *a lot*. My brain hurts from looking at the memory stuff!
I can now see that each client maps in the 8Mb shared memory region once. What I don't understand at the moment is where the pointer to the surface data is passed back to the client - can you say at what point that happens? When a client uses a buffer (e.g. to draw to it) does it retrieve the pointer by first getting the base address of the related heap, and then digging out an offset from the surface? If we assume that I have my own buffer abstraction (whereby I could map a buffer into both SurfaceFlinger and the client process) that wasn't based on having a Heap of contiguous memory. Then could the following be made to work easily: - Add a new Heap type, which would have an effective base of zero (see later). - The allocator would be simple (wouldn't need to worry about fragmentation itself). - An offset associated with the buffer that was effectively an offset from 0 (yeilding a 32 bit virtual pointer). - I might need to add and subtract a bias or would a heap base of 0 be OK? Also: - Presumably all rendering done by Android honours the fact that the buffer stride may not be the same as the width? - Presumably Android doesn't 'lock' and 'unlock' a buffer between rendering anywhere? Thanks, Fred. On Fri, Jan 16, 2009 at 3:02 AM, Mathias Agopian <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
