i965: Restore a lost comment about TXF offset bugs.

Eric's original code to work around TXF offset bugs contained a comment
explaining the problem, which was lost when Chris generalized it to an
IR transformation (in commit 598ca510b8a118c3c7e18b5d031a2b116120e0a6).

This commit adds the original comment to the newer code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Drop ir->op != ir_txf condition in offset checking.

brw_lower_unnormalized_offset sets ir->offset to NULL if it applies the
texelFetchOffset workarounds, so there's no need to special case it
here---there won't be an offset for ir_txf.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Move texel offset handling to visit(ir_texture *).

This moves the handling of non-constant texel offset subexpression trees
to the place where we visit other such subtrees.  It also removes some
uses of ir->offset in emit_texture_gen7, which will be useful when we
write the backend for our new upcoming IR.

Based on a patch by Connor Abbott.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: don't use ir->offset in emit_texture_gen5.

v2 (Ken): Refactor the Gen7 code separately; rebase.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Make brw_texture_offset() not use ir_texture.

Our new IR won't have ir_texture objects.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Rename "length" to "components" in emit_mcs_fetch().

This is slightly clearer.  Based on a patch by Connor Abbott.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Make emit_mcs_fetch() not use ir_texture.

Our new IR won't have ir_texture objects.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: make rescale_texcoord() not use ir_texture.

Our new IR won't have ir_texture objects, but using glsl_type is fine.

v2 (Ken): Drop redundant ir->coordinate NULL check; rebase.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Don't use ir->coordinate in emit_texture_*.

This drops a dependency on ir_texture objects.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Don't use ir->lod_info.grad.dPd<x,y> in emit_texture_*.

This drops a dependency on ir_texture objects.

v2 (Ken): Rename lod_components to grad_components, as it only has a
          meaningful value for ir_txd.  We could set it to 1 for TXL,
          but there's no real need.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: don't use ir->type in emit_texture_gen4()

We already have the type from the original destination.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: don't pass in ir_texture to emit_texture_*

At this point, the only thing it's used for is the opcode.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: fix integer textures with swizzles

This happened to work before, but it would convert the output to a float
and then back to an integer which seems bad.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Make swizzle_result() not use ir_texture.

Our new IR won't have ir_texture objects.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Make gather_channel() not use ir_texture.

Our new IR won't have ir_texture objects.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: Refactor the texture emission logic into a single function.

Before, we had 3 different emit functions for various different gen's,
as well as some ancilliary work that was the same across all gen's which
was either contained in functions or duplicated across the GLSL IR and
Mesa IR backends. Now, we have a single method, emit_texture(), that
takes all the information needed to make a texture instruction and
handles all the setup, and all we have to do to emit a texture
instruction while converting from GLSL IR, Mesa IR, or any new backend
is to extract the information emit_texture() needs and then call it.

v2: Significant rebasing (by Ken).

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965/fs: don't make a fake ir_texture in the Mesa IR frontend

Now that we've made all the texture emit code mostly independent of GLSL
IR, this isn't necessary any more.

Signed-off-by: Connor Abbott <connor.abbott@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
vc4: correctly include the source files

The kernel files are built into a separate static library and
all the functions that require it are already wrapped in ifdef
USE_VC4_SIMULATOR. Don't forget the header file :)

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Add usage history bitfield to buffer objects

In the drivers, we occasionally want to reallocate the backing
store for a buffer object; often to avoid waiting for the GPU
to be finished with the previous contents.

At the point that happens, we don't have a good way of determining
where else the buffer object may be bound, and so no good way of
determining which dirty flags need to be raised -- it's fairly
expensive to go looking at all the possible binding points.

Until now, we've considered any BO to be possibly bound as a UBO or
TexBO, and flagged all that state to be reemitted.

Instead, remember what kinds of binding point this buffer has ever
been used with, so that the drivers can flag only what they need.
I don't expect these bits to ever be reset, but that doesn't matter
for reasonable apps.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
mesa: Mark buffer objects which are bound as UBOs

When a buffer object is bound to one of the indexed uniform buffer
binding points, assume that from that point on it may be used as
a uniform buffer.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>