DMA-BUF Image Sharing: Layout Compatibility and Completed Work

Describe the image as well as its handle

Linux 6.18's pixel-buffer exchange model carries dimensions, pixel format, modifier, and each plane's handle, byte offset and byte stride. Planes can share one memory buffer or occupy separate allocations. The format describes pixel representation; the modifier describes memory layout. A handle alone leaves that interpretation incomplete.

For the proposed path, have the provider identify the delivered description and the usages covered by each participant's support. An inference component reading an image and an encoder consuming it are separate required usages. A generic statement that both support DMA-BUF does not answer whether they accept this delivery.

This explanation uses the named Linux 6.18 documentation. The appointed application and driver owners establish support and observed behavior for the offered releases and devices. It is an interface and purchasing explanation; implementation and work authorization require their own responsible owners.

References: [PX18]

BUF3: two compatible stages leave the encoder unresolved

Consider original fictional case BUF3. Decoder D produces an image that inference stage I analyzes and encoder E must also read for encoding. Stipulate that both consumers need that same decoded image, with no intervening in-place modification. All three accept one agreed image-format definition and the same stipulated dimensions. Hold that format fixed while comparing layouts; place all its planes in one backing allocation for this example.

D supports abstract layout tokens {L, T}. I supports {T}. E supports {L}. These tokens and capability sets are invented comparison inputs, not real DRM modifier identifiers or device claims. In particular, L and T are not assertions about linear or tiled support on actual equipment.

D and I have the common candidate {T}. A proposal limited to those two participants can therefore identify T for further qualification. Add E, however, and {L, T} intersected with {T} intersected with {L} is empty. Choosing T leaves E outside the stipulated support; choosing L leaves I outside it.

Successful sharing between D and I would answer a useful part of the requirement. It would leave the requested three-participant sharing unresolved. Separate demonstrations of D with I and D with E could use different allocations and layouts, so their success would still leave the single-allocation requirement open.

An offer retaining these capability sets needs to explain an alternative path, any additional image allocation or transformation, and its responsible provider. There is no universal conversion established by this example. The buyer can consider a declared alternative when it meets the application requirement, while keeping its extra work visible.

References: [PX18]

A changed encoder makes T a candidate, not a delivered result

Now consider a separate fictional offer for BUF3 in which E supports {L, T}, with every other layout premise retained. The three-way intersection becomes {T}. This resolves the earlier incompatibility in the capability description.

The supplier still needs to establish the actual allocation's selected layout and plane metadata, and successful supported import for every intended use. The Linux documentation expressly warns that a nonempty modifier intersection does not guarantee import: consumers can impose further constraints. Alignment or memory-location requirements can remain outside what the format/modifier pair expresses.

A useful response names those remaining conditions and explains how the supplied allocation satisfies them. Evidence for D-to-I import leaves E's import open until E is covered too. If a provider claims GPU-local placement, that claim needs its own support; the DMA-BUF label does not select it.

Missing layout information is also not a declaration of a linear layout. A path relying on implicit modifiers needs its implementation-specific interpretation explained. Implicit layout interpretation and implicit synchronization refer to different questions.

References: [PX18]

BUF3: the handle arrives four milliseconds before the image

Independently of either layout offer, stipulate this timeline for BUF3: its handle is available at 2 ms; D finishes producing the image without error at 6 ms; I reads it from 6 ms until 9 ms; and a conflicting overwrite of that same storage is proposed at 8 ms. These are invented times for reasoning about dependencies, not measured latency or a recommended schedule.

The reference arrives 6 - 2 = 4 ms before production completes. Receiving it at 2 ms therefore supplies no basis for treating the complete produced image as available then. Under the example's assumptions, I's stated read interval begins only when the producer has finished without error.

At 8 ms, D's production is already complete, but I still needs the old contents. Overwriting them conflicts with the final 9 - 8 = 1 ms of I's stipulated reading interval. Producer completion resolved the dependency before reading; it did not resolve the later dependency before overwriting.

