Hacker News Reader

Comment by AnotherGoodName | Hacker News Reader

I haven't seen it in years but the cause is actually the limitations of float precision and/or the way the developer has setup the world/view matrices.

eg. Your shaders operate on float16 precision (common in the D3D9 days) on a screen with high enough resolution. The boundary pixels at the diagonal now can't fit into the precision of a float16 cleanly.

View on HN

Mmmh there is rather an easy way to get that bug due to float precision is when the vertice positions are the result of some maths. Then two vertices which should be mathematically at the same position will end up not being exactly at the same position in practice due to float precision. Only ways to have two vertices at the exact same position is either hardcoding it, assigning the position of one to the other or using index buffers. An easy thing to miss.

That wouldn't be a problem in this case though? The vertices of 2 fullscreen triangles can be passed to the GPU using hardcoded values without any precision error (integers below a certain value can be represented precisely using floats).

That wouldn't be a problem as long as the vertex positions go through exactly the same transformations, as that ends with them accumulating the same rounding errors. Assuming that nobody was messing with floating point rounding behavior at runtime or flat out decided to enable fast-math and live with the resulting mess.

It doesn't make sense to use floating point for coordinates because it makes points near the origin have more precision than other points.

Nearly everything done with floating point would be better done another way...

But the reality is that floating point numbers 'just work' for a huge number of things, and the space and compute inefficiency is small enough to not worry about.

Yeah, but we're talking about GPUs here, which are still evolving.

Reply on news.ycombinator.com