4 ms·

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 whet

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?

taneq 7y ago
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.
- magicalhippo 7y ago
  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.
  - hrgiger 7y ago
    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
  - srean 7y ago
    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.
    - eutectic 7y ago
      Serious probability calculations are usually best made in log-space, turning multiplication into addition.
      - srean 7y ago
        Indeed -- https://en.wikipedia.org/wiki/Log_semiring https://en.wikipedia.org/wiki/Log_semiring
        taneq 7y ago
        See this is why we keep you maths people around. Sometimes all that abstract wizardry is really useful! :)
        srean 7y ago
        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_for_log-domain_calculations https://en.wikipedia.org/wiki/LogSumExp#log-sum-exp_trick_fo...
mschuetz 7y ago
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.
pjc50 7y ago
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.
- jbay808 7y ago
  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.

taneq 7y ago

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.

magicalhippo 7y ago
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.
- hrgiger 7y ago
  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
- srean 7y ago
  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.
  - eutectic 7y ago
    Serious probability calculations are usually best made in log-space, turning multiplication into addition.
    - srean 7y ago
      Indeed -- https://en.wikipedia.org/wiki/Log_semiring https://en.wikipedia.org/wiki/Log_semiring
      - taneq 7y ago
        See this is why we keep you maths people around. Sometimes all that abstract wizardry is really useful! :)
        srean 7y ago
        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_for_log-domain_calculations https://en.wikipedia.org/wiki/LogSumExp#log-sum-exp_trick_fo...

mschuetz 7y ago

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.

pjc50 7y ago

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.

jbay808 7y ago
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.