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
device’s 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 doesn’t 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 doesn’t 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-buf’s 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: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members