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

[bugzilla-daemon at freedesktop.org]

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

Iago Toral <itoral at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at jlekstrand.net

--- Comment #13 from Iago Toral <itoral at igalia.com> ---
Jason, scattered writes did fix the problem, thanks!

I noticed an unexpected behavior though, according to the PRM, the scattered
write message is supposed to write 8 DWords at 8 offsets (for a block size of
8), however, for me it only writes 4. It completely ignores offsets stored in
M1.4:M1.7 and data stored in M2.4:M2.7 of the message payload.

This issue actually works great for me here because a vector type is at most 4
elements so we want to write 4 DWords tops with each message, but I wonder why
this this happening  and if it is safe to assume that it is going to write 4
Dwords always. The PRM says that the hardware uses the 8 lower bits of the
execution mask to select which of the 8 channels are effectively written, so I
wonder if that could be affecting here or if this issue might be related to
something else.

Any thoughts?

This is important because if I can't be sure that only 4 Dwords are going to be
written then I need to disable the writes from offsets M1.4:M1.7. Ideally I
would do this by altering the execution mask for the SEND instruction so that
it only considers the the channels we want to write. Is this possible? I have
not found any examples in the driver where this is done.

Alternatively, I could replicate the writes from offsets 0..3 into 4..7 (the
PRM says that the hardware optimizes writes to the same offset so this may not
be that bad).

-- 
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/20150416/a33ab9e5/attachment.html>