You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've got a few CTS tests that only pass on one or two adapters. The behaviour these tests are enforcing isn't being missed upstream in the backends that are failing, which I think is a sign that either: these tests should have some skipping mechanism, we need a spec adjustment, or in the cases where only one adapter passes we could consider making them adapter specific tests.
These are the ones I noticed while working on the device parameterization PR:
urProgramSetSpecializationConstants InvalidValueSize, InvalidValueId and InvalidValuePtr have match entries for all adapters apart form CL - likely there's a missing skip for these one because cuda and hip don't support the entry point at all (Added DEVICE_INFO_PROGRAM_SET_SPECIALIZATION_CONSTANTS #2539 )
urUSM*Alloc InvalidUSMSize tests all fail for cuda, hip and native cpu - might simply not be possible to check this on these backends
urEnqueueKernelLaunchKernelSubGroupTest fails on every adapter but CL
urEnqueueKernelLaunchTest.InvalidKernelArgs fails on every adapter but CL
urMemBufferCreateWithNativeHandleTest has a lot of match entries, all native handle entry points should be optional so almost certainly just missing a skip
The text was updated successfully, but these errors were encountered:
add to the list urKernelGetSubGroupInfoFixedSubGroupSizeTest.CompileNumSubGroups which seems to fail on every adapter (maybe this is something that only works with a specific platform? some of the other tests like this one only work on opencl igpu + fpga emulator)
We've got a few CTS tests that only pass on one or two adapters. The behaviour these tests are enforcing isn't being missed upstream in the backends that are failing, which I think is a sign that either: these tests should have some skipping mechanism, we need a spec adjustment, or in the cases where only one adapter passes we could consider making them adapter specific tests.
These are the ones I noticed while working on the device parameterization PR:
DEVICE_INFO_PROGRAM_SET_SPECIALIZATION_CONSTANTS
#2539 )The text was updated successfully, but these errors were encountered: