Elaborate conversions #983
Conversation
dneto0
force-pushed
the
vector-conversions
branch
from
ccc3b22
to
a810efa
Compare
|
I left TODOs for conversion from floating point to integral, where there is rounding required or the result would be out of bounds. |
| * Otherwise, the original value is not exactly representable. | ||
| * If the original value is different from but lies between two adjact values representable in the destination type, | ||
| then the result is one of those two values. | ||
| [SHORTNAME] does not specify whether the larger or smaller representable |
There was a problem hiding this comment.
Can we choose which one it is and have it specified?
There was a problem hiding this comment.
That would be specifying the rounding mode.
Vulkan leaves that as an implementation detail.
https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#fundamentals-fp-conversion
When a value is converted to a defined floating-point representation, finite values falling between two representable finite values are rounded to one or the other. The rounding mode is not defined.
Note that OpenCL C has explicit conversion functions where the programmer can choose the rounding mode: rtz, rte, rtn, rtp
See https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html#explicit-conversions (subsection "Rounding modes")
It would be extra cost to enforce a rounding mode.
Note: OpenCL C has a 'nextafter' builtin function that returns the next-larger representable floating point value, and I think you can exploit that.
(If memory serves correctly, nextafter is almost the same as as<f32>(1+as<u32>(x)) )
There was a problem hiding this comment.
I added an issue for this discussion.
dneto0
force-pushed
the
vector-conversions
branch
from
a810efa
to
c5e05af
Compare
|
Rebased. Please take another look: @dj2 |
- Add a table for vector-value conversions - Define signed/unsigned reinterpration as equality modulo 2**32 - Write a "floating point conversion" section, with TODOs for uncertain parts - Add an issue for whether default rounding mode should be implementation-dependent
dneto0
force-pushed
the
vector-conversions
branch
from
c5e05af
to
ccaabbe
Compare
|
I posted a gist of the result: https://gistpreview.github.io/?496822ce8507504fa349aad6c9826473#conversion-expr (Go to the "Conversion expressions" section) |
|
Discussed at 2020-09-01 meeting. |
…puweb#983) * Implement validation,createRenderPipeline,pipeline_output_targets,blend_min_max * Address reviewer's comments
parts