Comment # 10
on bug 83510
from Marek Olšák
(In reply to Henri Verbeet from comment #9) > (In reply to Marek Olšák from comment #8) > > (In reply to Christoph Haag from comment #7) > > > I think in the new "Lightroom Interior" the blackness glitch is visible in a > > > more interesting way: > > > https://www.youtube.com/watch?v=R9N-srsF_Fg > > > > I think I've tracked down what's causing the blackness in all Unreal Engine > > demos: Division by zero. > > > I didn't debug this of course, but it seems suspicious that this would > depend on division be zero returning zero instead of infinity. I don't think > any other driver for current hardware does that with GLSL. Are you sure > there's not a subsequent multiplication by zero that depends on INF * 0 > returning 0 instead of NAN? Yes, that's possible. However, some internal documents suggest that Catalyst always uses the standard IEEE version of MUL. There are also alternative opcodes for RSQ, RCP and LOG that don't generate NaNs and Infs, which can be used instead. You can certainly choose which behavior you want on a case-by-case basis. Sometimes you want 0 instead of NaN, other times you want 0 or FLT_MAX instead of Inf. The hardware has RSQ and RCP opcodes that do that. However, Tonga and later hardware doesn't have the legacy dx9 opcodes for MUL, MAD, RCP, RSQ, and LOG and they must be emulated with a comparison (or V_CLASS_F32 that returns whether it's NaN/+-Inf/Denorm/+-0/etc) + conditional assignment. It's better to do the conditional assignment after every RCP than after every MUL.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
