llvmpipe: fix bug in early depth test / late depth write handling

Using wrong type if the format was less than 32bits.
No piglit changes as it doesn't hit that path.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: (trivial) remove confusing code in stencil test

This was meant to disable some code which isn't needed when depth/stencil
isn't written. However, there's more code which wouldn't be needed in that
case so having the condition there was just odd (llvm will drop all the code
anyway).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: fix issue with not writing new stencil values

We did mask checks between depth/stencil testing and depth/stencil write.
This meant that if the depth/stencil test killed off all fragments we never
actually wrote the new stencil value. This issue affected all early/late
test/write combinations.
So move the mask check after depth/stencil write (for early depth test,
could do the same for late depth test but might not be worth it at that
point so just skip it there).
This addresses https://bugs.freedesktop.org/show_bug.cgi?id=41787.
Piglit does not hit this issue because of the simple_shader optimization
in generate_fs_loop() which means we're skipping the mask checks.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: fix early depth test / late depth write stencil issues

We actually did early depth/stencil test and late depth/stencil write even
when the shader could kill the fragment (alpha test or discard). Since it
matters for the new stencil value if the fragment is killed by depth/stencil
test or by the shader (in which case it will not reach the depth/stencil
test) this simply cannot work (we also would possibly skip writing the new
stencil value due to mask checks but this is a secondary issue).
So use late depth test / late depth write instead in this case.
(No piglit changes as it doesn't seem to hit such bogus early depth test
/ late depth write path.)

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: disable simple_shader optimization

This optimization disabled mask checks if the shader is simple enough.
While this should work correctly, the problem is that it can hide real issues
because shaders in practice are usually complex enough (8 instructions or 1
texture is already enough) so this doesn't get used, whereas dumbed-down
tests which should hit all the same code paths suddenly do something quite
different. This was the reason that bug 41787 could not be easily tracked as
stencil test not working correctly (piglit would in fact have failed some
tests without that optimization).
So disable it for now, it's unclear if it's much of a win in any case.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
softpipe: disambiguate TILE_SIZE / TEX_TILE_SIZE

These can be different (just like NUM_TEX_TILE_ENTRIES / NUM_ENTRIES),
though currently they aren't.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
softpipe: change TEX_TILE_SIZE and NUM_TEX_TILE_ENTRIES

Initially we had NUM_TEX_TILE_ENTRIES of 50, however this was using too much
memory (mostly because the tile cache is operating on fixed max current
sampler views which could be fixed but that's another topic). So it was
decreased to 4. However this is a ridiculously low number which can't
actually really work (the number of tiles needed for as little as
a single quad with linear_mipmap_linear is 2 to 8 for a 2d texture, and
4 to 16 for a 3d texture), as it just about guarantees there will be
cache thrashing sometimes (just about always for 3d textures in fact, since
while there are 4 entries the cache is direct mapped).
So increase that number to 16 (which is still on the low side for direct
mapped cache though I guess using something like 4-way associativity would
be more effective than increasing this further) which has at least some good
chance to avoid thrashing. Since we don't want to increase memory requirements
however in turn decrease the tile size accordingly from 64 to 32 (as a bonus
point this also decreases the cost of texture thrashing which might still
happen sometimes).
I've seen performance improvement in the order of factor ~200 (specifically,
drawing the first frame from the replay from bug 41787 needs "only" ~10s
instead of ~30min, meaning I can actually compare the output with other
drivers...) with this.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
i965: Shut up more compiler warnings from vector insert/extract changes.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
intel: Count fragments in our blitter-based glBitmap() path.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59440
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
radeon: Initialize variables in radeon_llvm_context_init.

'type' was not fully initialized when calling lp_build_context_init.

Fixes "Uninitialized scalar variable" defect reported by Coverity.

NOTE: This is a candidate for the stable branches.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
ilo: Initialize need_flush in draw_vbo.

need_flush was uninitialized if hw3d->new_batch was true.

Fixes "Uninitialized scalar variable" defect reported by Coverity.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
ARB_fp: accept duplicate precision options

Relaxes the validation of

   OPTION ARB_precision_hint_{nicest,fastest};

to allow duplicate options. The spec says that both /nicest/ and
/fastest/ cannot be specified together, but could be interpreted
either way for respecification of the same option.

Other drivers (NVIDIA etc) accept this, and at least one Unity3D game
expects it to succeed (Kerbal Space Program).

V2: Add spec quote.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Enable guardband clipping on Gen4/5.

Enables guardband clipping when the viewport covers the entire render
target.

No piglit regressions on Ironlake.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Conditionally compile mcs-related code for i965 only.

This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field in the i915 driver).  This should make it a
bit easier to implement fast color clears without undue risk to i915.
intel: Create intel_miptree_get_region() to prepare for fast color clear.

With the advent of fast color clears, it will no longer be safe for
the driver to access the data stored in a miptree with impunity.  For
example, sometimes a resolve will need to be performed first (to
ensure that deferred writes due to a fast clear are performed before
the buffer is accessed).  Other times, fast clear will need to be
disabled for the miptree, so that its contents can be safely shared
with an entity that Mesa can't synchronize with easily.

To prepare for that, this patch renames intel_mipmap_tree::region to
intel_mipmap_tree::region_private and creates an accessor function,
intel_miptree_get_region().  At the moment, the accessor function
simply returns region_private.  Later in the patch series, this
function will be expanded to take appropriate actions to maintain the
proper fast color clear state.

As much as possible, I've tried to restrict the functions which
directly access region_private to low-level miptree functions
(e.g. miptree initialization functions), so that it will be easy to
verify that those functions access the miptree contents safely.
i965/gen7+: Create an enum for keeping track of fast color clear state.

This patch includes code to update the fast color clear state
appropriately when rendering occurs.  The state will also need to be
updated when a fast clear or a resolve operation is performed; those
state updates will be added when the fast clear and resolve operations
are added.
i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.

On Gen7+, MCS buffers are used both for compressed multisampled color
buffers and for "fast clear" of single-sampled color buffers.

Previous to this patch series, we didn't support fast clear, so we
only used MCS with multisampled bolor buffers.

As a first step to implementing fast clears, this patch modifies the
code that sets up SURFACE_STATE so that it configures the MCS buffer
whenever it is present, regardless of whether we are multisampling or
not.
i965/gen7+: Create helper functions for single-sample MCS buffers.
i965/gen7+: Implement fast color clear operation in BLORP.

Since we defer allocation of the MCS miptree until the time of the
fast clear operation, this patch also implements creation of the MCS
miptree.

In addition, this patch adds the field
intel_mipmap_tree::fast_clear_color_value, which holds the most recent
fast color clear value, if any. We use it to set the SURFACE_STATE's
clear color for render targets.

v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree.
i965/blorp: Expand clear class hierarchy to prepare for RT resolves.

The fragment shaders that to do color clears will be re-used to
perform so-called "render target resolves" (the resolves associated
with fast color clears).  To prepare for that, this patch expands the
class hierarchy for blorp params by adding
brw_blorp_const_color_params (which will be used for all blorp
operations where the fragment shader outputs a constant color).

Some other data structures and functions were also renamed to use
"const_color" nomenclature where appropriate.