<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Adding a single-iteration do-while loop in a GLSL shader leads to a different image" href="https://bugs.freedesktop.org/show_bug.cgi?id=101648#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Adding a single-iteration do-while loop in a GLSL shader leads to a different image" href="https://bugs.freedesktop.org/show_bug.cgi?id=101648">bug 101648</a> from <a class="email" href="mailto:andriy.khulap@globallogic.com" title="Andriy Khulap <andriy.khulap@globallogic.com>"> Andriy Khulap</a> <pre>I am able to reproduce this issue on Skylake GT2. But it looks like it is already fixed. Tested the fallowing mesa versions: Mesa 17.3.6 (git-b3e5a3f35b) - FAIL Mesa 17.3.7 (git-8a51f3857c) - FAIL mesa-18.0.0-rc1 (e91e68d6a87a14) - OK Mesa 18.0.0 (git-dceb1ce807) - OK Mesa 18.1.0-devel (git-e7fc18097e) - OK Bisected and found the fix (tested it by reverting from the latest mesa master): commit 4d1959e69328cf0d59f0ec7aeea5a2b704ef0c5f Author: Francisco Jerez <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>> Date: Fri Oct 13 17:52:00 2017 -0700 intel/cfg: Represent divergent control flow paths caused by non-uniform loop execution. This addresses a long-standing back-end compiler bug that could lead to cross-channel data corruption in loops executed non-uniformly. In some cases live variables extending through a loop divergence point (e.g. a non-uniform break) into a convergence point (e.g. the end of the loop) wouldn't be considered live along all physical control flow paths the SIMD thread could possibly have taken in between due to some channels remaining in the loop for additional iterations. This patch fixes the problem by extending the CFG with physical edges that don't exist in the idealized non-vectorized program, but represent valid control flow paths the SIMD EU may take due to the divergence of logical threads. This makes sense because the i965 IR is explicitly SIMD, and it's not uncommon for instructions to have an influence on neighboring channels (e.g. a force_writemask_all header setup), so the behavior of the SIMD thread as a whole needs to be considered. No changes in shader-db. Reviewed-by: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> Reviewed-by: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>