diff options
author | Kenneth Graunke <[email protected]> | 2017-12-25 19:10:22 -0800 |
---|---|---|
committer | Kenneth Graunke <[email protected]> | 2018-01-02 16:51:42 -0800 |
commit | 74e1d6e20c186bd1bdcb6624e379727c1e18b5a6 (patch) | |
tree | 5c71262de262b20ca6196938da9f11281e382c4e /src/intel/compiler/brw_nir.c | |
parent | bd32d4d0671777d9b7d6e3a592abb67563a8063c (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.c')
-rw-r--r-- | src/intel/compiler/brw_nir.c | 4 |
1 files changed, 1 insertions, 3 deletions
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c index 265c63efdda..dbddef0d04d 100644 --- a/src/intel/compiler/brw_nir.c +++ b/src/intel/compiler/brw_nir.c @@ -211,7 +211,6 @@ remap_patch_urb_offsets(nir_block *block, nir_builder *b, void brw_nir_lower_vs_inputs(nir_shader *nir, - bool use_legacy_snorm_formula, const uint8_t *vs_attrib_wa_flags) { /* Start with the location of the variable's base. */ @@ -230,8 +229,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir, add_const_offset_to_base(nir, nir_var_shader_in); - brw_nir_apply_attribute_workarounds(nir, use_legacy_snorm_formula, - vs_attrib_wa_flags); + brw_nir_apply_attribute_workarounds(nir, vs_attrib_wa_flags); /* The last step is to remap VERT_ATTRIB_* to actual registers */ |