3 ms·
It turned out to be something different, but another much more common source of shader output differences is when a float value is clamped to integer (with the
by flohofwoe 15d ago
It turned out to be something different, but another much more common source of shader output differences is when a float value is clamped to integer (with the value being very close to the closest integer), and then use the clamped value as index (or tex coord with an unfiltered sampler). This may result in an off-by-one error on some gpu/driver combos but not others. Completely understandable why it happens, but hard to catch unless testing on a wide range of GPUs and drivers.
TL;DR: don't expect that floating point operations on GPUs are strictly IEEE-754 compatible
- jamiejquinn 15d agoDamn, coming from the CUDA world, this is quite unexpected. Do you know of any resources on FP in the graphics hardware? I mean do they fit A standard (nvfp, bf, etc?)?
- ablob 15d agoAs far as I know you might want to read the GLSL or Vulkan specification. At least there (and by extension in SPIR-V) you can select different floating point behaviors. Historically graphics programming has been more concerned with looking good rather than being accurate, and behavior is likely different on each GPU. It's a "hop into the water and learn to swim" kind of thing as far as I'm concerned. You will find errors for things you'll never have thought about and there is hardly any way to brace for it except trying on the go.
- jamiejquinn 15d agoAppreciate the looking good aspect but surely the graphics community also appreciates some level of consistency...?
- flohofwoe 14d agoIn short: Benchmark numbers were always more important than consistency (traditionally, GPU vendors competed on frames-per-second, not on image quality). E.g. floating point behaviour is only the tip of the iceberg. Every GPU vendor also does mipmapping differently (to balance image quality versus required memory bandwidth).