/!\ DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT:DRAFT /!\

dma-buf

Current status: initial patchset accepted by Linus T and released in linux-3.3, additional features now being implemented.

  • Validated on OMAP4 on Xorg and V4L2 camera; hacks required to work around lack of synchronization objects, some limitations to be addressed

Priority

Description

Launchpad Blueprints

Status

Platform (Android, Linux, ChromeOS)

Medium

Synchronization objects: needed to avoid user/kernel space roundtrips during render complete and page flip operations; this is required for the case where GPU and display driver (KMS) being separate

the sync object blueprints are linked in a dependency chain under dmabuf-sync-objects. Other blueprints in that chain are: dmabuf-usage-hint, dmabuf-fence-object, dmabuf-multiple-prepares, dmabuf-cache-domain-object

TODO

All

Medium

Mapping Hints: Concerns from v4l2 around "expensive" per-frame or per-access operations involving negotiating API - need some kind of hint that changes have occurred and therefore the importer should remap

dmabuf-attachment-hint, dmabuf-usage-hint

TODO

Linux

High

CPU buffer mmap: Allowing an imported buffer to be mapped on the CPU (eg for the glTexSubImage2D and glReadPixels use cases)

dmabuf-user-mmap

Good Progress

All

Medium

EGLImage extension: allow interoperability between a dma-buf handle and a GL userspace

dmabuf-egl-extension

TODO

All

Medium

Buffer set mapping: support for mapping a collection of buffers in order to avoid thrashing under memory pressure

dmabuf-multi-buffer, dmabuf-multiple-prepares

TODO

All

Medium

Non-CPU-backed buffers: dma-buf needs to handle device-mapped buffers containing protected content with no CPU backing

dmabuf-non-cpu-backed

TODO

All

Non-features

  • dma_buf has no way to allocate a buffer: Consensus is that allocation of buffers should happen in other subsystems, namely DRM/KMS for the simple graphics use case.

  • pin/unpin API: The need for a pin/unpin API was discussed, in addition to the hint mentioned above.

  • buffer pools: If these are actually needed, they should be implemented in userspace.

  • X11 DRI2 protocol does not provide a way to dup a file descriptor over the X-socket connection - there is a proposed solution for this : to use a DRM driver which supports the GEM memory manager and use GEM's flink to create an ID for the buffer object which can be passed from the X-server DDX driver to the application in a DRI2 get buffers response

Need clarification

  • Allowing to queue multiple jobs into the kernel which require the same buffer (seems to me more generic than dma-buf per se, but related - the proposed solution was to use ARM's "kernel dependency system"). Needs a concrete proposal as to what is required to do there.
  • May need to introduce some new in-kernel API to help describe the case of many components being actually less "connected" than in the PC space

DMA Mapping changes

Current status: v7 patchset submitted to list (link to message thread) by Marek; reviews on-line ongoing.

  • Patch is likely to evolve until accepted
  • However, unclear who is the right maintainer to review this patchset

Priority

Description

Status

High

dma_alloc_unmapped: dma-mapping API requires pages in kernel linear mapping, which we would like to avoid for shared buffers

TODO

Medium

DMA context: encapsulate opaque device-specific dma mapping context

TODO

Low

Cache domain hierarchies: Avoid unnecessary cache operations when devices share same cache tree

TODO

?

Providing debugging calls from the API

TODO

?

Need to cater for the case of kzalloc failing for sizes bigger than PAGE_SIZE

TODO

CMA

Current status: v23 patchset submitted to the list.

  • Patchset included minor bugfixes (related to memory compression) and simple updates to memory reclaim.
  • Has ACKs from Mel Gorman and Arnd on all but 2 patches
  • Branch included in linux-next
  • According to author Marek Szyprowski, CMA will be merged into Andrew Mortons MM tree targeted for inclusion into kernel 3.5

V4L2

  • Only drivers using videobuf2 will be able to use dma-buf objects
    • Importer and exporter role need support; Sumit has implemented importer support, but changes only the dma-contig allocator
    • Tomasz has posted a patchset based on Sumit's work
    • vmalloc and dma-sg support still need doing (TODO)
  • Consolidation branch for V4L2 dma-buf work with the RFC versions of patches is available at

    • tree: git://github.com/sumitsemwal/kernel-omap4.git
    • branch: 3.3rc3-v4l2-dmabuf-RFCv1

DRM (including KMS and GEM)

Current status: initial branch in RFC status posted by David Airlie as part of drm-prime work; working through issues and limitations

  • All DRM drivers need updating for dma-buf

WorkingGroups/Middleware/Graphics/UMM/Status (last modified 2012-04-09 18:04:28)