i965/fs: Fix dump_instructions() on uniforms.

All of a vec4 uniform was being printed as "u0"

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/fs: Handle arrays of special regs more cleanly.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/fs: Add a couple more global special regs to special[]

Nothing bad came of this because they weren't used after visitor running,
but leaving them in a bad state seems like a recipe for pain later.

Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
i965/fs: Track whether we're doing dual source in a more obvious way.

I'm going to be turning dual_src_output into an array in a moment.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/vec4: Add a test for copy propagation behavior.

I thought I was seeing a bug in the code while reviewing, but it's not
there.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/vec4: fix record clearing in copy propagation

Given

  mov vgrf7, vgrf9.xyxz
  add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
  add vgrf10.x, vgrf6.xyzw, vgrf7.wwww

the last instruction would be wrongly changed to

  add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz

during copy propagation.

The issue is that when deciding if a record should be cleared, the old code
checked for

  inst->dst.writemask & (1 << ch)

instead of

  inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch))

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749
Signed-off-by: Chia-I Wu <olv@lunarg.com>
Cc: Jordan Justen <jljusten@gmail.com>
Cc: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romainck <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.1" <mesa-stable@freedesktop.org>
svga: replace sampler assertion with conditional

For TEX instructions, the set of samplers and sampler views should
be consistent.  The XA state tracker sometimes passes an inconsistent
set of samplers and sampler views.  Rather than assert and die, issue
a warning.

v2: add debugging code to detect inconsistent state.
v3: also check for null sampler in svga_state_tss.c

Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
st/omx/enc: allocate input buffer private on demand

v2: move allocation to a function as first step
    to clean vid_enc_EncodeFrame

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
st/omx/enc: cleanup omx/vid_enc.c

cleanup by moving each step into a separate function

Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
mesa: add bounds checking to eliminate buffer overrun

Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.

v2: add more detail comment. Compute limit outside inner loops.
v3: add bugzilla reference
v4: Correct cc syntax in commit log
v5: really grab the right patch

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74988
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1, suggested v2-3]
freedreno/a3xx: deal with optimized tex instructions

Keep track of whether we actually have any sam instructions in the
resulting shader, rather than using TGSI SAMP declarations.  If the sam
instruction is optimized out, because the result is not used, we don't
want to emit texture state, etc.  In fact emitting sampler state and/or
setting PIXLODENABLE bit when there are no texture fetches seems to
cause lockup.

In theory this should never happen for a "normal" shader, unless the
state tracker is wonky.  But it is a very real possibility for binning
pass shaders.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
i965: Delete "fast color clear unsupported" performance warning.

Applications frequently clear to colors other than 0.0 or 1.0, which
prevents us from doing fast color clears.  In that case, we issue this
performance warning on basically every glClear call, resulting in so
much spam that it's nearly impossible to see any other messages.

Plus, I don't think it's useful.  We aren't suggesting a better way to
do what the application developers want---we're just telling them it
would be faster to do something they don't want.

Driver developers have no control over the clear color, so this message
is totally useless to them.

A better alternative to get this sort of information is to use
INTEL_DEBUG=blorp, which tells you whether color clears were fast,
simd16 repdata, or slow.

v2: Rebase on has_color_component changes.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: move declaration before code in etc2_unpack_rgb8()

To fix MSVC build since cb4ad1368551b.
i965: Remove unused sampler key fields

Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
tnl: Merge _tnl_vbo_draw_prims() into _tnl_draw_prims().

This should help prevent situations where we render without proper index
bounds. For example: https://bugs.freedesktop.org/show_bug.cgi?id=59455

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
gallium/radeon: fix warnings
r600g,radeonsi: set correct initial domain for shared resources
r600g,radeonsi: add a bunch of useful queries for the HUD
radeonsi: allow fast color clear and Hyper-Z with 1D-tiled surfaces on CIK

This depends on my kernel fix. Hyper-Z is still disabled by default.
freedreno/a3xx/compiler: fix neg mov's

create_mov() was fixed up to handle neg/abs properly for interal mov's,
using absneg.f, but forgot to fix it for TGSI MOV's.  The problem with
using add.f to handle negated mov's is that we can only take a single
const reg src.  So:

  MOV TEMP[n], -CONST[m]

would turn into:

  add.f Rdst, (neg)CONST[m], 0.0

which would not work.  Anyways, just remove the extra code and always
use create_mov() which DTRT.

This fixes piglit vs-op-neg-int test.

Signed-off-by: Rob Clark <robclark@freedesktop.org>