Hi, I don't have a strong opinion, but I think I'd lean more towards 1), explicitly disabling exceptions in code that we think is more likely to produce them.
Using -ftrapping-math globally seems like it may carry performance implications and I am not sure it makes sense to pay that price for what seems like more exceptional behavior on the app's side? We would be penalizing a large majority for a singular exception. I don't like 3) too much, since behavior is less predictable as things would depend on the precise time at which the app enables floating point exceptions. Iago El mar, 08-09-2026 a las 12:02 +1000, Timothy Arceri escribió: > Hi all, > > I'd like to move forward MR 42611 (or its alternate patch) as a real > game is currently crashing on mesa drivers, but those who have > commented on the MR are at a deadlock as to what is the best way to > handle user enabled floating point exception flags inside the > compiler. > > The problem with the game is the exception when evaluating a divide > by > zero in the shaders math, as the game has floating point exception > flags turned on. > > There are currently three options I can see: > > 1. Disable the exceptions whenever the compiler evaluates math from > the > shader (see patch [2]) and then re-enable them afterwards, here we > just > ignore the chance that anything else in mesa generates the exceptions > which can be possible (but not currently seen) as we enable the build > flag no-trapping-math > > 2. Apply the above patch and apply the -ftrapping-math flag to builds > so that clang doesn't default to no-trapping-math > > 3. Use the patch the MR currently carries that just disables the > exceptions at context and screen creation time, and leave them > disabled > behind the applications back. > > I would be happy enough with 1 landing as it solves the game bug, 2 > is > the most complete solution but means we no longer set no-trapping- > math, > 3 disables floating point exception flags outright, but doesn't cover > vulkan and can disable the flags for the application, it might also > be > possible the calling application turns them on again later and new > threads will pick up that change but I'm not 100% sure if that can > end > up happening in mesa. > > I'd appreciate any thoughts on how we should move this forward. > > Thanks, > Tim > > > [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42611 > [2] > https://gitlab.freedesktop.org/-/project/176/uploads/361c2f02fd14a994e864719ee5a5dfca/0001-nir-temporarily-disable-floating-point-exception-fla.patch >
