On Mon, Jan 26, 2009 at 8:45 AM, F H <[email protected]> wrote: > Hi Mathias, > > - It seems to me that clients of SurfaceFlinger don't care about memory > allocation and that accesses to surfaces are via GGLSurfaces, which just > contain a pointer (not a base/offset combination). For a client, access to > this pointer is gated through the surface lock/unlock calls. So clients > should be O.K. regardless of how the surface memory is allocated.
correct. > - It's a little less clear where SurfaceFlinger is called - does it access > the surfaces in the same way as a client (i.e. through a lock/unlock) or > does it just grab hold of the pointer (base/offset) and use it as it sees > fit. It doesn't use an lock/unlock mechanism. The whole point of SurfaceFlinger's design is that it never needs to acquire a lock when accessing the surface. All the synchronization is done with atomic operations in the control block (which lies in shared memory with the application). things are designed so that even if the application messes with this memory, surfaceflinger won't crash and only that application's display may be affected). For this reason, SurfaceFlinger doesn't use *any* information in the control block, instead it has its own version of the data needed to display a surface. It knows which buffer to display based on the values of some bits on the control block and is guaranteed that the application won't touch the buffer while SurfaceFlinger accesses it (unless the app cheats, we it's its problem). While SurfaceFlinger never blocks (by design), a client application may be blocked on lockSurface() until SurfaceFlinger consumes one of its buffer. > - w.r.t. complexity, The scenario I'm trying to get to should be simpler and > not need a surface heap. > - I can see where I would need to allocate my Surface (in LayerBitmap) - and > store a relevant handle in the shared control block. Remember you cannot store any "handle" in there that cannot live in shared memory. This prevents pointers (of all forms). you can only store int in there. In particular, you cannot store a filedescriptor (or any kernel object) in the control block. > - I can see where I would map my Surface into client space (in the > lockSurface call in SurfaceComposerClient) using the handle in the control > block. (see above) > - Where I see more difficulties is in SurfaceFlinger, which rather than > propogate a buffer pointer around the place a base/offset gets bounced > around. e.g. in things like the copybit_image_t struct. Yes. The copybit api doesn't assume that the memory can be mapped at all. Therefore the concept of an"address" is irrelevant. For instance, all the data could be in video memory that cannot be mapped. Instead, a buffer is identified with an filedescriptor + offset. It possible that for the release after cupcake, we'll make that mechanism even more generic. > (I also notice that > this struct doesn' contain a stride - so it begs the question as to whether > SF honours the stride associated with the buffer? It does. The copybit structure contains a width / height + a "rect", which allows to "emulate" the stride (basically, width is set to the stride, and the rect is set to the width). > - Is there any reason wht SF couldn't just propogate a simple pointer around > (rather than a base/offset - which is only relevant for allocation > purposes)? It definitely cannot propagate a pointer to its clients which live in a different process and even internally it may not always make sense to use a pointer when using h/w accelerated graphics: a fd+offset is one step in the right direction in terms of abstraction, but it's not ambitious enough and as I said we will probably improve this in a future release. Mathias > > On Thu, Jan 22, 2009 at 11:31 PM, Mathias Agopian <[email protected]> > wrote: >> >> On Thu, Jan 22, 2009 at 3:04 PM, F H <[email protected]> wrote: >> > >> > It goes back to my desire to use my own allocator for surface memory. >> > I have a degree of enthusiasm to do this because many of our own >> > underlying components (e.g. OpenGL ES, Video Codecs, Blit engines and >> > so on) use our own abstraction rather than a heap. So when a Surface >> > is to be allocated I need SurfaceFlinger to allocate one of these >> > buffers (and map it into SurfaceFlinger's address space) and pass back >> > information to the client who then needs to use this handle to make an >> > ioctl call to map the related buffer memory into the user client >> > space. >> >> I see. Well this is complicated, basically you're trying to work >> around the current design and I'm not very comfortable with this. >> You're looking for an abstraction of mmap basically, which we don't >> have. So you'll have to build your own "everything" parallel to the >> current mechanisms. I don't have enough information about your system. >> >> Personally I would advise against going this route for now. >> >> Mathias >> >> >> > >> > On 1/22/09, Mathias Agopian <[email protected]> wrote: >> >> >> >> On Thu, Jan 22, 2009 at 2:46 PM, F H <[email protected]> wrote: >> >>> >> >>> Thank you Mathias, >> >>> >> >>> Very helpful as usual. >> >>> >> >>> If I wanted to convey a bit more information between SurfaceFlinger >> >>> and the client, would it be best to convey it via the control block or >> >>> add it to the Parcel? >> >> >> >> Can you elaborate? What information? >> >> >> >> Mathias >> >> >> >>> >> >>> Fred. >> >>> >> >>> On 1/22/09, Mathias Agopian <[email protected]> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> On Tue, Jan 20, 2009 at 3:37 AM, F H <[email protected]> >> >>>> wrote: >> >>>>> Hi Mathias, >> >>>>> >> >>>>> Android typically creates two buffers per surface. Presumably this >> >>>>> is so >> >>>>> that one of them can be locked by an application for rendering while >> >>>>> the >> >>>>> other (complete buffer) is available to SurfaceFlinger for >> >>>>> compositing? >> >>>> >> >>>> correct. >> >>>> >> >>>>> What kinds of surfaces would have only one associated buffer? >> >>>> >> >>>> Surfaces with content that never changes? :-) >> >>>> But why do you ask? SurfaceFlinger never allocate a surface with only >> >>>> 1 >> >>>> buffer. >> >>>> >> >>>> >> >>>>> Surface Buffer access is guarded by calls to Lock/Unlock(andPost) - >> >>>>> there >> >>>>> is >> >>>>> another fcunction - nextBuffer which looks like it always returns >> >>>>> data >> >>>>> pertinent to the front buffer without effecting a lock. >> >>>> >> >>>> nextBuffer() was an experiment which was never cleaned-up. Don't use >> >>>> it (I mean it). nextBuffer will most likely disapear in cupcake. >> >>>> >> >>>>> Are all accesses to buffers gated through either lockSurface (& >> >>>>> corresponding unlock..) >> >>>> >> >>>> correct. >> >>>> >> >>>>> or nextBuffer? When is nextBuffer used as opposed to >> >>>>> the lockSurface? (Seems like a misleading name). >> >>>> >> >>>> see above. >> >>>> >> >>>>> Does the information ultimately get conveyed to a GGLSurface object >> >>>>> before >> >>>>> any Android rendering is done? >> >>>> >> >>>> I need to double-check on that. I think this might still be the case. >> >>>> >> >>>>> I also noticed a limit on the number of Layers a client can have >> >>>>> (NUM_LAYERS_MAX), which is set to 31. Does this pose a problem for >> >>>>> applications that for example use lots of UI type widgets? >> >>>> >> >>>> No. A "layer" correspond to a "window" in the UI (like a status-bar, >> >>>> a >> >>>> dialog, or the main window). >> >>>> >> >>>>> Also I guess 31 >> >>>>> is used as a number just so that the control block stays smaller >> >>>>> than >> >>>>> 4k? >> >>>> >> >>>> Yes. It also simplifies a few things to keep track of surfaces (the >> >>>> implementation uses an uint32 as a bit set). >> >>>> >> >>>> >> >>>> Mathias >> >>>> >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Fred. >> >>>>> >> >>>>> >> >>>>> > >> >>>>> >> >>>> >> >>>> > >> >>>> >> >>> >> >>> > >> >>> >> >> >> >> > >> >> >> > >> > > >> > >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
