cl_khr_fp16 extension consistency issues with core C spec

[oddhack]

Some issues that have come up while integrating language from the extension to the core C spec for #950. These mostly arise from the situation that there is a considerable amount of cl_khr_fp16-related functionality in the C spec already, and many footnotes saying "only if cl_khr_fp16 is supported", but by no means all of the extension language. In particular, the functions operating on 'half' data types are not included, nor are compile-time constants. So it is unclear if the extension was already considered to be included in the C spec or not, but fully including it as I've been doing with the other C language extensions raises a bunch of questions:

• The extension spec says "The OpenCL compiler accepts an h and H suffix on floating-point literals, indicating the literal is typed as a half" while the C spec says "The half data type can only be used to declare a pointer to a buffer that contains half values", which seems like a major functionality difference.

• The "Explicit Conversions" section excludes the 'half' data type while the extension says the conversion functions are extended to take 'half' and 'halfn'. Note this is unlike the implicit conversions / explicit casts sections, which exclude 'half' unless cl_khr_fp16 is supported, and I assume should be treated similarly.

• The Math Functions table for fract() refers to fmin(x - floor(x), 0x1.fffffep-1f), while the table in the extension refers to fmin(x - floor(x), 0x1.ffcp-1f). Why are the constants different? If the extension constant is intended to be a half-precision version of the fract() in the C spec, (a) shouldn't it have a 'h' suffix and (b) why isn't there also a double-precision constant version for the versions of fract() taking doubles?

• The nextafter() function in the C spec is defined to "Compute the next representable floating-point value following x in the direction of y" but accepts gentype arguments - should it not be "next representable FP value of the precision of its arguments" or similar?

[RemiArnaud]

Thanks for this report. Any chance you could create a PR ?

[ivalylo]

I work with forked version of OpenCOLLADA and can't contribute a patch since I can't test it with the official version. I can upload the fork itself on github if it will be of any interest when I've tested it. Here is what I'm changing from the official version:

• new hybrid parsing - IWriter methods should be able to return new code that means - don't delete the item, add it to the loader (similar to the items added for the post-processor). Then the loader itself provides a DOM fashion interface with the requested items. The idea is to simplify the loading and SAX parse just the meshes or any other items you can process out of order and it's worth the trouble.
• consistent use of FW_NEW/FW_DELETE. Or even converting them to more flexible custom allocator functions (like in the FBX SDK)
  • custom file IO interface.
• fix the Texture and Light object report in the IExtraDataCallbackHandler::parseElement. The getObject() methods didn't implement this
• the color/uv sets have some weird initial index which offsets the indices reported for additional sets. There is also a comment in the COLLADA to glTF converter about this weirdness. I removed it,
  • I would want to fix the index data duplication in the mesh loader, so it can be reused, but I don't know if I will have time since it's more involved. For example normals/tangents/binormals would likely use the same indices, but currently (if I understand the code properly), the same indices will be loaded 3 times.

[RemiArnaud]

if you forked from this repo, you should be able to create a branch matching the common ancestry and do the patch. you can merge the updated openCOLLADA changes too.