Update the test to use
`CL_EXTERNAL_MEMORY_HANDLE_ANDROID_HARDWARE_BUFFER_KHR` instead of
`CL_EXTERNAL_MEMORY_HANDLE_AHB_KHR` to match the headers.
Handle missing format in switch statement.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Use the latest stable LTS version of the NDK (r28c) and add
`ANDROID_PLATFORM` to the CMake configuration options, set to 29, so
that Android Hardware Buffer tests can be compiled.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Use the correct print format specifiers for `uint64_t` and fix loop
index type to address sign warning.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Drivers _may_ choose to advertise values for
`CL_DEVICE_MAX_WORK_GROUP_SIZE` or `CL_DEVICE_MAX_WORK_ITEM_SIZES` that
kernels without a `reqd_work_group_size` are not able to be launched
with.
The CTS should therefore make sure that the local_size passed to
`clEnqueueNDRangeKernel` does not exceed `CL_KERNEL_WORK_GROUP_SIZE`
This fixes it up in two places I've noticed this not happening.
New test following on from OpenCL-Docs Issues discussion
https://github.com/KhronosGroup/OpenCL-Docs/issues/1390#issuecomment-3023818903
Noting that we have no test coverage for using the original value of
`work_dim` during command-buffer update. All of our current CTS testing
uses `0` for the `work_dim` to signify no update from the original
value, however this test explicitly uses the original value.
Prior to this change, both `clEnqueueReadBuffer` calls before and after
updating the command buffer were writing to the same `output_buffer`,
causing a data race condition and the first call's result to be
overwritten. This commit introduces separate destination vectors
(`output_buffer` and `updated_output_buffer`) for these operations and
verifies both results independently to ensure test integrity.
Memory objects created in `EnqueueSimultaneousPass()` are used by
kernels
that don't execute until the user event is signaled. Without retaining
these objects, they would be destroyed before the deferred kernel
execution occurs.
While the cl_khr_semaphore extension spec does state that are no
implicit dependencies between already enqueued commands and the
clEnqueueSignalSemaphoresKHR, it's nothing special as this is already
true for any other event that's not a barrier or marker.
Also, the CTS can't reliably assume implementations to reorder events
even in an out of order queue as this is highly implementation defined
behavior and implementations may or may not choose to reorder events in
a specific order.
I don't see a reason why this should be tested for semaphores, but not
for any other commands, especially as it imposes a restriction on how to
implement out of order queues that wasn't enforced before.
Closes: https://github.com/KhronosGroup/OpenCL-CTS/issues/2439
While #2409 is under review, could we please add "cl_khr_spirv_queries"
to the list of known extensions? This will prevent test "failures" for
implementations that support the extension.
Modify the prime numbers generator function to return `size_t` instead
of `int` and use `0` as a sentinal value instead of hardcoded negative
ones. `0` is not a prime number, so it is suitable to use to indicate an
error.
Fixes#1159
---------
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
`clGetDeviceInfo` should fail with `CL_INVALID_VALUE` when queried for
`CL_DEVICE_SPIR_VERSIONS` on devices that do not claim to support the
extension that provides it, `cl_khr_spir`.
Following this change, the test is skipped instead of failing on devices
that do not support `cl_khr_spir`.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
- Do not override parent-provided value for CMAKE_CXX_FLAGS
- Stop building with -fpermissive (not required/bad practice)
- Delete unused variables
- Remove unnecessary casts
Signed-off-by: Kévin Petit <kpet@free.fr>
fixes#2387
Corrects the "correctly rounded" behavior for the math bruteforce tests.
Specifically:
* Only applies the `-cl-fp32-correctly-rounded-divide-sqrt` build option
for the `divide_cr` and `sqrt_cr` tests. The other tests do not receive
this build option. This means that there is a difference in the behavior
of the `divide` and `divide_cr` tests and the `sqrt` and `sqrt_cr`
tests, and the "correctly rounded" build option is not applied to the
fp16 or fp64 tests.
* Removes the build option to toggle testing the correctly rounded
divide and square root tests since it no longer needed. Instead, the
test names can be used to choose whether to test the correctly rounded
functions or the non-correctly rounded functions.
Additionally:
* Relaxes the fp16 sqrt accuracy requirements to 1 ULP. This is needed
to pass this test on some of our devices. This part is still under
discussion, so I will keep this PR as a draft until it is settled.
Currently, selecting a different device in a platform to test is rather
cumbersome, for two reasons:
1. The default device type tested is the "default" device and there is
at most one default device in a platform. This means that, by itself,
choosing any non-zero device index is by definition out-of-range:
```sh
$ CL_PLATFORM_INDEX=1 CL_DEVICE_INDEX=1 ./test_conformance/basic/test_basic
Initializing random seed to 0.
Requesting Default device based on command line for platform index 1 and device index 1
device index out of range -- choosen_device_index (1) >= num_devices (1)
```
2. To choose a non-default device type you therefore need to explicitly
specify another device type also, but "all" is not a valid device type
in the harness. This means that you need to know both the device type
and the index of the device within that device type to choose the device
to test.
```sh
$ CL_DEVICE_TYPE=all CL_PLATFORM_INDEX=1 CL_DEVICE_INDEX=1 ./test_conformance/basic/test_basic
Unknown CL_DEVICE_TYPE env variable setting: all.
Aborting...
Aborted (core dumped)
```
This PR aims to fix (2), by allowing "all" as a device type. In the
future, we could consider making the default device type "all" vs.
"default", which would fix (1) also, but that will likely need more
discussion and should be done in a separate PR.
* Ulp_Error*: ilogb(reference) - 1 may overflow if reference is zero.
* binary_i_double Test: DoubleFromUInt32's result is a cl_double and the
attempt is to store it as a cl_double, but p was defined as a pointer to
cl_ulong, resulting in an unintended implicit conversion that is not
valid for out-of-range doubles.
* exp2, tanpi: ensure early exit for NaN.
* shift_right_sticky_128: avoid out-of-range shift if shift value is
exactly 64.
* scalbn: e += n may overflow if n is large, move it after the check for
large n.
Add cl_khr_command_buffer test that is it valid to release a
command-buffer after it has been enqueued but before execution is
finished.
This stresses the semantics from
[clReleaseCommandBufferKHR](https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/clReleaseCommandBufferKHR.html#_description)
that: "After the command_buffer reference count becomes zero **and has
finished execution**, the command-buffer is deleted"
The `local_workgroup_size` is changed by
`get_max_common_work_group_size`. But the input data still use the
original `local_workgroup_size`, which will cause the check logic to
failed.
Refactor the following tests:
1. `test_imagecopy`
2. `test_imagecopy3d`
3. `test_imagereadwrite`
4. `test_imagereadwrite3d`
The change does the following:
1. Use RAII to manage allocated resources
2. For `imagecopy` and `imagecopy3d`, the change allows for a custom src
image memory flags and adjusts how the source image is created according
to the input flags.
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
In CMake 3.24+, there is built-in support for adding -Werror that does
not require adding -Werror explicitly, and allows it to be downgraded to
a warning if the user wants that. Use this, to account for warnings that
have false positives.
This change refactors the following tests to use RAII to clean-up
allocated resources on exit, and adds additional changes as mentioned
below:
- test_arrayreadwrite
- Allow different `cl_mem_flags` to be passed to the test.
- test_bufferreadwriterect:
- Allow different `cl_mem_flags` to be passed to the test.
- Customisable copy, read and write functions.
- test_buffer_copy
- Fill the destination buffer with `invalid_ptr` instead of `out_ptr` if
created with `CL_MEM_(USE/COPY)_HOST_PTR`.
- test_buffer_partial_copy
- Fill the destination buffer with `invalid_ptr` instead of `out_ptr` if
created with `CL_MEM_(USE/COPY)_HOST_PTR`.
---------
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
This commit fixes three tests that have memory leaks due to unreleased
CL objects.
- `kernel_local_memory_size`
- `multi_queue_flush_on_release`
- `queue_flush_on_release`
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Found while developing #2376.
Parts of "test_opencl_c_versions" were intending to build programs for
different OpenCL C versions, but unfortunately the helper function the
test was calling only created the program and did not build it. Switch
to a helper function that builds the program, instead.
This change provides partial test coverage for
KhronosGroup/OpenCL-Docs#1280
Adding CTS tests for:
1. clEnqueueMapBuffer, clEnqueueMapImage.
2. Command buffer negative tests.
3. clSetKernelArgs negative tests.
The bulk of the tests is to make sure that the CL driver does not allow
writing to a memory object that is created with `CL_MEM_IMMUTABLE_EXT`
flag when used with the above APIs.
---------
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Remove the test timing functionality from the conversions test, because
it
- is not advertised in the help,
- is not supported on all platforms, triggering warnings during the
build,
- goes beyond the core purpose of the conformance test suite.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
Fixes#2155 according to issue description
Additional remark: The image size was previously calculated based on the
memory size, which seems unusual. Due to Vulkan's configuration
capabilities, the size of memory allocated for a specific texture may
differ from what would be expected based on the texture dimensions.
Thus, calculating the image dimensions back from the memory size of a
Vulkan texture can be challenging.
This change add the following image formats to the supported image
formats:
1. CL_UNSIGNED_INT10X6_EXT
2. CL_UNSIGNED_INT12X4_EXT
3. CL_UNSIGNED_INT14X2_EXT
4. CL_UNORM_INT10X6_EXT
5. CL_UNORM_INT12X4_EXT
6. CL_UNORM_INT14X2_EXT
For reference, the specification for
`cl_ext_image_unsigned_10x6_12x4_14x2` can be found here:
https://github.com/KhronosGroup/OpenCL-Docs/pull/1352
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Co-authored-by: Michael Rizkalla <michael.rizkalla@arm.com>
