nvc0/ir: avoid infinite recursion when finding first uses of tex

In certain circumstances, findFirstUses could end up doubling back on
instructions it had already processed, resulting in an infinite
recursion. Avoid this by keeping track of already-visited instructions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83079
Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nv50: zero out unbound samplers

Samplers are only defined up to num_samplers, so set all samplers above
nr to NULL so that we don't try to read them again later.

Tested-by: Christian Ruppert <idl0r@qasl.de>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nvc0: don't make 1d staging textures linear

Experimentally, the sampler doesn't appear to like these, neither as
buffer nor as rect textures. So remove 1D from the list of texture types
to make linear when used for staging.

This fixes the OSD in mplayer for VDPAU.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nv50/ir: avoid creating instructions that can't be emitted

When constant folding a MAD operation, we first fold the multiply and
generate an ADD. However we do so without making sure that the immediate
can be handled in the saturate case. If it can't, load the immediate in
a separate instruction.

Reported-by: Tiziano Bacocco <tizbac2@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nv50: set the miptree address when clearing bo's in vp2 init

The mt address is about to be used more, make sure it's set
appropriately.

Reported-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nv50: mt address may not be the underlying bo's start address

With VP2, nv50_miptree is faked because the underlying bo's have to be
laid out in a certain way. This is done by adjusting the address. Make
sure that blits (and everything else for consistency) use the mt address
rather than the bo address as a base.

This fixes retrieving chroma plane with VDPAU.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82255
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
nv50: attach the buffer bo to the miptree structures

The current code... makes no sense. Use nouveau_bo_ref to attach the bo
to the exposed resource so as to have the proper lifetime guarantees.

Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
mesa: force height of 1D textures to be 1 in texture views

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
nv50: remove unused variables

Recent code changes have caused these to no longer be used. Remove them.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nouveau/nv40: quiten coverity warning in unused vertex texture code.

This fixes the code, but we never run it anyways, so silence coverity.

Signed-off-by: Dave Airlie <airlied@redhat.com>
xvmc/tests: %C isn't a valid printf specifier.

Reported-by: Coverity scanner.

Signed-off-by: Dave Airlie <airlied@redhat.com>
nouveau: don't leak dec struct on error

This one path doesn't goto fail, so it seems to leak dec.

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
i965: add missing parens in vec4 visitor

coverity reported this, Matt said it look like missing parens,
not bad identing, so lets try that.

Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Signed-off-by: Dave Airlie <airlied@redhat.com>
i965: Create a macro for setting a dirty bit.

This will make it easier to extend dirty bit handling to support
compute shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965: Create a macro for setting all dirty bits.

This will make it easier to extend dirty bit handling to support
compute shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965: Create a macro for checking a dirty bit.

This will make it easier to extend dirty bit handling to support
compute shaders.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965: Modify dirty bit handling to support 2 pipelines.

The hardware state for compute shaders is almost entirely orthogonal
to the hardware state for 3D rendering.  To avoid sending unnecessary
state to the hardware, we'll need to have a separate set of state
atoms for the compute pipeline and the 3D pipeline.  That means we
need to maintain two separate sets of dirty bits to determine which
state atoms need to be run.

But the dirty bits are not completely independent; for example, if
BRW_NEW_SURFACES is flagged while doing 3D rendering, then not only do
we need to re-run 3D state atoms that depend on BRW_NEW_SURFACES, but
we also need to re-run compute state atoms that depend on
BRW_NEW_SURFACES.  But we'll also need to re-run those state atoms the
next time the compute pipeline is run.

To accomplish this, we record two sets of dirty bits, one for each
pipeline.  When bits are dirtied (via SET_DIRTY_BIT() or
SET_DIRTY_ALL()) we set them to the dirty state in both pipelines.
When brw_state_upload() is run, we clear the dirty bits just for the
pipeline that was run.

Note that since the number of pipelines is known at compile time to be
2, the compiler should unroll the loops in SET_DIRTY_BIT() and
SET_DIRTY_ALL().

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965: Modify state upload to allow 2 different sets of state atoms.

The set of state atoms for compute shaders is currently empty; it will
be filled in by future patches.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
mesa: Convert NewDriverState to 64-bits

i965 will have more than 32 bits when BRW_STATE_COMPUTE_PROGRAM is added.

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
main/cs: Add gl_context::ComputeProgram

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>