summaryrefslogtreecommitdiffstats
path: root/src/intel/compiler/brw_nir.h
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2017-12-25 19:10:22 -0800
committerKenneth Graunke <[email protected]>2018-01-02 16:51:42 -0800
commit74e1d6e20c186bd1bdcb6624e379727c1e18b5a6 (patch)
tree5c71262de262b20ca6196938da9f11281e382c4e /src/intel/compiler/brw_nir.h
parentbd32d4d0671777d9b7d6e3a592abb67563a8063c (diff)
i965: Drop support for the legacy SNORM -> Float equation.
Older OpenGL defines two equations for converting from signed-normalized to floating point data. These are: f = (2c + 1)/(2^b - 1) (equation 2.2) f = max{c/2^(b-1) - 1), -1.0} (equation 2.3) Both OpenGL 4.2+ and OpenGL ES 3.0+ mandate that equation 2.3 is to be used in all scenarios, and remove equation 2.2. DirectX uses equation 2.3 as well. Intel hardware only supports equation 2.3, so Gen7.5+ systems that use the vertex fetcher hardware to do the conversions always get formula 2.3. This can make a big difference for 10-10-10-2 formats - the 2-bit value can represent 0 with equation 2.3, and cannot with equation 2.2. Ivybridge and older were using equation 2.2 for OpenGL, and 2.3 for ES. Now that Ivybridge supports OpenGL 4.2, this is wrong - we need to use the new rules, at least in core profile. That would leave Gen4-6 doing something different than all other hardware, which seems...lame. With context version promotion, applications that requested a pre-4.2 context may get promoted to 4.2, and thus get the new rules. Zero cases have been reported of this being a problem. However, we've received a report that following the old rules breaks expectations. SuperTuxKart apparently renders the cars red when following equation 2.2, and works correctly when following equation 2.3: https://github.com/supertuxkart/stk-code/issues/2885#issuecomment-353858405 So, this patch deletes the legacy equation 2.2 support entirely, making all hardware and APIs consistently use the new equation 2.3 rules. If we ever find an application that truly requires the old formula, then we'd likely want that application to work on modern hardware, too. We'd likely restore this support as a driconf option. Until then, drop it. This commit will regress Piglit's draw-vertices-2101010 test on pre-Haswell without the corresponding Piglit patch to accept either formula (commit 35daaa1695ea01eb85bc02f9be9b6ebd1a7113a1): draw-vertices-2101010: Accept either SNORM conversion formula. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
Diffstat (limited to 'src/intel/compiler/brw_nir.h')
-rw-r--r--src/intel/compiler/brw_nir.h2
1 files changed, 0 insertions, 2 deletions
diff --git a/src/intel/compiler/brw_nir.h b/src/intel/compiler/brw_nir.h
index e9cb6f89948..809d4c338dc 100644
--- a/src/intel/compiler/brw_nir.h
+++ b/src/intel/compiler/brw_nir.h
@@ -102,7 +102,6 @@ brw_nir_link_shaders(const struct brw_compiler *compiler,
bool brw_nir_lower_cs_intrinsics(nir_shader *nir,
unsigned dispatch_width);
void brw_nir_lower_vs_inputs(nir_shader *nir,
- bool use_legacy_snorm_formula,
const uint8_t *vs_attrib_wa_flags);
void brw_nir_lower_vue_inputs(nir_shader *nir,
const struct brw_vue_map *vue_map);
@@ -121,7 +120,6 @@ nir_shader *brw_postprocess_nir(nir_shader *nir,
bool is_scalar);
bool brw_nir_apply_attribute_workarounds(nir_shader *nir,
- bool use_legacy_snorm_formula,
const uint8_t *attrib_wa_flags);
bool brw_nir_apply_trig_workarounds(nir_shader *nir);