Comment # 8
on bug 79575
from Henri Verbeet
(In reply to comment #7) > Looks like this is happening purely for testing if a fpu control word would > be preserved, the actual value used by d3d does disable them just fine > (though, of course, this could also happen on any app, not just wine, if it > unmasks exceptions before calling into mesa code). It's perhaps important to point out that Wine isn't a single application as such, and we don't have a lot of control over how individual applications setup the FPU. The test in question exists because some applications expect us to setup the FPU in a specific way, while others expect us to leave it alone. Without having looked much into the llvm source for the backtrace, it's perhaps also a bit odd that compiling a pass-through shader is doing anything involving denormals in the first place. > Though IIRC you aren't actually expected to leave the fpu control word in a > non-standard state when you're calling into library code, so I'm not really > sure if this qualifies as a mesa bug. In any way since this happens in llvm > code finally here it might even be a bug there. I guess the only way to fix Mostly just for reference, regressions every now and then aside, the Wine D3D tests pretty much just pass with r600g / sb; that's currently my main development setup. (And somewhat off-topic, but not entirely unrelated to this bug, the reason that that's not a radeonsi system is because I think the llvm dependency is just painful to work with.)
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
