api consistency requirements for fp64 and fp16

[bashbaug]

We don't currently have any API consistency tests for fp64 (and fp16) but there are enough moving parts here so we probably should... assuming it's clear what the API consistency requirements are (more on this in a bit).

Specifically, it seems that the following queries should be consistent:

If fp64 is supported...

• cl_khr_fp64 must be in the extension string.
• CL_DEVICE_DOUBLE_FP_CONFIG must return a nonzero value.
• CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE must return a nonzero value.
• (not 100% sure about this one) CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE must return a nonzero value? What about "soft float" implementations? Can they return zero because they have no "native" double support?

Otherwise, when fp64 is NOT supported...

• cl_khr_fp64 must not be in the extension string.
• CL_DEVICE_DOUBLE_FP_CONFIG must return zero.
• CL_DEVICE_PREFERRED_VECTOR_WIDTH_DOUBLE must return zero.
• CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE must return zero.

I think the same logic should also hold for fp16, the cl_khr_fp16 extension, and the analogous HALF queries.

This seemed fairly straightforward to me, though I did find this comment in one of the CTS tests:

https://github.com/KhronosGroup/OpenCL-CTS/blob/9137cb66ed01f23d1eec84846635ff61491361cd/test_conformance/api/test_queries.cpp#L575

    // Note that even if cl_khr_fp64, the preferred width for double can be non-zero.  For example, vendors
    // extensions can support double but may not support cl_khr_fp64, which implies math library support.

Does this make sense, or is this a stale comment that can be removed?

[kamil-goras-mobica]

@bashbaug added PR: https://github.com/KhronosGroup/OpenCL-CTS/pull/2058