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
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.
This commit fixes three tests that have memory leaks due to unreleased
CL objects.
- `kernel_local_memory_size`
- `multi_queue_flush_on_release`
- `queue_flush_on_release`
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
This change provides partial test coverage for
KhronosGroup/OpenCL-Docs#1280
Adding CTS tests for:
1. clEnqueueMapBuffer, clEnqueueMapImage.
2. Command buffer negative tests.
3. clSetKernelArgs negative tests.
The bulk of the tests is to make sure that the CL driver does not allow
writing to a memory object that is created with `CL_MEM_IMMUTABLE_EXT`
flag when used with the above APIs.
---------
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
- Cases with a NULL global_work_size were not tested
- The specification states that zero-sized enqueues behave similarly to
marker commands. Test that events for NDRange kernel commands have the
correct CL_COMMAND_NDRANGE_KERNEL command type to guard against
implementations naively using a marker command.
- Tidy up the code a bit and add missing error checking.
Signed-off-by: Kévin Petit <kpet@free.fr>
The test is using CL_DEVICE_MAX_WORK_GROUP_SIZE as first dimension of
local work size. But it can be bigger than the first dimension of
CL_DEVICE_MAX_WORK_ITEM_SIZEs which results in failure.
This patch corrects it to query and use the first dimension of
CL_DEVICE_MAX_WORK_ITEM_SIZES instead.
Signed-off-by: Xing Huang <xing.huang@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>
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).
When cl_khr_fp16 is not supported, this property is not available.
Note that the spec is different for
CL_DEVICE_{PREFERRED,NATIVE}_VECTOR_WIDTH_HALF: those properties are
always available and return 0 if cl_khr_fp16 is not supported, so those
checks are left as is.
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>
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>
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.
The removed macros were never used.
Use the more common `ARRAY_SIZE` macro instead of defining an identical
`NELEMS` macro.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
Test that verifies `CL_INVALID_QUEUE_PROPERTIES` is returned from
`clCreateCommandQueue`, `clCreateCommandQueueWithProperties`, and
`clCreateCommandQueueWithPropertiesKHR` to match spec wording
> CL_INVALID_QUEUE_PROPERTIES if values specified in properties are
valid but are not supported by the device.
* Add NULL CL_MEM_HOST_PTR check for clGetMemObjectInfo
The spec requires implementations return NULL for CL_MEM_HOST_PTR
when the flags passed at memory object creation time do not contain
CL_MEM_USE_HOST_PTR
CTS was not checking this. Add the same check.
Fixes#1752
* Add NULL CL_MEM_HOST_PTR check for all flag combinations
As part of suggestions to #1801, add NULL CL_MEM_HOST_PTR
check for all flag combinations.
Fixes#1752
* Fix formatting issues
It seemed to be a typo; the comment says that it
tries to fetch local size for a subgroup count with
above max WG size, but it just used the previous
subgroup count.
The test on purpose sets a SG count to be a larger
number than the max work-items in the work group.
Given the minimum SG size is 1 WI, it means that there
can be a maximum of maximum work-group size of SGs (of
1 WI of size). Thus, if we request a number of SGs that
exceeds the local size, the query should fail as expected.
The spec requires implementations return NULL for CL_MEM_HOST_PTR
when the flags passed at memory object creation time do not contain
CL_MEM_USE_HOST_PTR
CTS was not checking this. Add the same check.
Fixes#1752
OpenCL FULL profile requires that online compiler be available.
OpenCL-CTS currently queries profile as well as online compiler
availability via device queries, but doesn't check for the consistency.
Check for consistency that if CL_DEVICE_PROFILE is "FULL_PROFILE"
(or technically is not "EMBEDDED_PROFILE") then CL_DEVICE_COMPILER_AVAILABLE
is CL_TRUE for that device.
Fixes#1763
test_conformance/api/test_queue_properties.cpp uses a cl_queue_properties_khr value
to query CL_DEVICE_QUEUE_PROPERTIES, however this should be a cl_command_queue_properties
typed variable.
Fixes issue #1640
All of these if-else chains compare against enums, which is better
done using switch statements. This helps avoid some
`-Wsometimes-uninitialized` warnings of variables that are assigned
inside the switch.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>