i965: Create drm_intel_bo_map wrappers with performance warnings.

Mapping a buffer is a common place where we could stall the CPU.

In a few places, we've added special code to check whether a buffer is
busy and log the stall as a performance warning.  Most of these give no
indication of the severity of the stall, though, since measuring the
time is a small hassle.

This patch introduces a new brw_bo_map() function which wraps
drm_intel_bo_map, but additionally measures the time stalled and reports
a performance warning.  If performance debugging is not enabled, it
simply maps the buffer with negligable overhead.

We also add a similar wrapper for drm_intel_gem_bo_map_gtt().

This should make it easy to add performance warnings in lots of places.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Use brw_bo_map() in intel_texsubimage_tiled_memcpy().

This additionally measures the time stalled, while also simplifying the
code.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Use brw_bo_map[_gtt]() in intel_miptree_map_raw().

This moves the intel_batchbuffer_flush before the drm_intel_bo_busy
call, which is a change in behavior.  However, the old behavior was
broken.

In the future, we may want to only flush in the batchbuffer references
the BO being mapped.  That's certainly more typical.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
radeon/uvd: fix feedback buffer handling v2

Without the correct feedback buffer size UVD runs
into an error on each frame, reducing the maximum FPS.

v2: fixing Michels comments

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Cc: "10.1" "10.0" "9.2" <mesa-stable@lists.freedesktop.org>
i965/blorp: do not use unnecessary hw-blending support

This is really not needed as blorp blit programs already sample
XRGB normally and get alpha channel set to 1.0 automatically by
the sampler engine. This is simply copied directly to the payload
of the render target write message and hence there is no need for
any additional blending support from the pixel processing pipeline.

The blending formula is anyway broken for color components, it
multiplies the color component with itself (blend factor is the
component itself).
Alpha blending in turn would not fix the alpha to one independent
of the source but simply used the source alpha as is instead
(1.0 * src_alpha + 0.0 * dst_alpha).

Quoting Eric:

 "If we want to actually make the no-alpha-bits-present thing work,
  we need to override the bits in the surface state or in the
  generated code.  In the normal draw path, it's done for sampling
  by the swizzling code in brw_wm_surface_state.c, and the blending
  overrides is just to fix up the alpha blending stage which
  doesn't pay attention to that for the destination surface."

If one modifies piglit test gl-3.2-layered-rendering-blit to use
color component values other than zero or one, this change will
kick in on IVB. No regressions on IVB.

This is effectively revert of c0554141a9b831b4e614747104dcbbe0fe489b9d:

    i965/blorp: Support overriding destination alpha to 1.0.

    Currently, Blorp requires the source and destination formats to be
    equal.  However, we'd really like to be able to blit between XRGB and
    ARGB formats; our BLT engine paths have supported this for a long time.

    For ARGB -> XRGB, nothing needs to occur: the missing alpha is already
    interpreted as 1.0.  For XRGB -> ARGB, we need to smash the alpha
    channel to 1.0 when writing the destination colors.  This is fairly
    straightforward with blending.

    For now, this code is never used, as the source and destination formats
    still must be equal.  The next patch will relax that restriction.

    NOTE: This is a candidate for the 9.1 branch.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
glsl: Make condition_to_hir() callable from outside ast_iteration_statement.

In addition to making it public, we also need to change its first
argument from an ir_loop * to an exec_list *, so that it can be used
to insert the condition anywhere in the IR (rather than just in the
body of the loop).

This will be necessary in order to make continue statements work
properly in do-while loops.

Cc: mesa-stable@lists.freedesktop.org

Acked-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
glsl: Fix continue statements in do-while loops.

From the GLSL 4.40 spec, section 6.4 (Jumps):

    The continue jump is used only in loops. It skips the remainder of
    the body of the inner most loop of which it is inside. For while
    and do-while loops, this jump is to the next evaluation of the
    loop condition-expression from which the loop continues as
    previously defined.

Previously, we incorrectly treated a "continue" statement as jumping
to the top of a do-while loop.

This patch fixes the problem by replicating the loop condition when
converting the "continue" statement to IR.  (We already do a similar
thing in "for" loops, to ensure that "continue" causes the loop
expression to be executed).

Fixes piglit tests:
- glsl-fs-continue-inside-do-while.shader_test
- glsl-vs-continue-inside-do-while.shader_test
- glsl-fs-continue-in-switch-in-do-while.shader_test
- glsl-vs-continue-in-switch-in-do-while.shader_test

Cc: mesa-stable@lists.freedesktop.org

Acked-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa: remove stray bits of GL_EXT_cull_vertex

GL_EXT_cull_vertex was removed back in 2010 in commit 02984e3536
but these bits still lingered.

Reviewed-by: Eric Anholt <eric@anholt.net>
gallium: remove PIPE_CAP_MAX_COMBINED_SAMPLERS

This can be derived from the shader caps.

All GPUs from ATI/AMD, NVIDIA, and INTEL have separate texture slots
for each shader stage.
r600g,radeonsi: treat DYNAMIC and STREAM usage as STAGING
r600g,radeonsi: skip busy-checking for DISCARD_RANGE if it has been done already
r600g,radeonsi: skip unnecessary buffer_is_busy call, add a comment
r600g: split streamout emit code into a separate function

For geometry shaders we need to call this code from a second place.

Just move it out for now to keep future patches cleaner.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
r600g: move barrier and end_of_program bits from output to cf struct (v2)

v2: fix regression on r600 NOP instructions.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
r600g/bc: add support for indexed memory writes.

It looks like we need these for geom shaders in the future.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: defer shader variant selection and depending state updates

[airlied: fix dropped streamout line - fix for master]

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: add hw register definitions for GS block setup

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: initial support for geometry shaders on evergreen (v2)

This is Vadim's initial work with a few regression fixes squashed in.

v2: (airlied)
fix regression in glsl-max-varyings - need to use vs and ps_dirty
fix regression in shader exports from rebasing.
whitespace fixing.
v2.1: squash fix assert

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: don't fail if we can't map VS->GS ring entries

This can happen in normal operation, so don't report an error on it,
just continue.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g/sb: add MEM_RING support

Although we don't use SB on geom shaders, the VS copy shader will use it
so we might as well implement MEM_RING support in sb.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>