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

Re: [Public WebGL] Is shader output atomic

There are never concurrent writes of different triangles (as far as the spec is concerned), as the result of a draw must be as if the triangles were drawn one at a time.


----- Original Message -----
From: "Tibor Ouden, den" <tibordenouden@gmail.com>
To: "Kenneth Russell" <kbr@google.com>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Friday, August 8, 2014 2:13:10 PM
Subject: Re: [Public WebGL] Is shader output atomic

Thanks for the info,
I was referring to the case were multiple triangles cover the same pixel so
there might be concurrent writes to the same pixel.
It makes sense that it works the way you describe, I was wondering how much
of it is formalized / specified in reference docs.

2014-08-08 22:35 GMT+02:00 Kenneth Russell <kbr@google.com>:

> 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:
> https://webglsamples.googlecode.com/hg/sprites/readme.html
> 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:
> http://advances.realtimerendering.com/s2013/2013-07-23-SIGGRAPH-PixelSync.pdf
> > 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.
> -Ken

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