Okay so I dismissed precision issues too quick. Digging deeper into float16 representation, it’s clearly the encoding itself which can’t handle increments < 1 for numbers >= 1024.0, as well as increments < 2 for numbers >= 2048.0 and so on.
In the end really this file is a perfect representation of floating point precision issues.
So this is only partially solved: For this specific test case I could go to float32 representation and wouldn’t hit any walls until much higher values alright. But what I’m really doing aside this minimal excerpt test-case would require larger render targets, a little more than two of these, and clearly going from 16 to 32bits is no small increase in memory footprint… For the sake of trying I did so though, but with the real-case values it appears I run into these precision issues as well even with full precision.
Now that I know where (at least part of) this is coming from, I need to test more things to see if I can come up with something. If I’m not mistaken, this issue arise from the matissa-exponent relationship, so even normalizing everything would not help, anyone can confirm ?