[Bug 93435] [HSW bisected] Render error when running Unigine-Heave_v4.0

[bugzilla-daemon at freedesktop.org]

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

Kenneth Graunke <kenneth at whitecape.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #3 from Kenneth Graunke <kenneth at whitecape.org> ---
I later reverted that workaround and did a better one that lets it actually use
dual color blending:

commit b3340cd32acf5935891f19833de0cfc500a93e0b
Author: Kenneth Graunke <kenneth at whitecape.org>
Date:   Wed Jan 20 17:33:14 2016 -0800

    i965: Implement a drirc workaround for broken dual color blending.

    OpenGL's dual color blending feature was specified so that an
    implementation could support both multiple render targets (MRT) and
    dual source blending.  Fragment shader outputs specify both "location"
    (the render target number) and "index" (either color 0 or 1).

    I believe DirectX only has the notion of "location" - if using dual
    color blending, location 0 or 1 will specify the operands.  If not,
    then location means the render target index.  The two features can't
    be used together.

    As such, some applications mistakenly try to use <loc = 0, index = 0>
    and <loc = 1, index = 0> in a shader used for dual color blending with
    a single render target, rather than the correct <loc = 0, index = 0>
    and <loc = 0, index = 1>.

    In particular, Unigine Heaven 4.0 and Valley 1.0 suffer from this bug.
    Unigine is aware of the problem, and quickly developed a fix, but has
    not bothered to change the download link on their website to a working
    copy in over a year.  People were still using the broken version and
    complaining.  We tried working around this by disabling dual color
    blending, but that apparently hurts performance, and people were once
    again unhappy.

    On i965, dual source blending is achieved by using different framebuffer
    write messages than normal rendering.  So, we have to compile different
    code for the two cases.  We're not being pedantic: we actually have to
    know in order to function.

    Normally, dual source blending is detectable in the shader: if a shader
    has an output with index = 1, then it's meant for blending, not MRT.
    With the broken inputs, they're indistinguishable, so we can only tell
    by looking at the current GL state.

    This patch implements a new drirc workaround:

       export dual_color_blend_by_location=true

    which makes the i965 driver detect when OpenGL state is configured for
    dual source blending, and recompile the fragment shader to use the right
    messages.  In that case, we allow either location = 1 or index = 1 to
    specify the second source for the blending equations.

    It also re-enables GL_ARB_blend_func_extended for Unigine.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92233
    Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
    Reviewed-by: Marek Olšák <marek.olsak at amd.com>
    Reviewed-by: Iago Toral Quiroga <itoral at igalia.com>
    Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
    Acked-by: Ilia Mirkin <imirkin at alum.mit.edu>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160206/ce723a2b/attachment.html>