i965: Drop support for the legacy SNORM -> Float equation.
authorKenneth Graunke <kenneth@whitecape.org>
Tue, 26 Dec 2017 03:10:22 +0000 (19:10 -0800)
committerKenneth Graunke <kenneth@whitecape.org>
Wed, 3 Jan 2018 00:51:42 +0000 (16:51 -0800)
commit74e1d6e20c186bd1bdcb6624e379727c1e18b5a6
tree5c71262de262b20ca6196938da9f11281e382c4e
parentbd32d4d0671777d9b7d6e3a592abb67563a8063c
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 <jason@jlekstrand.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
src/intel/blorp/blorp.c
src/intel/compiler/brw_compiler.h
src/intel/compiler/brw_nir.c
src/intel/compiler/brw_nir.h
src/intel/compiler/brw_nir_attribute_workarounds.c
src/intel/compiler/brw_vec4.cpp
src/intel/compiler/brw_vec4_vs.h
src/intel/compiler/brw_vec4_vs_visitor.cpp
src/intel/vulkan/anv_pipeline.c
src/mesa/drivers/dri/i965/brw_vs.c