Hi Mathias, That is extremely helpful.
Presumably, not having a kernel handle in shared memory is a security thing? Thus, if I needed to pass such a thing around I'd do it as a part of the Parcel. Incidentally, if SurfaceFlinger doesn't use the surface-related control block at all - then the relevant client information could simply have been passed back in the Parcel? Or would this make the operation of re-size difficult? w.r.t. Surface Flinger and buffer access - I guess the copy of the information it uses is in the 'mSurface' GGLSurface entity (which just has a pointer). Am I right in saying that the copybit interface is hardware specific? Is there any documentation about the interface and what /dev/graphics.. should support? Also, I guess that because this is hardware specific, tailoring it to our own API's won't upset anything? On 1/26/09, Mathias Agopian <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
