r600g,radeonsi: workaround for late shared screen initialization

Accidentally broken by the consolidation.
st/mesa: fix comment typo
r600g/sb: Move variable dereference after null check.

Fixes "Deference before null check" defect reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Vadim Girlin <vadimgirlin@gmail.com>
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>
Use -Bsymbolic when linking libEGL.so

For some reason that I don't yet fully understand, Glaze does not work with
libEGL unless libEGL is linked with -Bsymbolic.[*]

Beyond that specific reason, all of the reasons for which libGL.so is linked
with -Bsymbolic, (see the commit history), should also apply here.

[*] The specific behavior I am seeing is that when Glaze calls dlopen for
libEGL.so, ifunc resolvers within Glaze for EGL functions are called before
the dlopen returns. These resolvers cannot succeed, as they need the return
value from dlopen in order to find the functions to resolve to. I don't know
what's causing these resolvers to be called, but I have verified that linking
libEGL with -Bsymbolic causes this problematic behavior to stop.

CC: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
mesa: Remove all traces of GL_OES_matrix_get

I believe this extension was enabled by accident.  As far as I can tell,
there has never been any code in Mesa to actually support it.  Not only
that, this extension is only useful in the common-lite profile, and Mesa
does the common profile.

This "fixes" the piglit test oes_matrix_get-api.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Reenable glBitmap() after the sRGB winsys enabling.

The format of the window system framebuffer changed from ARGB8888 to
SARGB8, but we're still supposed to render to it the same as ARGB8888
unless the user flipped the GL_FRAMEBUFFER_SRGB switch.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
NOTE: This is a candidate for stable branches.
gallium: include u_surface.h instead of u_rect.h

u_rect.h was including u_surface.h just to avoid touching a bunch
of other source files after some functions were moved from u_rect.h
to u_surface.h.  This patch cleans up that hack.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
svga: we don't support TGSI_OPCODE_CONT

So return PIPE_SHADER_CAP_TGSI_CONT_SUPPORTED = 0.
svga: return 0 for PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER

Using the map/unmap path for glTexImage is a little bit faster
than blitting.  Also, this fixes about 50 assorted piglit failures
that seem to be related to the blit version of glReadPixels.

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
svga: fix pixel center integer

The svga/d3d9 convention is that pixel centers are at integer coordinates.
Fixes piglit glsl-arb-fragment-coord-conventions test.

Reviewed-by: José Fonseca <jfonseca@vmware.com>