<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597#c48">Comment # 48</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Implement SSBOs in GLSL front-end and i965" href="https://bugs.freedesktop.org/show_bug.cgi?id=89597">bug 89597</a> from <a class="email" href="mailto:currojerez@riseup.net" title="Francisco Jerez <currojerez@riseup.net>"> Francisco Jerez</a> <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=89597#c47">comment #47</a>) >[...] > And to make things even more confusing, if I use scattered writes instead of > untyped writes, the problem persists (strange, since these ignore the pixel > mask and should write data from any channel enabled in the execution mask, > including the channel where reads are operating on. It is at least > consistent with the fact that fixing the pixel mask in the untyped write > message didn't work). However, if I use scattered reads instead of untyped > reads (and keeping untyped writes) it works well (correct write into inst[1] > and correct pixel color on screen). This is also consistent with the tests I > did above, since with scattered reads we will get the right index into the > channel that the write is using. > > As a side note, in the case that we can't find an explanation for this > behavior and fix it, I was thinking that a workaround that seems to work > could be to ignore the pixel mask for untyped reads. The rationale is that > the requirements from the spec as shared in <a href="show_bug.cgi?id=89597#c38">comment #38</a> only affect > operations that can modify the underlying surfaces. Since reads do not > modify anything, I think it should be fine to have them ignore the pixel > mask and only set a pixel mask for the write messages and atomic operations. > That would fix the problem by making sure that writes that depend on the > result of a read do not use data from channels that the reads end up > ignoring because of the pixel mask. You seem to have found the explanation yourself ;). The spec requires shader storage block reads to give well-defined values even for helper invocations, so the sample mask should *not* be used for untyped surface reads -- I think that's not only a workaround, it's how it should be. I suggest you simply remove the header from the payload built by emit_untyped_read() and unset the "header present" bit in brw_eu_emit.c, so that the shared unit uses the default sample mask of all ones.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>