OpenGL 4.2 (Compatibility Profile) - April 27, 2012

2.14. VERTEX SHADERS 157
invocation assumes that the other invocation has been launched and can complete
its writes. The only case where such a guarantee is made is when the inputs of
one shader invocation are generated from the outputs of a shader invocation in a
previous stage.
Stores issued to different memory locations within a single shader invocation
may not be visible to other invocations in the order they were performed. The
built-in function memoryBarrier() may be used to provide stronger ordering of
reads and writes performed by a single invocation. Calling memoryBarrier()
guarantees that any memory transactions issued by the shader invocation prior to
the call complete prior to the memory transactions issued after the call. Memory
barriers may be needed for algorithms that require multiple invocations to access
the same memory and require the operations need to be performed in a partiallydefined
relative order. For example, if one shader invocation does a series of writes,
followed by a memoryBarrier() call, followed by another write, then another
invocation that sees the results of the final write will also see the previous writes.
Without the memory barrier, the final write may be visible before the previous
writes.
The built-in atomic memory transaction functions may be used to read and
write a given memory address atomically. While built-in atomic functions issued
by multiple shader invocations are executed in undefined order relative to each
other, these functions perform both a read and a write of a memory address and
guarantee that no other memory transaction will write to the underlying memory
between the read and write. Atomics allow shaders to use shared global addresses
for mutual exclusion or as counters, among other uses.
Shader Memory Access Synchronization
Data written to textures or buffer objects by a shader invocation may eventually
be read by other shader invocations, sourced by other fixed pipeline stages, or read
back by the application. When applications write to buffer objects or textures using
API commands such as TexSubImage* or BufferSubData, the GL implementation
knows when and where writes occur and can perform implicit synchronization
to ensure that operations requested before the update see the original data and
that subsequent operations see the modified data. Without logic to track the target
address of each shader instruction performing a store, automatic synchronization
of stores performed by a shader invocation would require the GL implementation
to make worst-case assumptions at significant performance cost. To permit
cases where textures or buffers may be read or written in different pipeline stages
without the overhead of automatic synchronization, buffer object and texture stores
performed by shaders are not automatically synchronized with other GL operations
OpenGL 4.2 (Compatibility Profile) - April 27, 2012