On Tue, Jan 27, 2009 at 1:40 AM, F H <[email protected]> wrote: > > 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.
right. > 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? Yes it could have. But at the time I designed it, I wanted surfaceflinger to have full control over what the client could do; in particular I wanted to be able to move the surfaces around between a swap (to be able to defragment surfaceflinger's internal heap for instance). In practice this will probably never happen and we could simplify the control block. Also notice that the control block is also used by the client to tell surfaceflinger which region needs to be updated. > 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). Yes, as I recall. > Am I right in saying that the copybit interface is hardware specific? I'm not sure what you mean here. The implementation is h/w specific. The interface is standard to Android. You can implement your own copybit HAL module, and surfaceflinger will make use of it. > Is there any documentation about the interface copybit.h > and what > /dev/graphics.. should support? note hte copybit doesn't have to be implemented in /dev/graphics. That's why the module exist, to abstract the 2D blit functionality. > Also, I guess that because this is > hardware specific, tailoring it to our own API's won't upset anything? Mathias > > > 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 -~----------~----~----~----~------~----~------~--~---