At 9 ms, the example clears I's reading interval only. It supplies no encoder access interval. Reuse for the whole BUF3 path remains unresolved until E's use and any other outstanding conflicting access are covered. Granting E a compatible layout in the second offer changes none of these time relationships.

The useful handoff description follows the image version being consumed, the work producing it and every use that must finish before its storage is overwritten. Retaining a reference keeps an identity available; it does not create another independent image or permission to replace its contents.

References: [DB18]

Distinguish completion status, access ordering and CPU coherency

The Linux 6.18 framework separates dma-buf sharing, dma-fence asynchronous completion and dma-resv associations between buffers and fences. Whether an interface uses implicit synchronization or requires explicit synchronization matters to the handoff. Sharing alone does not establish that every participant's dependencies are represented and respected.

A signaled fence can carry an error. Completion without a reported fence error and completion due to an error are distinct outcomes; neither is an application-level image-quality verdict. BUF3 expressly assumes error-free production at 6 ms. A different return reporting failed production cannot inherit that premise merely because its fence has signaled.

CPU cache coherency is another requirement when CPU access occurs. The documented userspace coherency mechanism does not exclude simultaneous access by other devices or processes. Completion of tracked work also leaves any necessary CPU-access preparations to be addressed.

For a proposed CPU inspection step, ask the software owner to explain both coherent access to the intended contents and exclusion of conflicting work. A claim about one leaves the other question open. No CPU access is stipulated in BUF3, so its timeline supplies no evidence for such an added step.

References: [DB18]

Compare the offered result across all three stages

Offer A retains BUF3's original sets and describes a shared D-to-I image followed by a separately supplied encoder input. It can be a coherent proposal if the responsible provider identifies that second input's allocation and representation, how it is produced, and the completed-work relationships on both sides. The buyer can then assess the complete path against the actual requirement. A requirement for one shared allocation across D, I and E remains unmet by A's stated sets.

Offer B includes the changed encoder support and proposes one T-layout allocation for all three uses. Its capability description addresses the common-layout requirement. Compare its supplied evidence for the actual delivered image, each supported import, producer handoff and final release for conflicting reuse. Repeating the two-stage demonstration would leave B's broader result unestablished.

Make the comparison concrete with a request tied to the named application, devices, drivers and releases: identify which stages share BUF3, which require a different representation or allocation, who supplies any intervening transformation, and what evidence covers valid access and reuse at every handoff. An unresolved encoder dependency belongs in that response even when decoder-to-inference sharing works.

The appointed application and driver owners establish actual support and observed behavior. A complete response lets the buyer choose between a supported shared path and a declared alternative without hiding extra storage, processing or unresolved dependencies behind the same DMA-BUF label.

Keep the sharing boundary attached to the image being delivered

BUF3's inference-stage premise says that I accepts the stipulated image representation. It supplies no account of later model-input preparation. If the actual application requires a different shape, numeric type or representation, have its owner identify that transformation and resulting storage before extending a copy-avoidance claim through inference.

Use the related Bayer guide when the question is how sampled colors become derived RGB components. Use the tensor-view guide when the question is how tensor shapes and strides share underlying storage. Those representation decisions remain useful even after image import succeeds.

The related DMA-address guide separates CPU and device address spaces; pinned-memory guidance follows ordinary host/device staging; GPUDirect Storage guidance follows file-byte paths. AF_XDP follows packet frames and ring ownership. Their separate worked examples should not be read as evidence of BUF3 compatibility or completion.

Scope physical installation separately when the equipment needs it

If the customer-selected image-processing system also needs physical installation, Leviathan's Rack-and-Stack Installation service covers an agreed equipment-mounting, IT-cabling, labeling and physical-record package. Use the related service and project-inquiry links with a nonconfidential equipment list, rack plan, approved endpoints, site window and required physical handoff to discuss scope and availability.

DMA-BUF integration, image conversion, driver support and application acceptance remain with the appointed software and platform providers.

References: [L1]