missing testing for cl_ext_float_atomics

[bashbaug]

This issue is to track missing tests for the cl_ext_float_atomics extension.

There is some testing for these extensions in the Vulkan CTS.

There are also some tests in the Intel Cassian test framework, see: intel/cassian@239de5d

A good first step would be to evaluate what is tested by the other frameworks, see what may be useful for the OpenCL CTS, and write up a brief test plan.

[shajder]

Below is the proposition for a work plan on cl_ext_float_atomics and a few questions, I will appreciate discussions and your answers, thanks!

1. Adaptation of c11_atomics test suite in order to add support for cl_ext_float_atomics by including new generic cases for data types fp16/fp32/fp64 in classes:

• CBasicTestStore with atomic_half
• CBasicTestLoad with atomic_half
• CBasicTestExchange with atomic_half
• CBasicTestFetchAdd with atomic_float
• CBasicTestFetchAdd with atomic_double
• CBasicTestFetchAdd with atomic_half
• CBasicTestFetchSub with atomic_float
• CBasicTestFetchSub with atomic_double
• CBasicTestFetchSub with atomic_half
• CBasicTestFetchMin with atomic_float
• CBasicTestFetchMin with atomic_double
• CBasicTestFetchMin with atomic_half
• CBasicTestFetchMax with atomic_float
• CBasicTestFetchMax with atomic_double
• CBasicTestFetchMax with atomic_half

2. Extending c11_atomics with special values tests for:

• CBasicTestFetchAdd with atomic_float
• CBasicTestFetchAdd with atomic_double
• CBasicTestFetchAdd with atomic_half
• CBasicTestFetchSub with atomic_float
• CBasicTestFetchSub with atomic_double
• CBasicTestFetchSub with atomic_half
• CBasicTestFetchMin with atomic_float
• CBasicTestFetchMin with atomic_double
• CBasicTestFetchMin with atomic_half
• CBasicTestFetchMax with atomic_float
• CBasicTestFetchMax with atomic_double
• CBasicTestFetchMax with atomic_half

3. Implementation of new tests for spirv_new test suite including both CrossWorkGroup and Workgroup storage classes, supporting fp16/fp32/fp64 is not necessary. It is a matter of --compilation-mode spir-v run options and the specific cl_offline_compiler to test SPIRV + cl_ext_float_atomics extension along with c11_atomics test.

[bashbaug]

IMHO, one of the trickiest parts of testing float atomics will be numerical stability because floating-point addition is not associative. Have you given any thought how to handle this issue? Have you evaluated how other testing frameworks solve this problem?

Are we able to test any NaN (and infinity?) behavior, or are we expecting our inputs and results to be non-NaN (and non-infinity)?

[b-sumner]

I agree with @bashbaug. Unless the order of the atomic operations is explicitly controlled, the test will have to assume they can happen in any possible order and account for that.

An option for one test is to use only the values where the order doesn't matter and each operation is guaranteed to be exact, e.g. small integers while avoiding overflow.

[shajder]

Have you given any thought how to handle this issue? Have you evaluated how other testing frameworks solve this problem?

Thanks, I went through vk-gl-cts modifications related to VK_EXT_shader_atomic_float extension, issue 2371. I may be wrong but it seems like related changes were applied to general atomic test (vktAtomicOperationTests.cpp), it looks pretty generic and hard to read but it looks like comparing of float results narrow down to this function:

template <typename T>
bool sloppyFPCompare(T x, T y)
{
    return fabs(deToDouble(x) - deToDouble(y)) < 0.00001;
}

Does hardcoded epsilon be an acceptable solution for OpenCL-CTS atomic floats tests?

Edit: I just created PR for atomic_fetch_add case. The idea is to estimate largest possible summation error based on worse/best case scenarios. If that's not acceptable approach I will appreciate your tips and hints. Thanks