lca14: lca14-417: mmap, allocators & sharing buffers: userland perspective

Download LCA14: LCA14-417: mmap, allocators & sharing buffers: userland perspective

Post on 13-Jun-2015




3 download

Embed Size (px)


Resource: LCA14 Name: LCA14-417: mmap, allocators & sharing buffers: userland perspective Date: 06-03-2014 Speaker: Sumit Semwal


  • 1. Thu 6 March, 4:10pm, S.Semwal, B.Gaignard LCA14-417: mmap, allocators & sharing buffers - userland experience

2. Discussion, not presentation :) Current state Your experiences? Idea of Central dmabuf allocator helpers Open forum Agenda 3. Intentions of this session: Share the changes likely to happen as part of UMM initiative that would affect how userspace works with allocation and buffers Share idea of central buffer allocator helpers Understand from the audience if the steps make any sense to their experience domain; if not, what are the gaps. Try to find ways to fulfill the gaps; or at least document them clearly Discussion, not presentation :) 4. Pre-UMM days, a sample userspace application, eg. one working with a camera with v4l2 interface and a DRM based display, would need to: know about the v4l2 and drm buffer structs, know who (or decide) will allocate, and sometimes have that fixed for each platform, have some middleware component (like GStreamer) which could handle conversions from one type of buffers to the other, in some cases, copy over data across buffers. Pre-UMM State 5. GStreamer 0.10 without dma-buf Capture plugin: v4l2src Display plugin: ximagesink v4l2 driver DRM driver buffer with v4l2 metadata (index, userptr) buffer send through Xserver parameters conversion from v4l2 metadata to X metadata, may require copying buffer data queue/de queue mmaped or userptr buffers 6. Your experiences? 7. dma-buf framework added to make sharing buffers across frameworks easier; no longer need to know all the buffer structs, if all participating subsystems use the dma-buf API Also allows to defer allocation of backing storage till first map_attachment() request from one of the attached devices There is interest in having central dmabuf allocator helpers These can help in the userspace not having to worry about which devices allocator function to invoke; Userspace might be able to just: use a generic dma-buf exporter device, have each participating importer share their constraints during attach(), have the exporter device use these constraints to decide on where to allocate from. Changes post UMM initiative 8. dmabuf usage model: dma_buf_get() dma_buf_attach() dma_buf_map_attachment() dma_buf_unmap_attachment() dma_buf_detach() dma_buf_put() dmabuf exporter doesnt necessarily allocate backing buffer until map_attachment() time. dma-buf usage model 9. With dma-buf, now the same sample userspace application would need to: still know about the v4l2 and drm buffer formats, still know who will allocate, and sometimes have that fixed for each platform, the allocator will also be the exporter of dma-buf, and the other users of the buffers can just be attached to the same exported buffer, and use the same underlying memory no copying needed! have some middleware component (like GStreamer) which would not need to do any conversions across types of buffers for zero-copy purposes. (middleware would still be needed for other uses though - cap negotiation etc). Current State 10. Create a set of constraint aware dma-buf allocation helper functions On dma_buf_attach(), store compatible constraints flags for that device in dma-buf Provide helper functions that will look at constraints flags on dma-buf and allocate memory from the compatible heap userspace could be just one central dma-buf allocator, which could be supplied with platform-specific heaps Idea of Central dma-buf allocator helpers 11. New functionality in the usage sequence: dma_buf_get() - importer to set constraints in dev->dma_parms- >access_constraints_mask dma_buf_attach() - adds constraint to dma-buf; will return error if new device attachment doesnt satisfy existing constraints dma_buf_map_attachment() - exporter looks at constraint mask, and (optionally) uses allocation helpers to allocate dma_buf_unmap_attachment() dma_buf_detach() - re-calculates dma-bufs constraint mask dma_buf_put() Proposed Changes in dma-buf usage model 12. Gstreamer 1.X with dma-buf Capture plugin: v4l2src Display plugin: waylandsink v4l2 driver DRM driver wayland server central dma-buf allocator buffer pool: negotiated and shared by the both plugins dma-buf queue/dequeue dma-buf buffer dma-buf fd imported by prime wayland protocol create buffer: return fd 13. Open Forum 14. More about Linaro Connect: More about Linaro: More about Linaro engineering: Linaro members: