[Bug 89597] Implement SSBOs in GLSL front-end and i965

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 6 04:22:06 PDT 2015


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

--- Comment #48 from Francisco Jerez <currojerez at riseup.net> ---
(In reply to Iago Toral from comment #47)
>[...]
> 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 comment #38 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.

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


More information about the intel-3d-bugs mailing list