Bazel requires that test outputs are put in a specific directory given
by $TEST_UNDECLARED_OUTPUTS_DIR when running a test through Bazel test
This patch checks for the environment variable $BAZEL_TEST, which Bazel
sets when running tests, and prepends the specified directory to the
user-provided path.
The behaviour when running outside of a bazel test environment is
unchanged
Unlike related PR #2344 that simply warns about unsupported FTZ, this PR
attempts to correctly handle FTZ on RISC-V.
RISC-V 'f' extension does not support any way to enable/disable flushing
subnormals to zero, implementations are required to always support
subnormals. Therefore this PR re-uses FTZ handling code from PPC, where
flushing also has to be explicitly performed.
This PR adds negative tests for the following API functions:
- clCreateContext
- clCreateContextFromType
- clRetainContext
- clReleaseContext
- clSetContextDestructorCallback
Also, define a new macro `test_object_failure_ret` to test for an
expected error code and the returned object is `NULL` as a result of a
failure.
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.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.
- 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>
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
'-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
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.
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>
This change mainly extends `clFillImage` and `clCopyImage` test function
to include memory flags to be used during creating the image instead of
hard-coding these values. The memory flags are also different parameters
for source and destination images in `clCopyImage` tests.
---------
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Both `REGISTER_TEST` and `REQUIRE_EXTENSION` expect cl_device_id
variable but the variable name is inconsistent which makes both macros
unusable together.
This change renames `deviceID` in `REQUIRE_EXTENSION` to `device` to be
consistent with `REGISTER_TEST`.
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Project fails to build on systems with a kernel version older than 5.6.0
because of `-Wunused-function` combined with `-Werror`.
Expand the conditional compilation guard to include the offending code.
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>
Print the build log when building the program in `get_program_with_il`
fails, to make it easier to investigate spirv_new test failures.
Factor out a global helper function `OutputBuildLog` for printing the
build log for a single device.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
This commit links to issue (#2234).
When cross-compiling for AArch64, using gcc 13.3, you encounter three
warnings types that turn into errors:
- maybe-uninitialized
- stringop-truncation
- strict-aliasing
This commit fixes all the warnings found, in regards to the first two
rules. To resolve the warnigns due to strict-aliasing, I am editing the
CMake build system.
Signed-off-by: Antonios Christidis <a-christidis@ti.com>
This fixes three problems in `test_vulkan`:
1. One negative test is violating the OpenCL specification. A call to
`clEnqueue{Wait,Signal}SemaphoresKHR` with an invalid semaphore should
return `CL_INVALID_SEMAPHORE_KHR` and not `CL_INVALID_VALUE`.
>
[CL_INVALID_SEMAPHORE_KHR](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_INVALID_SEMAPHORE_KHR)
if any of the semaphore objects specified by sema_objects is not valid.
2. When populating the list of supported external memory handle types
for Vulkan, the types are unconditionally added to the list, without
checking if the device supports it or not, this fix is namely for
`VULKAN_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD`.
3. If a device does not support an optional extension (that is required
for a test), the test should skip, not throw an exception and fail. A
test failure should be reserved for the cases where a device claims
support for an extension but then fails to execute the test correctly.
---------
Signed-off-by: Ahmed Hesham <ahmed.hesham@arm.com>
The code base uses a mix of 'device' and 'deviceID'. I suggest we
standardise on 'device' which is shorter and slightly more prevalent.
Contributes to #2181
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
When comparing scanlines for SNORM images, take into account that -1.0
can be exactly represented in two different ways.
---------
Co-authored-by: Ben Ashbaugh <ben.ashbaugh@intel.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.
Removes `using namespace std` and adds `std::` explicitly instead, which
is usually on calls to `min`.
This is generally best practice, and it also might be helpful when there
are the same function names in the std namespace and in the global
namespace (e.g. #1833).
All existing tests in `test_image_streams`, that are capable of testing
image formats using the `CL_UNORM_INT_2_101010_EXT` data type, do so.
Signed-off-by: Gorazd Sumkovski <gorazd.sumkovski@arm.com>
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:
1. Multi import diff ctx subtest which acquires/releases external memory
via queue not associated with the context in which memory was imported.
2. Platform/Device info subtests to handle different platforms and
availability of the query.
glutInit double called in CTS CLGL test case code, which will lead
to an error:
freeglut (./test_gl): illegal glutInit() reinitialization attempt
root cause is in: test_conformance/gl/main.cpp:343
if (glEnv->Init(&argc, (char **)argv, CL_TRUE))
the glEnv->Init has already called in same file line:260, the function
glutInit in glEnv->Init can not be called twice, then a error will occur
although all the gl / CLGL cases are passed. Then in the full quick CTS
running it will appear:
(12-Jul 03:54:01) BEGIN OpenCL-GL Sharing :
PASSED sub-test.
PASSED 23 of 23 tests.
(12-Jul 04:01:48) FAILED OpenCL-GL Sharing : (467s, test 34/53)
Although all the gl/CLGL cases are passed, but this group test is judged
to failed.
This issue already been found in
https://github.com/KhronosGroup/OpenCL-CTS/pull/1885
And fixed partly by:
02471c8f56
But I found in setup_osx.cpp, the glutInit still has double init issue,
I add the same fix like previous fix,
can you please help to review?
Signed-off-by: Honglei Huang <Honglei1.Huang@amd.com>
Co-authored-by: Honglei Huang <Honglei1.Huang@amd.com>
Include `cmath` instead of `math.h` in C++ mode under MSVC, to avoid
build errors inside the header. Ideally we would not condition this
on `_MSC_VER`, but issue 1833 currently prevents doing so.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
Basic explicit_s2v:
The verification step was always using round to even when converting a
float to half even for round to zero cores.
Commonfns degrees:
The verification step was only taking into account infinities and not
values that over/underflow. This resulted in an incorrect error
calculation. E.g:
double cpu_result = 175668.85998711039;
cl_half gpu_result = 31743; // this is 65504 when converting to float,
we overflowed.
float error = (cpu_result - gpu_result) * some_factor;
The fix adds the check if( (cl_half) reference == test ) before
calculating the error.
Some conformance tests use directly the size returned by the runtime
for max memory size to allocate buffers.
This doesn't leave enough memory for the system to run the tests.
