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>
sccache emits a warning message after every build that it has failed to
save a build cache. Additionally the stats are all zeroes, no cache hits
(or misses). The "Caches" tab under "Actions" does not have any cached
build artifacts which confirms that nothing is being saved.
Fix by passing the correct launcher options directly to CMake instead of
wrapping them in `CMAKE_CACHE_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 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>
