The extension tests in `test_conformance/extensions` have not matching
entries in the `opencl_conformance_tests_*.csv` files. This means that
they are missed from conformance runs by vendors who use these files.
I've included the new extensions in the full and quick CSV files as they
don't have vast combinations of tests to run like bruteforce or
conversions.
I've put `cl_khr_dx9_media_sharing` in the
`test_conformance/opencl_conformance_tests_d3d.csv` CSV as like the
other tests there the test binary is conditional built only on a Windows
platform.
I've created a new `opencl_conformance_tests_vulkan.csv ` file for
testing the `cl_khr_external_semaphore` extension, as creation of the
binary is conditional on the Vulkan SDK being enabled environment. Any
other tests that require the Vulkan SDK in future can also be added
there.
some fixes we've been carrying in our CTS fork:
* fix UB in `command_buffer_event_sync.cpp`: enqueue of two commands in
two separate queues, with both using the same buffer argument, and no
synchronization between the commands.
* fix UB in `command_buffer_test_barrier.cpp`: missing synchronization
between zeroing command and command-buffer using two separate queues
* make `test_thread_dimensions.cpp` thread-safe to avoid spurious
errors.
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>
Replace the occurrences of 0.0f == test' with 0.0f == HTF(test)'. The
types of 0.0f and test are not the same, so the equality comparison will
get undesired result when the test represents a -0.0h (i.e., test is
32768=0x8000). In this situation, 0.0f == test will be false, but 0.0f
== HTF(test) will be true.
Revise each if-statement to match the OpenCL s7.5.3 Item 4, specifically
modify to check that the result is subnormal instead of checking that it
is zero. "If the result of 3. is a sub-normal before rounding, the
result may be flushed to zero"
Co-authored-by: tnimburk <tnimburk@qti.qualcomm.com>
Comparing test (of type cl_half) with 0.0f is incorrect because cl_half
is a typedef of uint16_t (or unsigned short in c)
Co-authored-by: Tejswini Nimburkar <tnimburk@qti.qualcomm.com>
fixes several issues:
* `generic_address_space` test: add check for program scope variables.
The test uses both generic AS and program-scope variables, however it
only checked the generic-AS presence in `clGetDeviceInfo`.
* `compiler/test_compiler_defines_for_extensions.cpp`: add
`cl_khr_command_buffer_multi_device` to the list of recognized
extensions
* `command_buffer_event_sync.cpp`: add delays for testing
`clSetEventCallback` - according to specification, these can be executed
asynchronously (in a separate thread) by the OpenCL implementation,
hence the event callback is not quaranteed to be called before
`clFinish()` returns. Existing test `events/test_callbacks.cpp` also
waits for callback with loops of usleep.
* `images/kernel_image_methods/test_1D_buffer.cpp`: fix allocation size
being too small for the 1D buffer backing the image
---------
Co-authored-by: Ben Ashbaugh <ben.ashbaugh@intel.com>
It was disabled because lack of reference implementation. However the
reference implementation exists. Then no reason to start testing these
functions.
Adds test to confirm that the timestamp returned from
clGetEventProfilingInfo for an event on a device and a device
timestamp queried from the same device are in the same timebase.
Fixes#753
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>
All of these are already set in the top-level `CMakeLists.txt` nowadays,
so no need to repeat them in the test's own `CMakeLists.txt`.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
This will ensure consistent output on any conforming implementation.
Note that the specification does not define the output style when
precision is missing.
---------
Signed-off-by: Cui, Dele <dele.cui@intel.com>
fixes a few minor issues introduced by #1984.
edit: Tested with the updated command buffer emulation layer on a device
that supports out-of-order queues and SVM and all of the
`test_cl_khr_mutable_dispatch` tests pass.
fixes#2040
* Compiles the Vulkan SPIR-V files in a directory based off of
CMAKE_CURRENT_BINARY_DIR.
* Changes the search path for the Vulkan SPIR-V files to this directory
rather than a semi-arbitrary set of directories.
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>
The various forms of `TestInfoBase` have many members in common, so
avoid duplicating the struct definition and move it to `common.h`.
Provide a description and initializer for every struct member, and drop
initializations done with `memset`.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
An implementation may not support exportable semaphore, subtests
available in cl_khr_external_semaphore assumes support for exportable
semaphore, resulting in failure on such implementation. Allow
implementations to use importable semaphore in such cases.
The main sources of warnings were:
* Printing of a `size_t` which requires the `%zu` specifier.
* Printing of `cl_long`/`cl_ulong` which is now done using the `PRI*64`
macros to ensure portability across 32 and 64-bit builds.
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.
This makes it literally impossible for drivers to constant fold the
IsTininessDetectedBeforeRounding kernel. Sure, drivers might have should
respect volatile here, but I'm not convinced this is actually required
by the spec in a very strict sense, because here there are no
side-effects possible in the first place.
And as far as I know, constant folding is allowed to give different
results than an actual GPU calculation would.
In any case, passing the constants via kernel arguments makes this
detection more reliable and one doesn't have to wonder why the fma test
is failing.
Side note: this was the last bug (known as of today) I had to fix in
order being able to make a CL CTS submission for Apple Silicon devices.
1. Fix memory leak by making `context2` use the context wrapper.
2. Create two separate events to associate with the two calls to
`clEnqueueSignalSemaphoresKHR()`, as events cannot be reused.
Also delete the unused helper function
`semaphore_external_cross_queue_helper()` (which was a duplicate of
`external_semaphore_cross_queue_helper()` anyway).
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.
