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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #37 from Iago Toral <itoral at igalia.com> ---
(In reply to Iago Toral from comment #36)
> (In reply to Kenneth Graunke from comment #35)
> > Is this on Gen7?  Does setting GEN7_PS_VECTOR_MASK_ENABLE in 3DSTATE_PS
> > DWord 2 help?  (Gen8+ already does this.)
> 
> Yes, it is gen7. I've just tested this but it does not seem to have any
> effect in this case, the problem persists.

As far as I can see, this issue spawns from the fact that atomic messages can
include a message header with pixel mask information while scattered read/write
messages (like many other read/write messages) can't, which can lead to some
inconsistencies when both are used together, something that I imagine being
common in SSBO usage patterns, unfortunately.

The PRMs clearly state that the pixel mask and the dispatch mask can be
different, which means that in these scenarios atomic operations will operate
on less channels (since the pixel mask is implicitly anded with the execution
mask) than our read/write messages, leading the inconsistent behavior I
explained in comment #34.

One way to work around this issue would be to fix the pixel mask in atomic
operations to always be 0xffff. Since the mask is anded with the dispatch mask
this should make atomic operations effectively use the dispatch mask and
operate on the same channels as our read/write messages. I have tested this
locally with a couple of examples and this seems to work, producing consistent
results.

Would this be an option?

If that is not a good idea, then I guess the alternative would be to do it the
other way around: fix the dispatch mask in the read/write messages to be like
the pixel mask we use in atomic operations, but I don't know if that is
possible.

-- 
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/20150504/4ca50624/attachment.html>