[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 #47 from Iago Toral <itoral at igalia.com> ---
(In reply to Iago Toral from comment #46)
> I have implemented reads and writes in the fragment shader using untyped
> messages. Works fine, but I found a very strange quirk that seems to happen
> in a very specific scenario and that once again seems related to the pixel
> mask. I don't know what is going on.
> 
> The scenario that triggers this is always with an instance block although I
> am not sure that the actual problem has anything to do with that. The shader
> looks like this:
> 
> layout(std140, binding=2) buffer Fragments {
>    vec4 v0;
>    vec4 v1;
> } inst[3];
> 
> out vec4 color;
> 
> void main()
> {
>    int index = int(inst[0].v0.x);
>    inst[index].v1 = vec4(-1, -2, -3, -4);
>    color = vec4(int(inst[0].v0.x), int(inst[0].v0.y), int(inst[0].v0.z), 1);
> }
> 
> inst[0].v0 is initialized to (1,1,1,1), so  the shader should be writing
> (-1,-2,-3,-4) to inst[1].v1. What I see, however, is that it writes to
> inst[0].v1 instead.
> 
> I tracked this down to the pixel mask again:
> 
> If I force the pixel mask used in the untyped read messages to be 0x1, then
> we obtain the result we expect (that is, a write into inst[1]). My
> interpretation of this is that the write is operating on channel 0, while
> the read, for some reason, is not, even if they both use the same pixel
> mask. However, if I do this, the pixel color shown on the screen is
> incorrect. Again, my interpretation of this is that the framebuffer write is
> choosing data from a channel other than 0.
> 
> If I force the pixel mask in the untyped read messages to be 0x8 (channel
> 3), then the pixel color on the screen is correct. My interpretation of this
> is that framebuffer writes take data from channel 3.
> 
> If I don't force any pixel mask in the untyped read messages (i.e., I use
> the one delivered to the thread in g1.7), then the color in the screen is
> also correct. My interpretation of this is that untyped reads and
> framebuffer writes operate on channel 3.
> 
> So I would guess the problem here is that the untyped write operates on
> channel 0 when it should operate on channel 3. However, I don't see what
> could be causing this when both untyped reads and untyped writes are using
> the same pixel mask for their headers (the one from g1.7). Also, if I force
> the pixel mask in the write message to be 0x8 so it operates on channel 3,
> it still writes to inst[0], which again, I find unexpected, since channel 3
> should be carrying the right index data as per the tests above.

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 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/97a32669/attachment.html>