Thu 6 March, 4:10pm, S.Semwal, B.Gaignard

LCA14-417: mmap, allocators & sharing buffers - userland experience

• Discussion, not presentation :)• Current state• Your experiences?• Idea of Central dmabuf allocator helpers• Open forum

Agenda

• 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 :)

• 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

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/dequeue mmaped or userptr buffers

Your experiences?

• 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

• 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

• 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

• 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

• 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 maskdma_buf_put()

Proposed Changes in dma-buf usage model

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

Open Forum

More about Linaro Connect: http://connect.linaro.orgMore about Linaro: http://www.linaro.org/about/

More about Linaro engineering: http://www.linaro.org/engineering/Linaro members: www.linaro.org/members