[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79575

--- Comment #10 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to comment #8)
> (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.
Well with analsysis lots of things can go on. As a simple example, llvm could
for instance recognize some float const is the same as some int const, and I
could easily imagine just such basic analysis throwing fpu exceptions all over
the place.
As far as I can tell though, if an app doesn't set that fpu preserve bit, d3d
will set some single precision mode with trunc rounding, but still have all
exceptions masked. And if an app does set the fpu preserve bit, the control
word will be left alone - near certainly in this case fpu exceptions are still
masked (but potentially rounding / precision bits different) because noone
wants to bother with them (and all exceptions masked is the default).
(That second case is what you'd get with "ordinary" apps outside of wine, and
it doesn't look like it's really a problem in practice. So, only the test in
wine really hits that.)

> 
> > 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.)
The dependency might be painful but home-grown optimizers will get pretty
complex fast. Besides, if you really have apps which set the control word to
unmask exceptions, I'm pretty sure you can trigger exceptions inside core mesa
too.
As said, I'm not entirely sure what the expected behavior really is if you call
into library code with non-default fpu control word. On some cpus setting the
fpu control word can actually be very expensive (though some have it fully
pipelined now so it's cheap).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/52b5de6b/attachment-0001.html>