[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 #34 from Iago Toral <itoral at igalia.com> ---
Kristian, Jason:

we are almost done with development and we are doing some more elaborate
testing before preparing the patchset for review. In one of these tests I found
a situation that I tracked down to what I think is an incorrect value of the
pixel mask being delivered in the FS payload. I explain below:

I have a fragment shader like this:

layout(std140, binding=0) buffer Fragments {
   vec4 vf[8];
   int a[8];
   int last;
   vec4 d[];
};

layout(binding = 0, offset = 0) uniform atomic_uint counter;

in vec4 fragmentColor;
out vec4 color;

void main() {
   atomicCounterIncrement(counter);

   int index = int(mod(gl_FragCoord.x, 8));
   int i = atomicAdd(a[index], 1);

   if (i == 0)
      vf[index] = gl_FragCoord;

   i = atomicAdd(last, 1);
   d[i] = gl_FragCoord;

   color = fragmentColor;
}

When drawing a single point primitive I find this to produce the following
result:

- The atomic counter's value is 1
- a[3] == 1, a[i] = 0 for i != 3
- vf[3] = (199.5, 165.5, 0.5, 1.0)
- vf[2] = (198.5, 165.5, 0.5, 1.0)
- vf[i] = (0,0,0,0) for i != 2,3
- last == 1
- d[0] = (199.5, 165.5, 0.5, 1.0)
- d[i] i > 0 is 0

My understanding of this result is the following: the rendering of this single
point is producing two fragments that are both processed in a single execution
of the fragment shader (hence the two writes into vf). I verified that the
writes into vf come from offset.0 and offset.1 in the scattered write message
for that instruction, and seeing the coordinates  stored in vf it seems to make
sense.

However, in this scenario, what is the expected behavior of the atomic
operations? I would expect the atomicAdd on a[index] to increase a[3] *and*
a[2], since index has two different values for each of the fragments involved.
It seems like it is ignoring one of the fragments in this case. I would also
expect the acotmic counter to be incremented twice, etc

Since my implementation of the atomic operations on SSBOs reuse the existing
infrastructure used for atomic counters (so fs_visitor::emit_untyped_atomic in
this case) and I noticed this copies the pixel mask from g1.7 into the message,
I thought there could be a problem there, so I forced the pixel mask to be 3
(so that it aknowledges data in channels 0,1 where I know valid fragments are
stored in this particular case) and then I see this working as expected, that
is, after renderin the point primitive I see:

- The atomic counter's value is 2
- a[2] = 1 and a[3] = 1
- last = 2
- d[1] and d[2] have the two fragments stored in vf[2], vf[3]

So based on this I think something is wrong with the pixel mask that is being
delivered in the thread payload, which for some reason is removing a valid
channel. I guess this does not affect the scattered writes because these don't
include a pixel mask in their header... does this make sense to you?

-- 
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/20150430/6a2bf6ac/attachment.html>