d169f09e37
SMEM does the addition with 64-bits, not 32. So if the original code relied on wrapping around (for example, for subtraction), it would break. Apparently swizzled MUBUF accesses also have issues with combining additions that could overflow. Normal MUBUF accesses seem fine. fossil-db (Navi): Totals from 27219 (20.02% of 135946) affected shaders: CodeSize: 128303256 -> 131062756 (+2.15%); split: -0.00%, +2.15% Instrs: 24818911 -> 25280558 (+1.86%); split: -0.01%, +1.87% VMEM: 162311926 -> 177226874 (+9.19%); split: +9.36%, -0.17% SMEM: 18182559 -> 20218734 (+11.20%); split: +11.53%, -0.34% VClause: 423635 -> 424398 (+0.18%); split: -0.02%, +0.20% SClause: 865384 -> 1104986 (+27.69%); split: -0.00%, +27.69% Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2748 Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2720>
10 lines
556 B
Plaintext
10 lines
556 B
Plaintext
dEQP-VK.rasterization.flatshading.line_strip_wide
|
|
dEQP-VK.rasterization.flatshading.non_strict_line_strip_wide
|
|
dEQP-VK.rasterization.flatshading.non_strict_lines_wide
|
|
dEQP-VK.rasterization.interpolation.basic.line_strip_wide
|
|
dEQP-VK.rasterization.interpolation.basic.non_strict_line_strip_wide
|
|
dEQP-VK.rasterization.interpolation.basic.non_strict_lines_wide
|
|
dEQP-VK.rasterization.interpolation.projected.lines_wide
|
|
dEQP-VK.rasterization.interpolation.projected.non_strict_line_strip_wide
|
|
dEQP-VK.rasterization.interpolation.projected.non_strict_lines_wide
|