On Fri, Jan 16, 2009 at 8:18 AM, F H <[email protected]> wrote: > 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?
There is a control block in shared-memory, per surface. It contains an offset to the surface's buffers from the beginning of their heap. Both the client and SurfaceFlinger use this offset to access the buffer; ;but they each have their own view of the pointer to the heap. Have a look at SurfaceComposerClient.cpp for implementation details. > 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? yes. the offset is controlled by SurfaceFlinger. > 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. That would not work. SurfaceFlinger's design assumes Surfaces are attached to a heap. A heap is by definition contiguous address-space (not to be confused with physically 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? No. absolutely not (see below). > Also: > - Presumably all rendering done by Android honours the fact that the buffer > stride may not be the same as the width? yes. > - Presumably Android doesn't 'lock' and 'unlock' a buffer between rendering > anywhere? correct. If you need to use your own memory type, you'd make the changes in VRamHeap.cpp, which is where whole the memory management is done (you'd need the cupcake branch, because things were even more complicated before). In theory whole you need to do is to write a kernel driver than can allocate your own type of memory, and use that instead of /dev/pmem or /dev/ashmem. for this to work, your driver will have to be able to allocated several of these heaps, which may not be possible. On the G1, we had 8MB total to share with all apps. For obvious security reason, we couldn't allow each client app to map the same 8MB into their address space. This is where pmem comes into play. pmem wraps a new "heap" around a master heap and allows the server process to "slap" and "unslap" individual pages in its client processes. "slapping" is like "mmapping" except when you "unslap" the pages are replaced by a "garbage" page (instead of a black hole). This way, the unique 8MB heap, is shared securely between all clients, which, each are allowed to "see" only the pages they need. You would have to replicate this mechanism if your kernel allocator cannot create multiple heaps. The easiest way would be to start from our pmem driver and modify it to suit your needs. Mathias > > 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 -~----------~----~----~----~------~----~------~--~---
