On Tue, 2026-09-08 at 15:19 +0200, Job Noorman wrote: > Hi, > > There is a fourth option as well: move to a full softfloat > implementation for constant evaluation. This has the added benefit of > making the compiler output more deterministic. It's also how other > compilers handle constant evaluation IIUC. > > I have been experimenting with this in the context of enabling > compiler > cache sharing between different host architectures. It isn't ready to > be > shared yet but if people think this idea has merits, I can clean it > up > sooner.
Its an interesting solution, I guess we would want to make sure its fast enough (or confirm its not a measurable change) to be a suitable replacement, compile times are a big deal after all. For now I guess option 1 wins. > > Cheers, > Job > > On 08/09/2026 04:02, Timothy Arceri wrote: > > 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
