Add a wrapper around AHB for proper resource deallocation and refactor
existing tests to use the wrapper.
Add a negative test for AHB to test for error codes when calling
clCreateImageWithProperties and clCreateBufferWithProperties.
---------
Signed-off-by: Alex Davicenko <alex.davicenko@arm.com>
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Co-authored-by: Alex Davicenko <alex.davicenko@arm.com>
Use the explicit version of the atomic_load/store and atomic_fetch_add
with memory order relaxed and memory scope workgroup to allow devices
that only support the minimum CL_DEVICE_ATOMIC_MEMORY_CAPABILITIES which
are (CL_DEVICE_ATOMIC_ORDER_RELAXED | CL_DEVICE_ATOMIC_SCOPE_WORK_GROUP)
to run the tests.
The test should only require the relaxed ordering and memory scope
workgroup anyway.
From the specificiation:
"The non-explicit atomic_store function requires support for OpenCL C
2.0, or OpenCL C 3.0 or newer and both the
__opencl_c_atomic_order_seq_cst and __opencl_c_atomic_scope_device
features"
"The non-explicit atomic_load function requires support for OpenCL C 2.0
or OpenCL C 3.0 or newer and both the __opencl_c_atomic_order_seq_cst
and __opencl_c_atomic_scope_device features."
"The non-explicit atomic_fetch_key functions require support for OpenCL
C 2.0, or OpenCL C 3.0 or newer and both the
__opencl_c_atomic_order_seq_cst and __opencl_c_atomic_scope_device
features."
**For mutable_dispatch_image_1d_arguments &
mutable_dispatch_image_2d_arguments:**
As the images are created using CL_UNSIGNED_INT8, the kernel does not
use correct instructions, as they are designed for signed variable. This
fix consists of modifying the kernel code to use unsigned instructions
and auxiliary variables .
Related to https://github.com/KhronosGroup/OpenCL-CTS/issues/2142,
according to the work plan, extending CBasicTestFetchAdd with support
for atomic_half.
I wasn't able to test that PR completely due to missing
`CL_DEVICE_LOCAL_FP_ATOMIC_ADD_EXT`/`CL_DEVICE_GLOBAL_FP_ATOMIC_ADD_EXT`
capabilities for atomic_half. I appreciate reviewers' attention, thanks.
Ensure clEnqueueReleaseExternalMemObjectsKHR targets imported_image
instead of the non-external opencl_image, matching the prior acquire
call.
Signed-off-by: Xin Jin <xin.jin@arm.com>
The test was using vloada_half which does not exist for scalars.
Also removed the files test.vloada_half_*.* from half.zip.
For test.vloada_half3_global, changed the OpenCL kernel to use
vload_half instead of vloada_half.
Build failures will return a proper failure now, before, the test was
passing in this case.
More Info: https://github.com/KhronosGroup/OpenCL-Docs/issues/648
Actions test plan from
https://github.com/KhronosGroup/OpenCL-CTS/issues/2473 to update CTS
tests to reflect changes from cl_khr_command_buffer PR
https://github.com/KhronosGroup/OpenCL-Docs/pull/1411
* Adds new test in`command_buffer_pipelined_enqueue.cpp` for multiple
enqueues without blocking in-between, but serialized execution.
* Removed test for `CL_COMMAND_BUFFER_STATE_PENDING_KHR` state query.
* Remove negative test for `clEnqueueCommandBuffer` pending state error.
* Simplify `cl_khr_command_buffer` tests that stress simultaneous-use by
testing multiple serialized enqueues of the same command-buffer, which
doesn't now require the device imultaneous-use capability
* Remove simultaneous-use command-buffer creation in base class to off,
and require tests do it themselves if they require it.
* Rewrite mutable dispatch simultaneous test to test updating both
pipelined enqueues, and updating the new definition of simultaneous-use
---------
Co-authored-by: Ewan Crawford <ewan@codeplay.com>
Before this change, `max_error` was initialized to `0.0f`, which caused
issues
when the actual maximum `error` was also `0.0f`. In such cases,
`max_val` would
never be updated, leading to misleading test output showing `NaN`
values:
```
degrees: Max error 0.000000 ulps at 0: *nan vs 0x1.9802318e8abefp+21
```
This fix initializes `max_error` to `-INFINITY` to ensure `max_val` is
always
updated at least once. Additionally, the log output now includes the
input
value for better debugging:
```
degrees: Max error 0.000000 ulps at 0, input 0x1.c7bffcp+15: *0x1.9802318e8abefp+21 vs 0x1.9802318e8abefp+21
```
This makes the test output more informative and eliminates confusing
`NaN` values in the summary.
Although run_conformance.py runs from test_conformance, it will change
the current working directory before launching each individual test.
Adjust the path accordingly.
Co-authored-by: Ben Ashbaugh <ben.ashbaugh@intel.com>
In C++17 the return type of std::filesystem::path::u8string() is
std::string, but in C++20 the return type changed to std::u8string.
Add a helper to copy a std::u8string to a std::string, to be used when a
std::string is required. This fixes the build for C++20.
Add a command line argument to override the SPIR-V file paths if needed,
similar to `test_spirv_new`. Set the default path to the one required by
`run_conformance.py`, which assumes the current working directory to be
`<build_dir>/test_conformance`.
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
The test had critical buffer overflow issues:
1. Buffer size was calculated incorrectly: used update_elements (4)
instead
of total work items. For 3D kernels, this meant allocating 16 bytes
when 64*4=256 bytes were needed for the updated 4x4x4 grid.
2. Original 2x2x2 grid writes 8 elements (32 bytes) but buffer was only
16 bytes, causing overflow on first execution.
3. Updated 4x4x4 grid writes 64 elements (256 bytes) with massive
overflow into adjacent memory.
4. Verify function only checked one dimension instead of total elements
in the 3D grid.
Fixed by:
- Calculating total work items as product of all dimensions
- Using update_total_elements (64) for buffer allocation
- Updating Verify calls to check correct number of elements
- Adding constants for original_total_elements and update_total_elements
There are two changes in total. The first one to fix a small issue of
current working directory so that second change can be applied. And the
second one is for resolving #852 Removing hard-coded SPIR-V binaries in
clUnloadPlatformCompiler tests.
Fixes#852
---------
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
Signed-off-by: Xing Huang <xing.huang@arm.com>
Related to #2142, according to the work plan, extending
CBasicTestFetchSub with support for atomic_half.
I wasn't able to test that PR entirely due to missing
CL_DEVICE_LOCAL_FP_ATOMIC_ADD_EXT/CL_DEVICE_GLOBAL_FP_ATOMIC_ADD_EXT
capabilities for atomic_half. I appreciate reviewers' attention, thanks.
- Make it a common parameter in harness using either '-w', '--wimpy' or
'CL_WIMPY_MODE' environment variable.
- Remove all test specific wimpy variable.
---------
Co-authored-by: Kévin Petit <kpet@free.fr>
Adds tests to cover points 2 & 3 from the questions asked about
cl_khr_command_buffer_mutable_dispatch in
https://github.com/KhronosGroup/OpenCL-Docs/issues/1437
* New test for point 2 from issue, `mutable_dispatch_updates_persist`,
testing multiple enqueues of a command-buffer after update, and that the
updated argument persists for all of them.
* New test for point 3 pseudocode from issue in test
`mutable_dispatch_set_kernel_arg`
This is a very small subset of the changes in #2477 to get things
building again, since the command-buffer pending state is no longer in
the spec or headers.
Both these functions cause a conflict when using an old version of the
GNU C Library with the header file sys/sysmacros.h where major() and
minor() are defined as a macro
The check implementated by that Skip function is already implemented in
'InfoMutableCommandBufferTest::Skip()'.
Also this is trying to get the extension_version before checking whether
the extension is supported, leading to false negative for device not
supporting the extension.
Fixes the following VVL errors:
```
Validation Error: [ VUID-VkExternalSemaphoreProperties-sType-sType ] | MessageID = 0x160be1e8
vkGetPhysicalDeviceExternalSemaphorePropertiesKHR(): pExternalSemaphoreProperties->sType must be VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES.
The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_EXTERNAL_SEMAPHORE_PROPERTIES (https://docs.vulkan.org/spec/latest/chapters/capabilities.html#VUID-VkExternalSemaphoreProperties-sType-sType)
```
```
Validation Error: [ VUID-VkImportSemaphoreFdInfoKHR-handleType-07307 ] | MessageID = 0x1b609443
vkImportSemaphoreFdKHR(): pImportSemaphoreFdInfo->handleType is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT so VK_SEMAPHORE_IMPORT_TEMPORARY_BIT must be set, but flags is VkSemaphoreImportFlags(0).
The Vulkan spec states: If handleType refers to a handle type with copy payload transference semantics, flags must contain VK_SEMAPHORE_IMPORT_TEMPORARY_BIT (https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VUID-VkImportSemaphoreFdInfoKHR-handleType-07307)
```
```
Validation Error: [ VUID-VkPhysicalDeviceExternalBufferInfo-None-09500 ] | MessageID = 0x8434cf
vkGetPhysicalDeviceExternalBufferPropertiesKHR(): pExternalBufferInfo->usage is zero.
The Vulkan spec states: If the pNext chain does not include a VkBufferUsageFlags2CreateInfo structure, usage must not be 0 (https://docs.vulkan.org/spec/latest/chapters/capabilities.html#VUID-VkPhysicalDeviceExternalBufferInfo-None-09500)
```
I was considering reusing other code where NaN gets taken into account,
but all the other places are a mess. The kernel read write tests are
just doing it within loops. Other places only compare raw values as
outside of kernel functions it seems to be fine to expect NaN to not
mess up results.
However the vulkan interop testing does run kernels and does operate on
NaN float values, so we need to special case this there.
