st/egl: flush resources before presentation

Fixes regression on r600g due to fast clear introduced by commit
edbbfac6.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
mesa: Fix misplaced includes of "main/uniforms.h".

Several C++ source files include "main/uniforms.h" from an extern "C"
block, which is both unnecessary, because "uniforms.h" already checks
for a C++ compiler and sets the right linkage, and incorrect, because
the header file includes other C++ headers ("glsl_types.h" and
"ir_uniform.h") that are supposed to get C++ linkage.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
glsl: Initialize all member variables of _mesa_glsl_parse_state on construction.

The _mesa_glsl_parse_state object relies on the memory allocator
zeroing out its contents before it's initialized, which is quite an
unusual practice in the C++ world because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind.  Initialize all fields
from the constructor and stop using the zeroing allocator.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Initialize all member variables of vec4_instruction on construction.

The vec4_instruction object relies on the memory allocator zeroing out
its contents before it's initialized, which is quite an unusual
practice in the C++ world because it ties objects to some specific
allocation scheme, and gives unpredictable results when an object is
created with a different allocator -- Stack allocation, array
allocation, or aggregation inside a different object are some of the
useful possibilities that come to my mind.  Initialize all fields from
the constructor and stop using the zeroing allocator.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Switch ast_node to the non-zeroing allocator.

All member variables of ast_node are already being initialized from
its constructor, but some of its derived classes were leaving members
uninitialized -- Fix them.

Using rzalloc makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables.  That's bad because it ties objects to some
specific allocation scheme, and gives unpredictable results when an
object is created with a different allocator -- Stack allocation,
array allocation, or aggregation inside a different object are some of
the useful possibilities that come to my mind.

v2: Use NULL initialization instead of default construction for pointers.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Switch ast_type_qualifier to the non-zeroing allocator.

All member variables of ast_type_qualifier are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Initialize all member variables of bblock_t on construction.

The bblock_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.  Initialize all fields from the
constructor and stop using the zeroing allocator.

v2: Use zero initialization for numeric types instead of default construction.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Initialize all member variables of cfg_t on construction.

The cfg_t object relies on the memory allocator zeroing out its
contents before it's initialized, which is quite an unusual practice
in the C++ world because it ties objects to some specific allocation
scheme, and gives unpredictable results when an object is created with
a different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.  Initialize all fields from the
constructor and stop using the zeroing allocator.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Switch ip_record to the non-zeroing allocator.

All member variables of ip_record are already being initialized from
its constructor, it's not necessary to use rzalloc to allocate its
memory, and doing so makes it more likely that we will start relying
on the allocator to zero out all memory if the class is ever extended
with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Switch fs_inst to the non-zeroing allocator.

All member variables of fs_inst are already being initialized from its
constructor, it's not necessary to use rzalloc to allocate its memory,
and doing so makes it more likely that we will start relying on the
allocator to zero out all memory if the class is ever extended with
new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Switch fs_live_variables to the non-zeroing allocator.

All member variables of fs_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Switch vec4_live_variables to the non-zeroing allocator.

All member variables of vec4_live_variables are already being
initialized from its constructor, it's not necessary to use rzalloc to
allocate its memory, and doing so makes it more likely that we will
start relying on the allocator to zero out all memory if the class is
ever extended with new member variables.

That's bad because it ties objects to some specific allocation scheme,
and gives unpredictable results when an object is created with a
different allocator -- Stack allocation, array allocation, or
aggregation inside a different object are some of the useful
possibilities that come to my mind.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa/program: Switch ir_to_mesa_instruction to the non-zeroing allocator.

All member variables of ir_to_mesa_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
st/mesa: Switch glsl_to_tgsi_instruction to the non-zeroing allocator.

All member variables of glsl_to_tgsi_instruction are already being
initialized from its implicitly defined constructor, it's not
necessary to use rzalloc to allocate its memory.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ralloc: Remove the rzalloc-based new/delete operator definition macro.

Using it encourages the (IMHO worrying) practice of leaving member
variables uninitialized in constructor definitions.  This macro
shouldn't be necessary anymore after the last patch series fixing all
its users to initialize all member variables from the class
constructor.  Remove it.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/blorp: Use passed in framebuffer rather than ctx->DrawBuffer

We have the destination framebuffer object passed in; there's no need to
go digging around in the context.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: compute DDX in a subspan based only on top row

Consider only the top-left and top-right pixels to approximate DDX in a 2x2
subspan, unless the application requests a more accurate approximation via
GL_FRAGMENT_SHADER_DERIVATIVE_HINT or this optimization is disabled from the
new driconf option disable_derivative_optimization.

This results in a less accurate approximation.  However, it improves the
performance of Xonotic with Ultra settings by 24.3879% +/- 0.832202% (at 95.0%
confidence) on Haswell.  No noticeable image quality difference observed.

The improvement comes from faster sample_d.  It seems, on Haswell, some
optimizations are introduced to allow faster sample_d when all pixels in a
subspan have the same derivative.  I considered SAMPLE_STATE too, which allows
one to control the quality of sample_d on Haswell.  But it gave much worse
image quality without giving better performance comparing to this change.

No piglit quick.tests regression on Haswell (tested with v1).

v2: better guess for precompile program key

Signed-off-by: Chia-I Wu <olv@lunarg.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
r600g/llvm: fix txq for texture buffer
r600g/llvm: Undef z and w component of 2D TXP inst
r600/llvm: Adds support for MSAA