added cl_half support for test_geometric

[shajder]

According to issue description (geometrics section):

https://github.com/KhronosGroup/OpenCL-CTS/issues/142

Couple of additional remarks for reviewers:

• Source files test_geometrics.cpp and test_geometrics_double.cpp were unified in the process of adding cl_khr_fp16 support. I've tried to make as little corrections to original code as possible. As result we get quite a large source file which could be easily divided into 3-4 logic parts - I left it as is ATM for the sake of comparison purposes.

• Please take a closer look at GeometricsFPTest::FillWithTrickyNums, former FillWithTrickyNumbers/FillWithTrickyNumbers_double since the logic behind wasn't entirely clear for me. Moreover it crashed after decreasing TEST_SIZE macro. I would gladly refactor this method to make it a bit more readable.

• BTW. I've decreased TEST_SIZE from 1<<20 to 1<<10, please let me know if you think it's not enough. trickyNumbers were copied into max 320 elements, rest of it equals 0 or random value which seems like sufficient number of tests.

• Please take a closer look at dot verification code for halfs - it was source of pain (TwoArgsFPTest::TwoArgsKernel). I had to apply additional condition to test expected/reference values against overflow/underflow.

• Please take a look at verification of ULP limits - previous calculations seemed not entirely related to spec so I've applied my corrections (still it makes me think I may be mistaken here).

[bcalidas]

We need more time to review this PR.

[lakshmih]

We would like to double check results at our end, can we get some more time.

[lakshmih]

We are opposed to this change merging in present form. The precision should be calculated in the same type as being used by the builtin (half for half, and float for float)

[shajder]

We are opposed to this change merging in present form. The precision should be calculated in the same type as being used by the builtin (half for half, and float for float)

@lakshmih could you please point out specific fragment of code you are referring to ?

[EwanC]

We are opposed to this change merging in present form. The precision should be calculated in the same type as being used by the builtin (half for half, and float for float)

@lakshmih could you please point out specific fragment of code you are referring to ?

Qualcomm commented on the OpenCL-Docs issue I linked on my discussion above: https://github.com/KhronosGroup/OpenCL-CTS/pull/1633#discussion_r1155571948 So i'd assume the dot/cross verification code

[bashbaug]

See comments on the related issue:

• https://github.com/KhronosGroup/OpenCL-Docs/issues/900#issuecomment-1588601203
• https://github.com/KhronosGroup/OpenCL-Docs/issues/900#issuecomment-1602054509

In short, even our pure fp16 dot implementation isn't failing the new test, but a pure fp16 cross implementation is. It would be great to get this clarified in the spec and to update the tests, also.

[lakshmih]

Could we remove focused review from this change since it is pending resolution of the spec discussion? We can add it back once we get there.

[bashbaug]

Removing "focused review" - we can revisit when the spec issues are resolved.