i965/fs: Estimate maximum sampler message execution size more accurately

Graphics / Mesa 3D Graphics Library / Mesa - Francisco Jerez [riseup.net] - 16 August 2016 18:31 UTC

The current logic used to determine the execution size of sampler messages was based on special-casing several argument and opcode combinations, which unsurprisingly missed the possibility that some messages could exceed the payload size limit or not depending on the number of coordinate components present. In particular:

- The TXL, TXB and TEX messages (the latter on non-FS stages only) would attempt to use SIMD16 on Gen7+ hardware even if a shadow reference was present and the texture was a cubemap array, causing it to overflow the maximum supported sampler payload size and crash.

- The TG4_OFFSET message with shadow comparison was falling back to SIMD8 regardless of the number of coordinate components, which is unnecessary when two coordinates or less are present.

Both cases have been handled incorrectly ever since cubemap arrays and texture gather were respectively enabled (the current logic used by the SIMD lowering pass is almost unchanged from the previous no16 fall-back logic used pre-SIMD lowering times).

Fixes the following GL4.5 conformance test on Gen7-8 (the bug also affects Gen9+ in principle, but SKL passes the test by luck because it manages to use the TXL_LZ message instead of TXL):

GL45-CTS.texture_cube_map_array.sampling

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

4d436c0 i965/fs: Estimate maximum sampler message execution size more accurately.
src/mesa/drivers/dri/i965/brw_fs.cpp | 109 ++++++++++++++++++++++------------
1 file changed, 72 insertions(+), 37 deletions(-)

Upstream: cgit.freedesktop.org

  • Share