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
`semaphores_ooo_ops_cross_queue` uses two OOO command queues to run the
test. In one queue, a semaphore is signalled and the semahpore is waited
on in the other queue.
The CL specification requires the application to synchronize the queues
if objects are shared.
Signed-off-by: Michael Rizkalla <michael.rizkalla@arm.com>
Add a `format` parameter to the macro, to be able to specify how to
print the expected and actual parameter values.
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
Following the re-enablement of narrowing warnings, this fixes a
compilation error when running the `ubuntu 22.04 arm` GitHub action.
Signed-off-by: Ahmed Hesham <ahmed.hesham@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>
According to work plan from
https://github.com/KhronosGroup/OpenCL-CTS/issues/1691
After consultations with @bashbaug I skipped this case:
`CL_INVALID_VALUE if any of the semaphore objects specified by
sema_objects requires a semaphore payload and sema_payload_list is NULL`
Semaphore spec has been updated to reflect the fact that semaphores
will be in the appropriate - pending signal or pending wait - state
when returning from clEnqueueSignalSemaphore or
clEnqueueWaitSemaphore commands: KhronosGroup/OpenCL-Docs#882
Deleted the following tests to match the updated spec:
semaphores_order_1 - Test calls EnqueueWaitSemaphore before calling
EnqueueSignalSemaphore and expects this wait to succeed.
This behavior is not compatible with the recent
spec updates to semaphores.
semaphores_order_2 & semaphores_order_3 - Calling
clEnqueueSignalSemaphoresKHR with a dependency on a user event may
cause the implementation to block until the user event is complete.
This is unsafe usage of clEnqueueSignalSemaphoresKHR and may
lead to deadlock.
semaphores_invalid_command - This test checks for specific behavior
when waiting on a semaphore in an invalid state.
According to the spec, this is undefined behavior,
and therefore cannot be tested directly.
Co-authored-by: Joshua Kelly <joshkell@qti.qualcomm.com>