i965/gen6/blorp: Set need_workaround_flush immediately after primitive

This patch makes the workaround code in gen6 blorp follow the pattern
established in the regular draw path. It shouldn't result in any
behavioral change.

On gen6, there are two places where we emit 3D_CMD_PRIM: brw_emit_prim()
and gen6_blorp_emit_primitive().  brw_emit_prim() sets
need_workaround_flush immediately after emitting the primitive, but
blorp does not. Blorp sets need_workaround_flush at the bottom of
brw_blorp_exec().

This patch moves the need_workaround_flush from brw_blorp_exec() to
gen6_blorp_emit_primitive().  There is no need to set
need_workaround_flush in gen7_blorp_emit_primitive() because the
workaround applies only to gen6.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
i965/gen6/blorp: Set need_workaround_flush at top of blorp

Unconditionally set brw->need_workaround_flush at the top of gen6 blorp
state emission.

The art of emitting workaround flushes on Sandybridge is mysterious and
not fully understood. Ken and I believe that
intel_emit_post_sync_nonzero_flush() may be required when switching from
regular drawing to blorp.  This is an extra safety measure to prevent
undiscovered difficult-to-diagnose gpu hangs.

I verified that on ChromeOS, pre-patch, need_workaround_flush was not
set at the top of blorp, as Paul expected. To verify, I inserted the
following debug code at the top of gen6_blorp_exec(), restarted the ui,
and inspected the logs in /var/log/ui. The abort gets triggered so early
that the browser never appears on the display.

    static void
    gen6_blorp_exec(...)
    {
        if (!brw->need_workaround_flush) {
            fprintf(stderr, "chadv: %s:%d\n", __FILE__, __LINE__);
            abort();
        }
        ...
    }

CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
i965/gen6/blorp: Remove redundant HiZ workaround

Commit 1a92881 added extra flushes to fix a HiZ hang in
WebGL Google Maps. With the extra flushes emitted by the previous two
patches, the flushes added by 1a92881 are redundant.

Tested with the same criteria as in 1a92881: by zooming in and out
continuously for 2 hours on Sandybridge Chrome OS (codename
Stumpy) without a hang.

CC: Kenneth Graunke <kenneth@whitecape.org>
CC: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
main: check texture target when validating layered framebuffers.

From section 4.4.4 (Framebuffer Completeness) of the GL 3.2 spec:

    If any framebuffer attachment is layered, all populated
    attachments must be layered. Additionally, all populated color
    attachments must be from textures of the same target.

We weren't checking that the attachments were from textures of the
same target.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Fix clears of layered framebuffers with mismatched layer counts.

Previously, Mesa enforced the following rule (from
ARB_geometry_shader4's list of criteria for framebuffer completeness):

  * If any framebuffer attachment is layered, all attachments must have
    the same layer count.  For three-dimensional textures, the layer count
    is the depth of the attached volume.  For cube map textures, the layer
    count is always six.  For one- and two-dimensional array textures, the
    layer count is simply the number of layers in the array texture.
    { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }

However, when ARB_geometry_shader4 was adopted into GL 3.2, this rule
was dropped; GL 3.2 permits different attachments to have different
layer counts.  This patch brings Mesa in line with GL 3.2.

In order to ensure that layered clears properly clear all layers, we
now have to keep track of the maximum number of layers in a layered
framebuffer.

Fixes the following piglit tests in spec/!OpenGL 3.2/layered-rendering:
- clear-color-all-types 1d_array mipmapped
- clear-color-all-types 1d_array single_level
- clear-color-mismatched-layer-count
- framebuffer-layer-count-mismatch

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Delete duplicate write_timestamp function.

brw_queryobj.c needs a version of write_timestamp that works on all
generations for the QueryCounter() driver hook.  So there's no point in
duplicating it in gen6_queryobj.c.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Set the correct error in _mesa_BeginConditionalRender

Piglit was recently changed to expect the correct error code (piglit
commit 271b998), so it started failing on Mesa.  This corrects that
failing and adds some spec quotations to justify the errrors set.

The code was rearranged a little bit to match the order listed in the
spec.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
egl_dri2: call dri2_add_configs_for_visuals after extensions set

dri2_add_config makes decisions based on NOK_texture_from_pixmap so
it needs to be enabled before calling dri2_add_configs_for_visuals.

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
dri: set yInverted default to GL_TRUE

yInverted is used by EGL_NOK_texture_from_pixmap to indicate that
window system rendering is y-inverted compared to OpenGL texture
representation. This extension is only known to be used with X11
window system where sane default is GL_TRUE.

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

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
st/egl: Flush resources before presentation

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

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
st/mesa: always prefer pipe->clear over clear_with_quad (v2)

v2: clear depth and stencil together
st/mesa: check depth and stencil writemask before clearing
st/mesa: use sRGB formats for MSAA resolving if destination is sRGB

Copied from the i965 driver, including the big comment.

Cc: 9.2 10.0 <mesa-stable@lists.freedesktop.org>
mesa: handle GL_NONE draw buffers correctly in glClear

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: bind NULL colorbuffers as specified by glDrawBuffers

An example why it is required:

    Let's say there's a fragment shader writing to gl_FragData[0..1].
    The user calls: glDrawBuffers(2, {GL_NONE, GL_COLOR_ATTACHMENT0});

    That means gl_FragData[0] is unused and gl_FragData[1] is written
    to GL_COLOR_ATTACHMENT0.

st/mesa was skipping the GL_NONE draw buffer, therefore gl_FragData[0]
was written to GL_COLOR_ATTACHMENT0, which was wrong.

This commit fixes it, but drivers must also be fixed not to crash when
binding NULL colorbuffers. There is also a new set of piglit tests for this.

The MSAA state also had to be fixed not to crash when reading fb->cbufs[0].

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium/util: easy fixes for NULL colorbuffers

Reviewed-by: Brian Paul <brianp@vmware.com>
radeonsi: handle NULL colorbuffers correctly

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
r600g: handle NULL colorbuffers correctly on Evergreen
r600g: handle NULL colorbuffers correctly on R600-R700
r600g: fix glClearBuffer by handling PIPE_CLEAR_COLORi flags correctly

also restructure the code