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.
'-list' option is used to print all sub-tests. But some test do not
support it at all. And all test do not display it the same way, making
it quite complicated for external tools to extract them.
That CL clean the usage so that tests:
- Print the sub-tests list with either '-list' (to prevent breaking
legacy usage) or '--list' (to match other options)
- Do not print anything else when the option is used
Both tests depend on a very old DirectX SDK (August 2009) and expect it
to be extracted to an {NV_TOOLS} environment variable. They additionally
require definining {ARCH} as a CMake configuration option, which is not
needed.
Update both projects to use DirectX libraries provided by the Windows
SDK and drop the unneeded configuration options.
---------
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
print a `log_info` and use the minimum value (`1`) for `pixelBytes`
instead of printing an error and returning with an error value.
It allows device exposing a big CL_DEVICE_IMAGE_MAX_BUFFER_SIZE (more
than CL_DEVICE_MAX_MEM_ALLOC_SIZE/2) to pass test_api
min_max_image_buffer_size
Fix#2245
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 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.
