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

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|FIXED   |WONTFIX

--- Comment #12 from Samuel Pitoiset  ---
As discussed offline with Michel Dänzer, the status should be WONTFIX rather
than FIXED. Sorry for the noise.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from Samuel Pitoiset  ---
Quite old bug (almost 3 years ago). The AMD open source stack has largely
evolved since 2014. Closing.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #10 from Roland Scheidegger  ---
(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: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Andrei Slavoiu  ---
Created attachment 104462
  --> https://bugs.freedesktop.org/attachment.cgi?id=104462=edit
r600_debug_ps.log

Output when ran with R600_DEBUG=ps

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 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.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Roland Scheidegger  ---
Specifically it looks like the wine test actually tries a control word which
enables all fpu exceptions.
Seems like nvidia drivers had the same problem at some point:
http://bugs.winehq.org/show_bug.cgi?id=28634
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).
I vaguely remember similar issues in the past in other parts of mesa code.
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
this kind of bug in mesa would be to change the fpu control word on all entry
points which could trigger numerical exceptions (and when additionally also
consistent results are on the wish list, would need to change it on all
entrypoints which could do some fpu calculations)) which I think is not
reasonable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from Michel D?nzer  ---
(In reply to comment #5)
> I tried adding R600_DEBUG=fs but no extra info was printed.

That should be R600_DEBUG=ps for the pixel/fragment shader (you can see a list
of supported debugging options with R600_DEBUG=help).

Anyway, this is probably related to comment #3.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Andrei Slavoiu  ---
BTW, I just noticed that in the latest backtrace
util_make_vertex_passthrough_shader_with_so no longer appears. Instead it
starts from util_make_empty_fragment_shader. I tried adding R600_DEBUG=fs but
no extra info was printed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Andrei Slavoiu  ---
Created attachment 104309
  --> https://bugs.freedesktop.org/attachment.cgi?id=104309=edit
r600_debug_vs.log

Log file with R600_DEBUG=vs

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Henri Verbeet  ---
For what it's worth, test_fpu_setup() tests creating a D3D device with a custom
FPU control word. (The background on that is that creating a D3D device should
setup the FPU in a specific way, depending on if D3DCREATE_FPU_PRESERVE is
specified or not.) My guess would be that something in llvm doesn't expect to
be called with a non-default FPU control word.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Michel D?nzer  ---
(In reply to comment #1)
> Can you post the output of R600_DEBUG=cs ?

Make that R600_DEBUG=vs , since the crash occurs in
util_make_vertex_passthrough_shader_with_so().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Tom Stellard  ---
Can you post the output of R600_DEBUG=cs ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: