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](https://github.com/torvalds/linux/blob/master/drivers/dma-buf/dma-heap.c).
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](https://developer.toradex.com/software/linux-resources/linux-features/contiguous-memory-allocator-cma-linux/)
(Contiguous Memory Allocator). Both of these are [kernel configuration
options](https://github.com/torvalds/linux/blob/master/drivers/dma-buf/heaps/Kconfig)
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 enum `dma_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
`-1` as the DMA handle in runtime if not.
To demonstrate the functionality, a new test is added for the
`cl_khr_external_memory_dma_buf` extension. 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.
---------
Signed-off-by: Gorazd Sumkovski <gorazd.sumkovski@arm.com>
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Co-authored-by: Gorazd Sumkovski <gorazd.sumkovski@arm.com>
fixes#2247
* For the `negative_create_command_buffer_not_supported_properties`
test, the only property we can check for is simultaneous use. All other
properties are part of other extensions and hence will generate
`CL_INVALID_VALUE`, not `CL_INVALID_PROPERTY`.
* Checks whether the `cl_khr_command_buffer_multi_device` extension is
supported when using `CL_COMMAND_BUFFER_DEVICE_SIDE_SYNC_KHR`, instead
of `device_side_enqueue_support`.
* If the `cl_khr_command_buffer_multi_device` extension is NOT supported
and the `CL_COMMAND_BUFFER_DEVICE_SIDE_SYNC_KHR` command buffer creation
flag is used, the expected error code is `CL_INVALID_VALUE`, not
`CL_INVALID_PROPERTY`.
Update cl_khr_command_buffer tests to reflect changes from
https://github.com/KhronosGroup/OpenCL-Docs/pull/1292
* Moves negative test for
`CL_DEVICE_COMMAND_BUFFER_SUPPORTED_QUEUE_PROPERTIES_KHR` from
command-buffer creation to enqueue.
* Moves negative test for
`CL_DEVICE_COMMAND_BUFFER_REQUIRED_QUEUE_PROPERTIES_KHR` from
command-buffer creation to enqueue.
* Introduces a negative test for `CL_INVALID_DEVICE` on command-buffer
enqueue for new error condition in spec. Although it requires a context
to be contain more than 1 device, which I'm not sure if possible in
current test framework.
* Introduces a new test that created a command-buffer using a queue
without the profiling property set, then enqueues the command-buffer to
a queue with the profiling property set.
* Introduces a new test that creates a command-buffer with an in-order
queue, enqueued on an out-of-order queue.
* Introduces a new test that creates a command-buffer with an
out-of-order queue, enqueued on an in-order queue.
It was noticed during another PR review
https://github.com/KhronosGroup/OpenCL-CTS/pull/2207/files#r1903921283
that there
was a case where the return value of a `Skip()` check was ignored, this
is fixed in this PR.
I've also tracking down occurrences of derived class overriding the
`Skip()` test fixture method, but not calling the parents class `Skip()`
check inside of the method. I believe omitting this parent skip check
wasn't intentional, it's clearer to explicitly respect the parent
classes skip conditions, even if we've got away with not needing too due
to the way the derived class skip conditions have been defined.
As described in Issue
https://github.com/KhronosGroup/OpenCL-CTS/issues/2152 we currently
check the provisional extension version supported by a vendor is the
same or older than a test specified version. However, it was discussed
in the WG that this should be a check for equality to avoid hitting
issues when a implementation tests against an older version of the CTS
using a lower extension version, with API breaking changes having
occurred since.
The tests for the command-buffer family of extensions are the only
provisional KHR tests using this versioning check, so this PR updates
all those cases to equality.
When creating a CL semaphore object from a Vulkan semaphore one, we
explicitly pass `-1` as the file descriptor value in the case of
`VULKAN_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD`. According to the CL
specification:
> The special value -1 for fd is treated like a valid sync file
> descriptor referring to an object that has already signaled. The
> import operation will succeed and the semaphore will have a
> temporarily imported payload as if a valid file descriptor had
> been provided.
The test currently checks that the semaphore payload is unsignalled,
unconditionally, which is incorrect.
Changed the test to check for the correct expected payload value.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Current class wrapper of the CTS test framework allows getting the
pointer of the private member object. This puts the object at risk of
losing its original value if the pointer gets reassigned, causing a
memory leak and potentially other problems.
This happens to the "clMemWrapper kernel" used by
mutable_command_work_groups tests, where the "clMemWrapper kernel" gets
initialised by the default basic setup function and then it gets
reassigned by the build_program_create_kernel_helper() helper function
through pointer.
This patch fixes this issue by updating mutable_command_work_groups
tests: instead of calling basic setup function and then initialise the
"clMemWrapper kernel" object again in the helper function, it now
overrides the basic setup function to make sure the "clMemWrapper
kernel" will be assigned only once.
Signed-off-by: Xin Jin <xin.jin@arm.com>
Currently Intel® C++ Compiler Classic (ICC) is supported to build
OpenCL-CTS on Windows. This compiler has been discontinued since the
second half of 2023. Instead, Intel recommends that users transition to
use the LLVM-based Intel® oneAPI DPC++/C++ Compiler (ICX).
This change is to enable users to build OpenCL-CTS with ICX on Windows.
Add a `format` parameter to the macro, to be able to specify how to
print the expected and actual parameter values.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
This test did not pass the `-cl-std=` flag when building the program. As
a result, for an OpenCL 3.0 device, the program will be "compiled using
the highest OpenCL C 1.x language version supported" by the device.
However this will force uniform work-group sizes which leads to a
`CL_INVALID_WORK_GROUP_SIZE` error.
To fix this, use the `create_single_kernel_helper()` helper function
which will automatically get the device version and pass that to
`-cl-std=` when building the program.
---------
Signed-off-by: Gorazd Sumkovski <gorazd.sumkovski@arm.com>
Following the re-enablement of narrowing warnings, this fixes a
compilation error when running the `ubuntu 22.04 arm` GitHub action.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
The extension tests in `test_conformance/extensions` have not matching
entries in the `opencl_conformance_tests_*.csv` files. This means that
they are missed from conformance runs by vendors who use these files.
I've included the new extensions in the full and quick CSV files as they
don't have vast combinations of tests to run like bruteforce or
conversions.
I've put `cl_khr_dx9_media_sharing` in the
`test_conformance/opencl_conformance_tests_d3d.csv` CSV as like the
other tests there the test binary is conditional built only on a Windows
platform.
I've created a new `opencl_conformance_tests_vulkan.csv ` file for
testing the `cl_khr_external_semaphore` extension, as creation of the
binary is conditional on the Vulkan SDK being enabled environment. Any
other tests that require the Vulkan SDK in future can also be added
there.
some fixes we've been carrying in our CTS fork:
* fix UB in `command_buffer_event_sync.cpp`: enqueue of two commands in
two separate queues, with both using the same buffer argument, and no
synchronization between the commands.
* fix UB in `command_buffer_test_barrier.cpp`: missing synchronization
between zeroing command and command-buffer using two separate queues
* make `test_thread_dimensions.cpp` thread-safe to avoid spurious
errors.
Fixes narrowing conversion build errors in test_common
Removing disable of narrowing errors in main CMakeLists.txt
and moving it down to specific test_conformance suite's
CMakeLists.txt where there are many more build errors revealed
from this fix.
Fixes a few simple issues under test_conformance in the process.
Contributes #787
Signed-off-by: Ellen Norris-Thompson <ellen.norris-thompson@arm.com>
---------
Signed-off-by: Ellen Norris-Thompson <ellen.norris-thompson@arm.com>
fixes several issues:
* `generic_address_space` test: add check for program scope variables.
The test uses both generic AS and program-scope variables, however it
only checked the generic-AS presence in `clGetDeviceInfo`.
* `compiler/test_compiler_defines_for_extensions.cpp`: add
`cl_khr_command_buffer_multi_device` to the list of recognized
extensions
* `command_buffer_event_sync.cpp`: add delays for testing
`clSetEventCallback` - according to specification, these can be executed
asynchronously (in a separate thread) by the OpenCL implementation,
hence the event callback is not quaranteed to be called before
`clFinish()` returns. Existing test `events/test_callbacks.cpp` also
waits for callback with loops of usleep.
* `images/kernel_image_methods/test_1D_buffer.cpp`: fix allocation size
being too small for the 1D buffer backing the image
---------
Co-authored-by: Ben Ashbaugh <ben.ashbaugh@intel.com>
fixes a few minor issues introduced by #1984.
edit: Tested with the updated command buffer emulation layer on a device
that supports out-of-order queues and SVM and all of the
`test_cl_khr_mutable_dispatch` tests pass.
An implementation may not support exportable semaphore, subtests
available in cl_khr_external_semaphore assumes support for exportable
semaphore, resulting in failure on such implementation. Allow
implementations to use importable semaphore in such cases.
1. Fix memory leak by making `context2` use the context wrapper.
2. Create two separate events to associate with the two calls to
`clEnqueueSignalSemaphoresKHR()`, as events cannot be reused.
Also delete the unused helper function
`semaphore_external_cross_queue_helper()` (which was a duplicate of
`external_semaphore_cross_queue_helper()` anyway).
The `vulkan-wrapper` helper library's purpose is to eliminate the need
to link targets directly to Vulkan, and load it dynamically instead at
runtime, using `dlopen` and `LoadLibrary`.
Remove the direct linking of the Vulkan library from targets that link
to `vulkan-wrapper`.
Fixes#1999
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
- when calling command buffer APIs, test with `command_queue != NULL`
should return `CL_INVALID_VALUE` only if the device doesn't support
`cl_khr_command_buffer_multi_device` (added `Skip`)
- some tests enqueued commands with multiple invalid arguments, e.g.
`clCommandCopyImageToBufferKHR` with two images and invalid sync points.
AFAIK the order of argument checking is not defined, so implementation
can return any valid error value for such API calls, but the tests
assumed only one particular error would be returned. Fix the API calls
to be unambiguous.
According to work plan from
https://github.com/KhronosGroup/OpenCL-CTS/issues/1691
After consultations with @bashbaug I skipped this case:
`CL_INVALID_VALUE if any of the semaphore objects specified by
sema_objects requires a semaphore payload and sema_payload_list is NULL`
`create_single_kernel_helper` invokes `clBuildProgram` and sets
`-cl-std` to the latest version supported by the context.
The vast majority of tests are using `create_single_kernel_helper`
instead of the `..._create_program` variant, so use the former for the
sake of consistency.
---------
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
