<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#c49">Comment # 49</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:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Francisco Jerez from <a href="show_bug.cgi?id=89597#c48">comment #48</a>) > (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. Ah, that makes sense, otherwise helper invocations would not do be reliable, of course. Thanks Francisco, I'll do that.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>