r600g/radeonsi: Use caching buffer manager for textures as well

Significantly reduces BO allocation / destruction overhead for transfers,
e.g. measurable via x11perf -shm{ge,pu}t* with glamor.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
i965: Update comments about Z16 being slow.

We've learned a few things since we originally disabled Z16; this attempts
to summarize the issue.  I am no expert on this subject, though, so the
comment may not be totally accurate.

I did some benchmarking on GM45 and Ironlake, and discovered that for
GLBenchmark 2.7 EgyptHD, using Z16 was 3% slower on GM45 (n=15), and
4.5% slower on Ironlake (n=95).  So, we can drop the "on Ivybridge"
aspect of the comment - it's always slower.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
i965: Disable Z16 in all APIs.

We originally thought that GL 3.0 required GL_DEPTH_COMPONENT16 to map
exactly to Z16.  However, we misread the specification, thanks in part
to LaTeX reordering the tables in the PDF.

Page 180 of the GL 3.0 specification (glspec30.20080923.pdf) says:
"[...] memory allocation per texture component is assigned by the GL to
match the allocations listed in tables 3.16-3.18 as closely as possible.
[...]

Required Texture Formats
[...]
In addition, implementations are required to support the following sized
internal formats.  Requesting one of these internal formats for any
texture type will allocate exactly the internal component sizes and
types shown for that format in tables 3.16-3.17:"

Notably, however, GL_DEPTH_COMPONENT16 does /not/ appear in table 3.16
or table 3.17.  It appears in table 3.18, where the "exact" rule doesn't
apply, and it falls back to the "closely as possible" rule.

The confusing part is that the ordering of the tables in the PDF is:

Table 3.16 (pages 182-184)
Table 3.18 (bottom of page 184 to top of 185)
Table 3.17 (page 185)

Presumably, people saw table 3.16, then saw the table immediately
following with DEPTH_COMPONENT* formats, and assumed it was 3.17.

Based on a patch by Chia-I Wu, but without the driconf option to force
Z16 to be used.  It's not required, and there's apparently no benefit
to actually using it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
glsl: Use M_PI_* macros.

Notice our multiple values for M_PI_2, which rounded ...32 up to
...4 and ...5.
i965/gs: Add dummy source to prepare_channel_masks instruction.

The generator uses its destination as a source implicitly, which breaks
some assumptions in dead code elimination. Giving the instruction a
source allows us to reason about it better.
i965/vec4: Let DCE eliminate dead writes in other basic blocks.

We previously stopped searching for unread writes after encountering
control flow, but we can instead just search backwards until we hit
control flow.

instructions in affected programs:     22854 -> 22194 (-2.89%)
i965/fs: Reimplement dead_code_elimination().

total instructions in shared programs: 1653399 -> 1651790 (-0.10%)
instructions in affected programs:     92157 -> 90548 (-1.75%)
GAINED:                                2
LOST:                                  2

Also significantly reduces the number of optimization loop iterations:

total loop iterations in shared programs: 39724 -> 31651 (-20.32%)
loop iterations in affected programs:     21617 -> 13544 (-37.35%)

Including some great pathological cases, like 29 -> 3 in Strike Suit
Zero and 24 -> 3 in Dota2.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/fs: Clear variable from live-set if it's completely overwritten.

One program affected:

instructions in affected programs:     246 -> 244 (-0.81%)

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/fs: Remove dead_code_eliminate_local().

Subsumed by the new dead_code_eliminate() function. No shader-db
changes.

Reviewed-by: Eric Anholt <eric@anholt.net>
dri: Expand driParseDebugString return value to uint64_t.

Users will downcast if they don't have >32 debug flags.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Expand INTEL_DEBUG to uint64_t.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Avoid dependency hints on math opcodes

  Putting NoDDClr and NoDDChk dependency control on instruction
sequences that include math opcodes can cause corruption of channels.
Treat math opcodes like send opcodes and suppress dependency hinting.

Signed-off-by: Mike Stroyan <mike@LunarG.com>
Tested-by: Tony Bertapelli <anthony.p.bertapelli@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
meta: Drop blit src size fallback.

I think we can assert that renderbuffer size is <= maximum 2D texture
size.  Our source coordinates should have already been clipped to the src
renderbuffer size, but haven't actually (so we could potentially have
trouble if there's scaling, and we're in the CopyTexImage path that tries
to use src size).  However, this texture size dependency was blocking the
next refactors, so I'm not sure if we want to go ahead with this series
before we get the clipping sorted out or not.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Refactor the BlitFramebuffer color CopyTexImage fallback.

There shouldn't be anything special about copying out a subset of the src
rb to a temp before texturing from it, so just do it when we're figuring
out our src texture binding.

This drops Anuj's change to copy an extra border of 1 pixel around the src
area.  I can't see how that change could be valid, and presumably if
there's some filtering problem at edges we just need to set the right
wrap mode.

v2: Don't fall back to swrast on non-2D/RECT/2D_MS textures when we can
    still CopyTexSubImage.  Fixes a segfault regression on i965 with
    gl-3.2-layered-rendering-blit.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1)
Tested-by: Anuj Phogat <anuj.phogat@gmail.com>
meta: Refactor the BlitFramebuffer depth CopyTexImage fallback.

This avoids a ReadPixels() if there's accelerated CopyTexImage present.
It now requires GLSL as opposed to just fragment programs, but we don't
have any drivers that do ARB_fp but not GLSL.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Move bind_fbo_image() code back to meta.c, to reuse it elsewhere.

I need to do the same code again for CopyTexSubImage().

v2: Drop incorrect, not-terribly-useful comment (review by Ken)

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v1)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Infer bind_fbo_image parameters from an incoming image.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Add support for CUBE_MAP_ARRAY to generatemipmap.

I added support to bind_fbo_image in the process of building meta
CopyTexSubImage, and found that it broke generatemipmap because previously
we would just throw a GL error there and then end up with an incomplete
FBO and fallback.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Add an accelerated glCopyTexSubImage using glBlitFramebuffer.

You'll note from the previous commits that there's something of a loop
here: You call CTSI, which calls BlitFB, then if things go wrong that
falls back to CTSI.  As a result, meta CTSI reaches over into blitfb to
tell it "no, don't try that fallback".

v2: Drop the _mesa_update_state(), which was only necessary due to use of
    _mesa_clip_blit() in _mesa_meta_BlitFramebuffer() in another patch
    series.
v3: Drop an _EXT suffix I copy-and-pasted.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (v2)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
meta: Add support for MSAA resolves from 2D_MS_ARRAY textures.

We don't have any piglit tests for this currently.

v2: Use vec3s for the texcoords so it has some hope of working.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>