Squashed commit of the following:

commit 04c5fa2cbb
Author: José Fonseca <jfonseca@vmware.com>
Date:   Tue Apr 23 17:37:18 2013 +0100

    gallium: s/lower_left_origin/bottom_edge_rule/

commit 4dff4f64fa
Author: José Fonseca <jfonseca@vmware.com>
Date:   Tue Apr 23 17:35:04 2013 +0100

    gallium: Move diagram to docs.

commit 442a63012c
Author: James Benton <jbenton@vmware.com>
Date:   Fri May 11 17:50:55 2012 +0100

    gallium: Replace gl_rasterization_rules with lower_left_origin and half_pixel_center.

    This change is necessary to achieve correct results when using OpenGL
    FBOs.

Reviewed-by: Marek Olšák <maraeo@gmail.com>

This fixes a crash when a resource cannot be mapped to the CPU's address space
because it's too big.

This puts a global pipe_context in r600_screen, which is guarded by a mutex,
so that we can use pipe_context when there isn't one around.
Hopefully our multi-context support is solid.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

NOTE: This is a candidate for the 9.1 branch.

Same approach as in the llvmpipe, if the geometry shader is
null and we have stream output then attach it to the vertex
shader right before executing the draw pipeline.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>

Because we don't support, and the u_format fallback doesn't work for
zs formats.

Reviewed-by: Brian Paul <brianp@vmware.com>

Prevents assertion failures inside the driver for such state combinations.

Reviewed-by: Brian Paul <brianp@vmware.com>

There will be a new IR for a3xx, which has a very different shader ISA
(more scalar oriented).  So rename to avoid conflicts later when I start
adding a3xx support to the gallium driver.

Signed-off-by: Rob Clark <Rob Clark robdclark@freedesktop.org>

The standalone shader assembler needed some meta-data to know about
attributes/varyings/etc, to do the shader linkage.  We don't need these
parts with gallium/tgsi, so just get rid of it.

Signed-off-by: Rob Clark <Rob Clark robdclark@freedesktop.org>

While initially that opcode probably was meant for something along the
lines of sm3 break_comp it has never worked that way (not even the
argument count was right) and now the opcode has quite different
semantics so just remove it. (Discovered by Jose Fonseca)

Most test pass, issue are with border color and swizzle.

Based on ircnick<maelcum> patch.

v2: Restaged commit hunk

Signed-off-by: Jerome Glisse <jglisse@redhat.com>

v2: Remove left over code
v3: Restage properly the commit so hunk of first one are not in
    second one.

Signed-off-by: Jerome Glisse <jglisse@redhat.com>

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>

Not all are supported as render targets.

The state tracker fallback of using RGBA instead of RGBX currently
fails for blending, we could work around this by clearing their alpha
to 1 and modifying the color mask to disable writing alpha.

This is the only sane solution for nv50 and nvc0 (really, trust me),
but since on other hardware the border colour is tightly coupled with
texture state they'd have to undo the swizzle, so I've added a cap.

The dependency of update_sampler on the texture updates was
introduced to avoid doing the apply_depthmode to the swizzle twice.

v2: Moved swizzling helper to u_format.c, extended the CAP to
provide more accurate information.

Tested with graw/fs-fragcoord 2/3, and piglit
glsl-arb-fragment-coord-conventions.

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

No longer used.

If we ever want the old behavior we can run a loop unroller pass.

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

Never used.

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

We were trying to use a destroy method from a deleted context.
This fix is based on what's in the svga driver.

Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

we were using the wrong vars, reporting incorrect stream output
statistics.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

This is a basic implementation of the pipeline statistics in the
draw module. The interface is similar to the stream output statistics
and also requires that the callers explicitly enable it.
Included is the implementation of the interface in llvmpipe and
softpipe. Only softpipe enables the pipeline statistics capability
though because llvmpipe is lacking gathering of the fragment shading
and rasterization statistics.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>

TGSI_OPCODE_IF condition had two possible interpretations:

- src.x != 0.0f

  - Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was false either for
    vertex and fragment shaders
  - gallivm/llvmpipe
  - postprocess
  - vl state tracker
  - vega state tracker
  - most old drivers
  - old internal state trackers
  - many graw examples

- src.x != 0U

  - Mesa statetracker when PIPE_SHADER_CAP_INTEGERS was true for both
    vertex and fragment shaders
  - tgsi_exec/softpipe
  - r600
  - radeonsi
  - nv50

And drivers that use draw module also were a mess (because Mesa would
emit float IFs, but draw module supports native integers so it would
interpret IF arg as integers...)

This sort of works if the source argument is limited to float +0.0f or
+1.0f, integer 0, but would fail if source is float -0.0f, or integer in
the float NaN range.  It could also fail if source is integer 1, and
hardware flushes denormalized numbers to zero.

But with this change there are now two opcodes, IF and UIF, with clear
meaning.

Drivers that do not support native integers do not need to worry about
UIF.  However, for backwards compatibility with old state trackers and
examples, it is advisable that native integer capable drivers also
support the float IF opcode.

I tried to implement this for r600 and radeonsi based on the surrounding
code.  I couldn't do this for nouveau, so I just shunted IF/UIF
together, which matches the current behavior.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>

v2:
- Incorporate Roland's feedback.
- Fix r600_shader.c merge conflict.
- Fix typo in radeon, spotted by Michel Dänzer.
- Incorporte  Christoph Bumiller's patch to handle TGSI_OPCODE_IF(float)
  properly in nv50/ir.

Never used or implemented.

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

Set transfer flag instead of fiddling with the tilling params directly.

Signed-off-by: Christian König <christian.koenig@amd.com>

There is a hardware bug on Cayman where a BREAK/CONTINUE followed by
LOOP_STARTxxx for nested loops may put the branch stack into a state
such that ALU_PUSH_BEFORE doesn't work as expected. Workaround this
by replacing the ALU_PUSH_BEFORE with a PUSH + ALU

Fixes piglit tests EXT_transform_feedback/order*

v2: Use existing loop count and improve comment
v3: [Vadim Girlin] Set jump address for PUSH instructions

NOTE: This is a candidate for the 9.1 branch

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-and-Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

Instead of emitting configuration values (e.g. number of gprs used) in a
predefined order, the LLVM backend now emits these values in
register/value pairs.  The first dword contains the register address and
the second dword contians the value to write.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

https://bugs.freedesktop.org/show_bug.cgi?id=60503

NOTE: This is a candidate for the stable branches.

Pointed out by gcc

nve4_compute.c: In function 'nve4_launch_grid':
nve4_compute.c:511:7: warning: 'ret' may be used uninitialized in
 this function [-Wmaybe-uninitialized]
    if (ret)
       ^

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

Edit by Christoph Bumiller:
Set it to -1 to indicate failure and only when it's actually required.

Exit gracefully rather than trying to create a random object, whenever the
chipset is unknown

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

As otherwise it is unused - pointed out by gcc

nve4_compute.c:586:20: warning: 'nve4_cache_split_name' defined but not used [-Wunused-function]
 static const char *nve4_cache_split_name(unsigned value)
                    ^

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

For debug build we'll hit the assert, for release we are going to emit random data
as subOp is used uninitilised. Spotted by gcc

codegen/nv50_ir_emit_nv50.cpp: In member function 'void nv50_ir::CodeEmitterNV50::emitATOM(const nv50_ir::Instruction*)':
codegen/nv50_ir_emit_nv50.cpp:1554:12: warning: 'subOp' may be used uninitialized in this function [-Wmaybe-uninitialized]
    uint8_t subOp;
            ^

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

Hackishly fixes alignment requirement of 2nd tuple for now.