Add support for allocating DMA buffers #2170
Conversation
ahesham-arm
force-pushed
the
dma_buf
branch
3 times, most recently
from
c5cdd6d to
841cf41
Compare
Signed-off-by: Gorazd Sumkovski <[email protected]>
ahesham-arm
force-pushed
the
dma_buf
branch
2 times, most recently
from
e927f43 to
7add709
Compare
The test demonstrates how an imported buffer can be created from a DMA buffer, allocated using the DMA heap system, which is now supported by the CTS. Signed-off-by: Gorazd Sumkovski <[email protected]>
ahesham-arm
force-pushed
the
dma_buf
branch
2 times, most recently
from
01b977f to
0022809
Compare
Add the ability to specify the type of DMA heap to use when allocating a DMA buffer, the path of which can be overridden using an environment variable, `OCL_CTS_DMA_HEAP_PATH_SYSTEM`. Add Doxygen-style documentation for the new function. Signed-off-by: Ahmed Hesham <[email protected]>
|
Discussed in the 2025/01/21 memory TSG: we should update the PR to skip the tests when hitting permission issues instead of failing them. |
|
|
|
Updated to address the review comments. |
|
We are ok with this change |
| int dma_buf_fd = allocate_dma_buf(buffer_size_bytes); | ||
| if (dma_buf_fd < 0) | ||
| { | ||
| if (dma_buf_fd == TEST_SKIPPED_ITSELF) |
There was a problem hiding this comment.
This is fine for now, but it's overloading the int return type and making an assumption that TEST_SKIPPED_ITSELF is a negative value, and it's possible it won't be true in the future - see #2276.
There was a problem hiding this comment.
I agree. I think we should aim for using something like std::optional if we are sticking with standard C++ options, or an equivalent to Rust's std::Result.
Review feedback: failure to open the DMA device will typically be caused by EACCES; i.e. insufficient filesystem permisisons. If that happens, the test should be skipped, instead of failing. This is done by returning the special value `TEST_SKIPPED_ITSELF` from the `allocate_dma_buf` function. Similarly, if the platform does not support DMA heaps, return `TEST_SKIPPED_ITSELF` instead of failing. Update the documentation and demo test case to reflect this change.
|
Merging as discussed in the February 25th memory subgroup. |
|
Hi, on systems where The warning seems accurate: Could you take a look at this? Would you like me to? |
Thank you for reporting this, sorry for the break. I have a fix for this but unfortnatuely I cannot test this locall. Can you please try it and comment on the PR if it works for you? Thanks! |
This adds support for allocating DMA buffers on systems that support it, i.e. Linux and Android.
On mainline Linux, starting version 5.6 (equivalent to Android 12), there is a new kernel module framework available called DMA-BUF Heaps. The goal of this framework is to provide a standardised way for user applications to allocate and share memory buffers between different devices, subsystems, etc. The main feature of interest is that the framework provides device-agnostic allocation; it abstracts away the underlying hardware, and provides a single IOCTL,
DMA_HEAP_IOCTL_ALLOC. Mainline implementation provides two heaps that act as character devices that can allocate DMA buffers; system, which uses the buddy allocator, and cma, which uses the CMA (Contiguous Memory Allocator). Both of these are kernel configuration options that need to be enabled when building the Linux kernel. Generally, any kernel module implementing this framework is made available under /dev/dma_heaps/<heap_name>, e.g. /dev/dma_heaps/system.The implementation currently only supports one type of DMA heaps;
system, the default device path for which is/dev/dma_heap/system. The path can be overridden at runtime using an environment variable,OCL_CTS_DMA_HEAP_PATH_SYSTEM, if needed. Extending this in the future should be trivial (subject to platform support), by adding an entry to the enumdma_buf_heap_type, and an appropriate default path and overriding environment variable name.The proposed implementation will conditionally compile if the conditions are met (i.e. building for Linux or Android, using kernel headers >= 5.6.0), and will provide a compile-time warning otherwise, and return
-1as the DMA handle in runtime if not.To demonstrate the functionality, a new test is added for the
cl_khr_external_memory_dma_bufextension. If the extension is supported by the device, a DMA buffer will be allocated and used to create a CL buffer, that is then used by a simple kernel.This should provide a way forward for adding more tests that depend on DMA buffers.