[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 #46 from Iago Toral <itoral at igalia.com> ---
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.

Again, this only seems to happen in a couple of examples where instance blocks
are involved, but I don't see how that could be related.

Any ideas as to what could be going on here?

-- 
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/98cfe290/attachment-0001.html>