[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Is shader output atomic

On Fri, Aug 8, 2014 at 8:19 AM, Tibor Ouden, den
<tibordenouden@gmail.com> wrote:
> If a shader writes multiple times to the same framebuffer location, what is
> guaranteed about the values of the location ?
> For example : a shader writes two times (1, 2) to the same framebuffer pixel
> without a depth or stencil test.
> After the shader is finished the values in the color channels (RGBA) have
> been computed by invocation 1 or 2.
> But is it guaranteed that all the color channel values for one pixel come
> frome either 1 or 2 ?
> so RGBA = [R(1), G(1), B(1), A(1)] or RGBA = [R(2), G(2), B(2), A(2)] or
> could it be a combination like [R(1), G(2), B(2), A(1)] ?
> So is writing the color values treated as an atomic operation ?
> It makes sense that this is true but I cannot find anything about this in
> the specification.

Could you clarify your question? Are you talking about the case where
there are two triangles covering a particular pixel, or the case where
a single invocation of the fragment shader writes gl_FragColor more
than once?

In the case where multiple triangles cover a particular pixel, and
there might be two concurrent executions of fragment shaders, I'm
pretty sure it's guaranteed that the color writes will be atomic. I
can't find anything in the OpenGL ES 2.0 or GLSL ES 1.0 spec stating
this explicitly, but there would be no way to reason about the output
if individual channels could be mixed up. I think there are even
further guarantees about the order in which triangles are rasterized
within a single draw call. See:


In the case where the shader writes gl_FragColor more than once, the
writes would conceptually occur serially. GLSL ES 1.0.17 section 7.2
"Fragment Shader Special Variables" states the rules for writing and
reading gl_FragColor. In GLSL ES it's only legal to read gl_FragColor
after it's been written by that invocation of that fragment shader.

Extensions like EXT_shader_framebuffer_fetch allow reading of
preexisting contents of the framebuffer but synchronization between
independent fragment shader instances is a problem. Marco Salvi from
Intel described an extension from Intel last year at SIGGRAPH intended
to solve this problem:


> What are the guarantees about the output in the case of multiple draw
> buffers ?

For each individual draw buffer the guarantees would be the same as
for the single draw buffer case.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl