i965: Always look up from the object's mt when setting up texturing state.

We know that the object's mt is equal to the firstimage's mt because it's
gone through intel_finalize_mipmap_tree().  Saves a lookup of firstimage
on pre-gen7.

v2: Merge in the warning fix that appeared later in the series (noted by
    Chad)

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Totally switch around how we handle nonzero baselevel-first_level.

This has no effect currently, because intel_finalize_mipmap_tree() always
makes mt->first_level == tObj->BaseLevel.

The change I made before to handle it
(b1080cfbdb0a084122fcd662cd27b4748c5598fd) got very close to working, but
after fixing some unrelated bugs in the series, it still left
tex-miplevel-selection producing errors when testing textureLod().  The
problem is that for explicit LODs, the sampler's LOD clamping is ignored,
and only the surface's MIP clamping is respected.  So we need to use
surface mip clamping, which applies on top of the sampler's mip clamping,
so the sampler change gets backed out.

Now actually tested with a non-regressing series producing a non-zero
computed baselevel.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Drop a special case for guessing small miptree levels.

Let's say you started allocating your 2D texture with level 2 of a tree as
a 1x1 image.  The driver doesn't know if this means that level 0 is 4x4 or
4x1 or 1x4, so we would just allocate a single 1x1 and let it get copied
in to the real location at texture validate time later.

Since this is just a temporary allocation that *will* get copied, the
extra space allocation of just taking the normal path which will happen to
producing a 4x1 level 0, 2x1 level 1, and 1x1 level 2 is the right way to
go, to reduce complexity in the normal case.

No change in miptree copies over the course of a piglit run.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Stop allocating miptrees with first_level != 0.

If the caller shows up with GL_BASE_LEVEL != 0, it doesn't mean that the
texture will over the course of its lifetime have that nonzero baselevel,
it means that the caller is filling the texture from the bottom up for
some reason (one could imagine demand-loading detailed texture layers at
runtime, for example).  If we allocate from just the current baselevel, it
means when they come along with the next level up, we'll have to allocate
a new miptree and copy all of our bits out of the first miptree.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Don't allocate a 1-level texture when GL_GENERATE_MIPMAP is set.

Given that a teximage that calls us with this flag set will immediately
proceed to allocate the other levels, we can probably just go ahead and
allocate those levels now.

Reduces miptree copies in piglit by about .05%.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Don't relayout a texture just for baselevel changes.

As long as the baselevel, maxlevel still sit inside the range we had
previously validated, there's no need to reallocate the texture.

I also hope this makes our texture validation logic much more obvious.
It's taken me enough tries to write this change, that's for sure.  Reduces
miptree copy count on a piglit run by 1.3%, though the change in amount of
data moved is much smaller.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Always allocate validated miptrees from level 0.

No change in copies during a piglit run, but it's one less first_level !=
0 in our codebase.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Add missing license to intel_tex_validate.c.

I've rewritten a lot of this file.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Add a real native TexStorage path.

We originally had a path just did the loop and called
ctx->Driver.AllocTextureImageBuffer(), which I moved into Mesa core.  But
we can do better, avoiding incorrect miptree size guesses and later
texture validations by just directly allocating the miptree and setting it
to all the images.

v2: drop debug printf.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: retype destination register for texture SEND instruction to UW.

From the bspec documentation of the SEND instruction:

    "destination region cannot cross the 256-bit register boundary."

To avoid violating this restriction when executing SIMD16 texturing
operations (such as those used by blorp), we need to ensure that the
destination of the SEND instruction doesn't exceed 256 bits in size.
An easy way to do this is to set the type of the destination register
to UW (unsigned word), since 16 unsigned words can fit inside a
256-bit register.  Fortunately, this has no effect on the sampling
operation, since the sampler always infers the destination data type
from the sampler message rather than from the type of the instruction
operand.

Previously, we did this for texturing operations issued by the vec4
and fs back-ends, but not for blorp.  This patch makes blorp use the
same trick.

I haven't observed any behavioural difference on actual hardware due
to this patch, but it avoids a warning from the simulator so it seems
like the right thing to do.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Chad Versace <chad.versace@linux.intel.com>
i965/fs: Improve accuracy of dFdy().

Previously, we computed dFdy() using the following instruction:

  add(8) dst<1>F src<4,4,0)F -src.2<4,4,0>F { align1 1Q }

That had the disadvantage that it computed the same value for all 4
pixels of a 2x2 subspan, which meant that it was less accurate than
dFdx().  This patch changes it to the following instruction:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }

Which has comparable accuracy to dFdx().

Unfortunately, for some reason the SIMD16 version of this instruction:

  add(16) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1H }

Doesn't seem to work reliably (presumably the hardware designers never
validated the combination of align16 mode with compressed
instructions), so we unroll it to:

  add(8) dst<1>F src<4,4,1>.xyxyF -src<4,4,1>.zwzwF { align16 1Q }
  add(8) (dst+1)<1>F (src+1)<4,4,1>.xyxyF -(src+1)<4,4,1>.zwzwF { align16 2Q }