intel/compiler/fs: Still attempt simd32 when INTEL_DEBUG=no16 is used
authorJordan Justen <jordan.l.justen@intel.com>
Sun, 31 May 2020 16:27:28 +0000 (09:27 -0700)
committerJordan Justen <jordan.l.justen@intel.com>
Thu, 9 Jul 2020 22:44:57 +0000 (15:44 -0700)
If INTEL_DEBUG=no16 is used, then simd16 will not be attempted. This,
in turn prevents simd32 from running, because we attempt to skip
simd32 when simd16 fails to compile.

This change more accurately recognizes when we attempted simd16, but
simd16 failed.

One easy way to cause an issue is to set both no8 and no16. Before
this change, we would be left with no FS program, even though simd32
could still be generated in some cases.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5269>

src/intel/compiler/brw_fs.cpp

index e10c6705858aeee31eba9dcd07cdee25830c4545..4ba0c8ed073339cb0bdfdf60eb0228b4ec891571 100644 (file)
@@ -8657,10 +8657,12 @@ brw_compile_fs(const struct brw_compiler *compiler, void *log_data,
       }
    }
 
+   const bool simd16_failed = v16 && !simd16_cfg;
+
    /* Currently, the compiler only supports SIMD32 on SNB+ */
    if (!has_spilled &&
        v8->max_dispatch_width >= 32 && !use_rep_send &&
-       devinfo->gen >= 6 && simd16_cfg &&
+       devinfo->gen >= 6 && !simd16_failed &&
        !(INTEL_DEBUG & DEBUG_NO32)) {
       /* Try a SIMD32 compile */
       v32 = new fs_visitor(compiler, log_data, mem_ctx, &key->base,