I recently did some refactoring of the AF fract code to use a lookup table of values. Unexpectedly this appears to have ballooned the runtime of all fract tests. Tint has been forced to suppress them due to timeouts, https://dawn-review.googlesource.com/c/dawn/+/185183.
There were already existing AF fract tests, so this isn't a case of just adding more slow tests. Additionally the f32 and f16 tests appear to be slow too.
I suspect this is related to all the lookup data being stored in a single file, af_data.ts and so fract is paying costs associated with the other look up tables. I am going to attempt to refactor the tables into seperate files and see if that resolves the issue. If that isn't successful I will have to investigate further.
I recently did some refactoring of the AF fract code to use a lookup table of values. Unexpectedly this appears to have ballooned the runtime of all fract tests. Tint has been forced to suppress them due to timeouts, https://dawn-review.googlesource.com/c/dawn/+/185183.
There were already existing AF fract tests, so this isn't a case of just adding more slow tests. Additionally the f32 and f16 tests appear to be slow too.
I suspect this is related to all the lookup data being stored in a single file, af_data.ts and so fract is paying costs associated with the other look up tables. I am going to attempt to refactor the tables into seperate files and see if that resolves the issue. If that isn't successful I will have to investigate further.