util: add more memory debugging features

Add a DEBUG_FREED_MEMORY option to help catch use-after-free errors.
Add debug_memory_check() function which can be periodically called to
check that all known blocks are good.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
configure.ac: print LLVM flags

to see what we're mixing with ours

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
configure.ac: consolidate stripping unwanted LLVM flags

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
configure.ac: look for whole words in LLVM flags, not prefixes

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
configure.ac: remove -fomit-frame-pointer from LLVM flags

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
st/mesa: add support for GL core profiles

The rest of the plumbing was in place already.

I have tested this by turning on all GL 3.1 features.
The drivers not supporting GL 3.1 will fail to create a core profile
as they should.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
st/mesa: allow forward-compatible contexts and set Const.ContextFlags

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
docs: Mark some features in GL3.txt as done for r600

Signed-off-by: Marek Olšák <maraeo@gmail.com>
meta: Don't try to glOrtho when the draw buffer isn't initialized.

I ran across this while running a glGenerateMipmap() test.

_meta_GenerateMipmap sets MESA_META_TRANSFORM, which causes
_mesa_meta_begin to try and set a default orthographic projection.

Unfortunately, if the drawbuffer isn't set up, ctx->DrawBuffer->Width
and Height are 0, which just causes an GL_INVALID_VALUE error.

Fixes oglconform's fbo/mipmap.automatic, mipmap.manual, and
mipmap.manualIterateTexTargets.

Reviewed-by: Brian Paul <brianp@vmware.com>
i965/vs: Move some functions from brw_vec4_emit.cpp to brw_vec4.cpp.

This leaves only the final code generation stage in brw_vec4_emit.cpp,
moving the payload setup, run(), and brw_vs_emit functions to brw_vec4.cpp.

The fragment shader backend puts these functions in brw_fs.cpp, so this
patch also helps with consistency.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Pass the brw_context pointer into vec4_visitor and do_vs_prog.

We used to steal it out of the brw_compile struct...but vec4_visitor
isn't going to have one of those in the future.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Pass the brw_context pointer into brw_compute_vue_map().

We used to steal it out of the brw_compile struct, but that won't be
initialized in time soon (and is eventually going away).

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Rework memory contexts for shader compilation data.

During compilation, we allocate a bunch of things: the IR needs to last
at least until code generation...and then the program store needs to
last until after we upload the program.

For simplicity's sake, just keep it all around until we upload the
program.  After that, it can all be freed.

This will also save a lot of headaches during the upcoming refactoring.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Move uses of brw_compile from do_vs_prog to brw_vs_emit.

The brw_compile structure is closely tied to the Gen4-7 hardware
encoding.  However, do_vs_prog is very generic: it just calls out to
get a compiled program and then uploads it.

This isn't ultimately where we want it, but it's a step in the right
direction: it's now closer to the code generator.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Abort on unsupported opcodes rather than failing.

Final code generation should never fail.  This is a bug, and there
should be no user-triggerable cases where this could occur.

Also, we're not going to have a fail() method after the split.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Split final assembly code generation out of vec4_visitor.

Compiling shaders requires several main steps:

   1. Generating VS IR from either GLSL IR or Mesa IR
   2. Optimizing the IR
   3. Register allocation
   4. Generating assembly code

This patch splits out step 4 into a separate class named "vec4_generator."

There are several reasons for doing so:

   1. Future hardware has a different instruction encoding.  Splitting
      this out will allow us to replace vec4_generator (which relies
      heavily on the brw_eu_emit.c code and struct brw_instruction) with
      a new code generator that writes the new format.

   2. It reduces the size of the vec4_visitor monolith.  (Arguably, a lot
      more should be split out, but that's left for "future work.")

   3. Separate namespaces allow us to make helper functions for
      generating instructions in both classes: ADD() can exist in
      vec4_visitor and create IR, while ADD() in vec4_generator() can
      create brw_instructions.  (Patches for this upcoming.)

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
i965/vs: Move struct brw_compile (p) entirely inside vec4_generator.

The brw_compile structure contains the brw_instruction store and the
brw_eu_emit.c state tracking fields.  These are only useful for the
final assembly generation pass; the earlier compilation stages doesn't
need them.

This also means that the code generator for future hardware won't have
access to the brw_compile structure, which is extremely desirable
because it prevents accidental generation of Gen4-7 code.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
radeonsi: Bitcast result of packf16 intrinsic to float for export intrinsic.

Fixes 7 piglit tests, and prevents many more from crashing.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-and-Tested-by: Christian König <christian.koenig@amd.com>
gallivm: Altivec pack/unpack intrisics

This patch adds PPC Altivec support for pack/unpack operations using Altivec
supported vector type (8xi8, 16xi16, 4xi32, 4xf32).

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
gallivm: Altivec vector max/min intrisics

This patch adds the PPC Altivec instrics max/min instruction for
supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32).

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>