i965/fs: Estimate maximum sampler message execution size more accurately.
authorFrancisco Jerez <currojerez@riseup.net>
Fri, 12 Aug 2016 21:05:19 +0000 (14:05 -0700)
committerFrancisco Jerez <currojerez@riseup.net>
Tue, 16 Aug 2016 23:31:59 +0000 (16:31 -0700)
commit4d436c011fd9f7ebcadbaebef05090d2056e9d48
tree9839bf80bfbf45023eaa3620591baaabdd04c060
parent61a02fb74c07d574b726a8b27517a02251aa4be4
i965/fs: Estimate maximum sampler message execution size more accurately.

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
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
src/mesa/drivers/dri/i965/brw_fs.cpp