meta/blit: Add stencil texturing mode save and restore

v2 (Ken): Only restore the mode if it has changed.

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/meta: Store stencil texturing mode

Meta path needs to keep the current texture object's state. Fixes
the following gles3 cts tests on bdw:

framebuffer_blit_functionality_negative_width_blit.test: fail
framebuffer_blit_functionality_all_buffer_blit.test: fail
framebuffer_blit_functionality_negative_height_blit.test: fail
framebuffer_blit_functionality_missing_buffers_blit.test: fail
framebuffer_blit_functionality_negative_dimensions_blit.test: fail
framebuffer_blit_functionality_minifying_blit.test: fail
framebuffer_blit_functionality_magnifying_blit.test: fail

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
vl: add interface for non-referenced frames

Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
radeon/vce: implement non-referenced frames

Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
st/omx/enc: implement restricted b frames pattern

Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
i965/sf: Reset flag_value to 0xff before emitting SF subroutines.

When compiling any of the SF program variants, flag_value starts off as
0xff and will be modified when generating code.

brw_emit_anyprim_setup emits several subroutines, saving and restoring
flag_value across each of them.  Since it starts out as 0xff, this is
equivalent to simply setting it to 0xff at the start of each subroutine.

Resetting the value makes more logical sense; each subroutine doesn't
know whether one of the others even executed, much less what it did
to the flag register.

This also lets us to drop the brw_set_predicate_control_flag_value call
from brw_init_compile: predicate is already initialized to
BRW_PREDICATE_NONE by the memset, and the value of flag_value is
irrelevant (as it's only used by the SF compiler).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Drop unnecessary predication default state resets in clip code.

Presumably, this was to reset the default state of predication_control
from brw_CMP.  But brw_CMP only sets that if dst is ARF null, which it
isn't here.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Don't implicitly set predicate default state in brw_CMP.

Previously, brw_CMP with a null destination implicitly set the default
state to make future instructions predicated.  This is messy and
confusing - emitting a CMP that populates the flag register and later
using it to predicate instructions are logically separate.  With the
main compiler, we may even schedule instructions between the CMP and the
user of the flag value.

This patch simplifies brw_CMP to just emit a CMP instruction, and not
mess with predication.  It also updates all necessary callers.  These
mostly fell into two patterns:

1. brw_CMP followed by brw_IF.

   We don't need to do anything special here; brw_IF already sets up
   predication appropriately.

2. brw_CMP followed by a single predicated instruction.

   The old model was to call brw_CMP, emit the next (predicated)
   instruction, then disable predication for any instructions beyond
   that.  Instead, just explicitly set predicate_control on the single
   instruction we want to predicate.  It's no more code, and requires
   less cross-module knowledge.

This drops setting flag_value to 0xff as well, which is a field only
used by the SF compile.  There is only one brw_CMP call in the SF code,
which is in do_twoside_caller, and called at the start of
brw_emit_tri_setup, where flag_value is already 0xff.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Drop unnecessary push/pop in do_twoside_color.

None of the assembly emitters called between push and pop actually
change the state.  So, we can drop these.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Drop useless push/pop state from flag register mashing code.

There's no point in pushing and popping the default state; the code
between the two stack operations doesn't alter anything.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Move brw_set_predicate_control_flag_value to brw_sf_emit.c.

Only the Gen4-5 SF program compiler actually uses this function; move
it there.  Soon the fields will be moved out of brw_compile.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Move brw_compile::flag_value to brw_sf_compile.

This field is only used to track the current value of the flag register
during the SF compile.  It has no place in the common compiler code.

While we're changing every call, drop the 'brw' prefix from the function
since it's static.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Drop unnecessary push/pop in flatshading code.

brw_JMPI sets predicate_control to BRW_PREDICATE_NONE, but that's
already the value coming in.  Otherwise, nothing changes state.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Drop unnecessary push/pop in copy_z_inv_w.

brw_MOV doesn't alter the default instruction state, so this does
nothing.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/sf: Replace push/pop in brw_emit_anyprim_setup.

Each of the subroutine emitters alter the predication state, but
otherwise don't change anything (or put it back when they do).
Resetting predication at the end makes these functions idempotent with
regard to the default instruction state - which is a nice property.

With that in place, push/pop is no longer necessary.

v2: Improve whitespace (requested by Matt).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
nvc0: add GK20A 3D class

GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0/ir: use SM35 ISA with GK20A

GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
meta/blit: Use gl_FragColor also in the msaa blit shader

Fixes framebuffer_blit_functionality_multisampled_to_singlesampled_blit
es3 cts test on bdw. Also fixes this on ivb when ivb is forced to use
the meta path.

No piglit regressions on IVB.

Further input from Ken:

 "Unfortunately, this doesn't fix MRT for integer data.

  In the single-sampled case, since we're directly copying data, we were
  read/copy/write data as "float" values, which actually contained the
  integer bits.  Here, we can't do that since we need to process the
  actual integer data.

  I do wonder if we could use intBitsToFloat/uintBitsToFloat to stuff the
  integer bits in the float gl_FragColor output.  Just a crazy idea.

  In the long term (post 10.2), I think we should draft an extension that
  allows you to do "layout(location = all)" on user-defined fragment
  shader outputs.  (Or some similar syntax.)"

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
egl-static: Fix undefined reference to `loader_*'

Trivial.  Better than a broken build.
i965: Fix repeated usage of rectangle texture coordinate scaling.

Previously, we set up new entries in the params[] array on every access
of a rectangle texture.  Unfortunately, we only reserve space for
(2 * MaxTextureImageUnits) extra entries, so programs which accessed
rectangle textures more times than that would write off the end of the
array and likely crash.

We don't really have a decent mapping between the index returned by
_mesa_add_state_reference and our index into the params array, so we
have to manually search for it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78691
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: mesa-stable@lists.freedesktop.org