Hi Mathias:
Just interested to know, what's the relationship between surfaceflinger
and pixelflinger?
Meanwhile, is there some document on sufraceflinger and pixelflinger?
Thanks.
--
Chen
On Sat, Jan 17, 2009 at 5:58 AM, Mathias Agopian <pixelflin...@google.com>wrote:
>
> On Fri, Jan 16, 2009 at 8:18 AM, F H <expelia...@googlemail.com> 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 <
> pixelflin...@google.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Jan 15, 2009 at 9:53 AM, F H <expelia...@googlemail.com> 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: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
