Hacker News Reader

Comment by seanalltogether | Hacker News Reader

How well does floating point work for 3D games/programs and gpus? That seems to be a very large category of floating point usage but I have no knowledge on whether it works well in that space. Would gpus be x% faster if they didn't have to do floating point, would games have more or less rendering problems without floating point?

View on HN

Generally floating point works fine for most things. Every now and then it doesn't, and you have to be aware enough of its weaknesses to (a) detect this, (b) understand what the hell is going on, and (c) find a workaround for it.

Indeed. Had a fun issue once where a colleague had prematurely optimized an expression to (a * c * e) / (b * d * f), this was in a somewhat hot path hence he wanted to eliminate divisions.

Turned out that in certain cases, the factors were all tiny and so both the numerator and denominator became denormalized and the division returned a NaN, ruining all further computations.

After a lot of debugging trying to find the source of the NaNs and understanding why exactly this happened the solution was quite clear, simply expand it back out: (a/b) * (c/d) * (e/f).

This was because due to the nature of the math being implemented, those ratios would always be roughly around order unity, even though each individual variable could potentially contain a very small number.

This costs us like 0.1% performance, but made the code handle all inputs without issue.

This comes up a lot in calculating odds, or ratio of probabilities. How one implements these in code is a good indicator of how much experience a person has with real world scenarios. One of those shibboleths. Another telltale giveaway is accumulating the dot product of float32s in float32s.

Serious probability calculations are usually best made in log-space, turning multiplication into addition.

Indeed -- https://en.wikipedia.org/wiki/Log_semiring

See this is why we keep you maths people around. Sometimes all that abstract wizardry is really useful! :)

I just hope that wasn't bitter sarcasm.

I think this would have been a more relevant link

https://en.wikipedia.org/wiki/LogSumExp#log-sum-exp_trick_fo...

I had similar problem too, that multiplication results had to be in range of 0 < x < 1 because after that, some log operations was resulting NAN, first I was using if/else which was slowed down noticeably and after I end up applying sigmoid which speed up things a bit, still I dont know exact cause and I am not brave to dive into that mess again

Works great for most things. Things can get a bit complicated for scenes/models with large coordinates and 32 bit floats, but that's not something that fixed precision integers/decimals would solve. An easy way to solve these issues is to use floats for some parts of the rendering pipeline and doubles for others, e.g. double precision matrices on CPU side, then compute a combined world-view matrix where huge camera and huge vertex coordinates cancel each other out. You can then cast the double precision world-view matrix to a single precision matrix and use that for rendering on the GPU.

Many years ago I wrote some 3D code for the 486SX, back when floating point units for PCs were optional extras. I used a fixed-point approach with 9 bits after the fixed point in 32-bit integer arithmetic. It worked pretty well, but doing that does force you to design the world coordinate system to avoid objects that are too small and suffer loss of precision errors.

I don't think it would entirely do away with things like z-fighting and seam alignment issues, but it would effectively "round" them off in more cases.

I'd definitely encourage any game developer trying to represent a "big world" to investigate fixed-point systems to avoid precision-loss problems creeping in when far away from the origin.

Floating-point is slightly more future proof in a world of increasing resolutions.

I think fixed point is more appropriate for a Cartesian coordinate system. Floating point will have better resolution only near (0, 0); the grid will get increasingly coarse as you move away from the origin.

Reply on news.ycombinator.com