[Bug 102289] SynMark CSDof misrenders with "i965/surface_state: Get the aux usage from the miptree code"

[bugzilla-daemon at freedesktop.org]

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

Jason Ekstrand <jason at jlekstrand.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Jason Ekstrand <jason at jlekstrand.net> ---
This is fixed by the following commit in master:

commit d5e217dbfda2a87e149bdc8586c25143fc0ac183
Author: Jason Ekstrand <jason.ekstrand at intel.com>
Date:   Fri Aug 18 16:10:39 2017 -0700

    i965: Stop looking at NewDriverState when emitting 3DSTATE_URB

    Looking at NewDriverState is not safe in general.  The state atom system
    is set up to ensure that new bits that get added to NewDriverState get
    accumulated into the set of bits used when emitting atoms but it doesn't
    go the other way.  If we read NewDriverState, we may not get the full
    picture because the per-pipeline state (3D or compute) does not get
    added to NewDriverState before state emit is done.  It's especially
    dangerous to do this from BLORP (either explicitly or implicitly when
    BLORP calls gen7_upload_urb) because that does not happen during one of
    the normal state upload paths.

    This commit solves the problem by whacking all of the per-shader-stage
    URB sizes to zero whenever we change the total URB size.  We still have
    to flag BRW_NEW_URB_SIZE to ensure that the gen7_urb atom triggers but
    the actual decision in gen7_upload_urb can now be based entirely on URB
    sizes rather than on state atoms.  This also makes BLORP correct because
    it just asks for a new URB config whenever the vsize is too small and so
    any change to the total URB size will trigger blorp to re-emit as well
    because 0 < vs_entry_size.

    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
    Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
    Bugzilla: https://bugs.freedesktop.org/102289
    Cc: mesa-stable at lists.freedesktop.org

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