<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [REGRESSION] [BISECTED] Large CS workgroup sizes broken in combination with FP64 on Intel."
   href="https://bugs.freedesktop.org/show_bug.cgi?id=111566">111566</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[REGRESSION] [BISECTED] Large CS workgroup sizes broken in combination with FP64 on Intel.
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>Mesa
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>19.2
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>not set
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Drivers/DRI/i965
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>intel-3d-bugs@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>currojerez@riseup.net
          </td>
        </tr>

        <tr>
          <th>QA Contact</th>
          <td>intel-3d-bugs@lists.freedesktop.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Large enough workgroup sizes that cause the Intel compiler back-end to generate
SIMD32 code are currently broken on master in combination with some shader
features that cause the back-end to allocate VGRFs larger than 16 GRFs, which
aren't supported by the register allocator and other back-end compiler passes,
and lead to assertion failures like:

"shader_runner: ../src/intel/compiler/brw_fs.cpp:2020: void
fs_visitor::split_virtual_grfs(): Assertion `offset <= MAX_VGRF_SIZE' failed.
Aborted (core dumped)"

I've written the following Piglit test that reproduces the issue:

<a href="https://gitlab.freedesktop.org/currojerez/piglit/commit/331b8afb47b9b79e5a6f697d4fe1fc2be6702617">https://gitlab.freedesktop.org/currojerez/piglit/commit/331b8afb47b9b79e5a6f697d4fe1fc2be6702617</a>

I bisected the regressions to change:

"commit f4ef34f207d15bcade7aed644328035dd0f2cc16
Author: Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>>
Date:   Wed May 29 17:46:55 2019 -0500

    intel/fs: Add an UNDEF instruction to avoid excess live ranges

    With 8 and 16-bit types and anything where we have to use non-trivial
    strides registersto deal with restrictions, we end up with things that
    look like partial writes even though we don't care about any values in
    the register except those written by that instruction.  This is
    particularly important when dealing with loops because liveness sees
    is_partial_write and the fact that an old version from a previous loop
    iteration may be valid at that point and extends all purely partially
    written values to the entire loop.

    This commit adds a new UNDEF instruction which does nothing (the
    generator doesn't emit anything) but which does a fake write to the
    register.  This informs liveness that we don't care about any values
    before that point so it won't consider those registers to be falsely
    live.  We can safely emit UNDEF instructions for all SSA values that
    come in from NIR and nearly all temporaries generated by various stages
    of the compiler.  In particular, we need to insert UNDEF instructions
    when we handle region restrictions because the newly allocated registers
    are almost guaranteed to be partially written.

    No shader-db changes.

    Bugzilla: <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - dEQP-VK tests running very long time"
   href="show_bug.cgi?id=110432">https://bugs.freedesktop.org/show_bug.cgi?id=110432</a>
    Reviewed-by: Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>>"

I had a half-baked fix for this but it seems like Jason is in the mood of
fixing SIMD32 regressions -- So here you got another one.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>