[Mesa-dev] [Bug 70009] [bisected] some wine apps renders black

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Oct 1 10:17:37 PDT 2013


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

Pavel Ondračka <pavel.ondracka at email.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[bisected] some apps wine   |[bisected] some wine apps
                   |apps renders black          |renders black
           Keywords|                            |regression

--- Comment #1 from Pavel Ondračka <pavel.ondracka at email.cz> ---
First apology for accidentally pushing Enter too early.

Now to the bug... Wine is known to produce some invalid shaders on old cards.
(see bug 42514 or http://bugs.winehq.org/show_bug.cgi?id=29146)  This is
because wine need some uniform components for internal fixups and when the
shader already uses all of them, it generates incorrect shaders. On my old
RV530 with r300g driver this usually resulted in using dummy shader instead of
the failing one (and hence missing some game object or effects), however except
from the few missing things, the apps were mostly working fine.

However, starting with 6a2baf3a06125405aa648e208af782e53f1312c0 , there is
major random color corruption in affected apps (specifically this was tested
with EVE online).

6a2baf3a06125405aa648e208af782e53f1312c0 is the first bad commit
commit 6a2baf3a06125405aa648e208af782e53f1312c0
Author: Paul Berry <stereotype441 at gmail.com>
Date:   Mon Jun 10 14:01:45 2013 -0700

    glsl/linker: Make update_array_sizes apply to just uniforms.

    Commit 586b4b5 (glsl: Also update implicit sizes of varyings at link
    time) extended update_array_sizes() to apply to both uniforms and
    shader ins/outs.  However, doing creates problems for geometry
    shaders, because update_array_sizes() assumes that variables with
    matching names in different parts of the pipeline should have the same
    sizes.  With the addition of geometry shaders, this is no longer true
    (e.g. both vertex and geometry shaders have a gl_ClipDistance output
    variable, but there's no reason these variables should have the same
    sizes).

    The original reason for commit 586b4b5 (avoid problems with
    gl_TexCoord being 0 length) has since been addressed by commit 6f53921
    (linker: Ensure that unsized arrays have a size after linking).  So go
    ahead and switch update_array_sizes() back to only acting on uniforms.

    Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>


After commit 98d2498404ba69a3efc1c765b1a1885d151181ed it changed to mostly
black

98d2498404ba69a3efc1c765b1a1885d151181ed is the first bad commit
commit 98d2498404ba69a3efc1c765b1a1885d151181ed
Author: Paul Berry <stereotype441 at gmail.com>
Date:   Fri Aug 9 07:58:43 2013 -0700

    glsl: Fix incorrect pattern matching in ir_set_program_inouts

    In commit 8fc41df (glsl: Modify ir_set_program_inouts to handle
    geometry shaders), when attempting to pattern match the "foo" part of
    expressions such as:

       foo[i][j]
       foo[i]

    I incorrectly called as_dereference_variable() on the subexpression
    foo[i] instead of foo.  As a result, the pattern never matched, so
    ir_set_program_inouts would fall back on marking the entire variable
    as used, rather than just the portion indexed by the array.

    This didn't result in incorrect behaviour, but it could have resulted
    in inefficiency by causing the back-end to allocate resources for
    unused parts of an input or output array.

    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

It would be nice if we could go back to the status before, eg. "ignoring the
bad shaders" and rendering everything else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131001/23bc49f6/attachment.html>


More information about the mesa-dev mailing list