blob: b136f95041ef213159e6725469bd114c86a78321 [file] [log] [blame]
Name
EXT_shader_pixel_local_storage
Name Strings
GL_EXT_shader_pixel_local_storage
Contributors
Jan-Harald Fredriksen, ARM
Sandeep Kakarlapudi, ARM
Marius Bjorge, ARM
Alexander Galazin, ARM
Tobias Hector, Imagination Technologies
Ilya Zaytsev, ARM
Contact
Jan-Harald Fredriksen (jan-harald.fredriksen 'at' arm.com)
Status
Shipping.
Version
Revision 6
Last Modified Date: Mar 12, 2014
Number
OpenGL ES Extension #167
Dependencies
OpenGL ES 3.0 is required.
This extension is written against the OpenGL ES Shading Language
specification, Language Version 3.00, Document Revision 3 and revision
OpenGL ES 3.0 of the API specification.
Overview
Techniques such as deferred shading and deferred lighting are often
implemented by attaching multiple color render targets to a framebuffer
object, rendering the required intermediate data, and then sampling from
this data as textures. While flexible, this approach consumes a large
amount of external memory bandwidth, which is at a premium on mobile
devices.
Observing that the intermediate or "G-buffer" data is often only written to
and read by shaders executing for the same pixel position, tile-based
renderers can offer a more efficient alternative by keeping the data on-GPU.
This allows large amounts of data to be kept per-pixel, with zero external
memory bandwidth impact.
This extension provides a way for applications to pass information between
fragment shader invocations covering the same pixel by introducing the
concept of pixel local storage. Pixel local storage is an on-chip memory
storage that can be efficiently accessed by fragments being processed by
the GL. The format of data stored in the pixel local storage is independent
of the format of the currently attached framebuffer. The data in pixel local
storage is not written back to main memory. Access to pixel local storage
is controlled via glEnable and glDisable. If commands that implicitly or
explicitly flush the GL command stream are issued when pixel local storage
is enabled then the contents of the pixel local storage becomes undefined
for subsequent commands.
New Procedures and Functions
None
New Tokens
Accepted by the <pname> parameters of GetBooleanv, GetIntegerv,
GetInteger64v, or GetFloatv:
MAX_SHADER_PIXEL_LOCAL_STORAGE_FAST_SIZE_EXT 0x8F63
MAX_SHADER_PIXEL_LOCAL_STORAGE_SIZE_EXT 0x8F67
Accepted by the <pname> parameters of IsEnabled, GetBooleanv, GetIntegerv,
GetInteger64v, or GetFloatv:
SHADER_PIXEL_LOCAL_STORAGE_EXT 0x8F64
New Macro Definitions
#define GL_EXT_shader_pixel_local_storage 1
Additions to Chapter 4 of the OpenGL ES Shading Language Specification
In Section 4.3 (Storage Qualifiers), add a qualifiers to the table:
"Qualifier Meaning
-------- -------
__pixel_localEXT fragment shader only; storage can be read and written
and is persistent across shader invocations covering
the same pixel
__pixel_local_inEXT fragment shader only; storage can be read and is
persistent across shader invocations covering the same
pixel; storage can be written in another shader
invocation declaring __pixel_localEXT or __pixel_-
local_outEXT storage.
__pixel_local_outEXT fragment shader only; storage can be written and is
persistent across shader invocations covering the same
pixel; storage is read in another shader invocation
declaring __pixel_localEXT or __pixel_local_inEXT
storage.
"
Then add a new paragraph at the end of the section:
"The __pixel_localEXT, __pixel_local_inEXT, and __pixel_local_outEXT
qualifiers are optional and must be enabled by calling
#extension GL_EXT_shader_pixel_local_storage : <behavior>
before use, where <behavior> is as specified in section 3.4."
After Section 4.3.6 (Output Variables), add a new paragraph:
"4.3.7 Pixel Local Variables
The __pixel_localEXT, __pixel_local_inEXT, and __pixel_local_outEXT
qualifiers are used to declare variables whose values are persistent across
fragment shader invocations covering the same pixel, collectively referred
to as pixel storage variables. Pixel local storage variables do not have any
backing store allocated through the OpenGL API and are not accessible to the
API.
Variables declared with the __pixel_localEXT qualifier can be read and
written from the same fragment shader invocation. Variables declared with
the __pixel_local_inEXT and __pixel_local_outEXT qualifiers can only be read
and written, respectively.
Pixel local storage variable reads and writes within a single shader
invocation are processed in order.
It is a compile-time error for a shader to statically write to both regular
user-defined fragment outputs and to pixel local storage variables. Reading
from pixel local storage variables and writing to user-defined fragment
outputs is, however, legal.
Pixel local storage variables may not have initializers and their contents
are undefined until written to from a shader.
Pixel local storage variables may be qualified with layout qualifiers
affecting how the values are stored in and retrieved from the underlying
storage, as described in section 4.3.8.4 "Pixel Local Block Layout
Qualifiers".
When reading from a pixel local storage variable, the in-storage value is
implicitly converted from the storage format specified by the layout
qualifier to the variable type. Similarly, when writing to a pixel local
storage variable, the value of the member is implicitly converted to the
storage format specified by the layout qualifier.
Pixel local storage variables may only be declared inside interface blocks
(section 4.3.7, "Interface Blocks"), which are then referred to as shader
pixel local storage blocks. It is a compile-time error to declare pixel
local storage variables at global scope (outside a block).
Pixel local storage blocks must be declared at global scope.
Pixel local storage variables declared inside pixel local storage
blocks will be laid out in local storage in monotonically increasing order
based on their location in the declaration. All pixel local storage
variables consume exactly 4 bytes of storage.
A shader may only declare a single input and a single output pixel local
storage block. A pixel local storage block declared using the __pixel_-
localEXT qualifier is counted as both an input and an output block. Thus,
it is a compile-time error for a shader to declare more than one pixel
storage block, with the exception that it is legal to declare one pixel
local storage block using the __pixel_local_inEXT qualifier and one with
the __pixel_local_outEXT qualifier.
Modify the start of Section 4.3.7 (Interface Blocks) to read:
"Uniform and pixel local storage variable declarations can be grouped into
named interface blocks to provide coarser granularity backing than is
achievable with individual declarations. They can have an optional instance
name, used in the shader to reference their members. A uniform block is
backed by the application with a buffer object. A block of pixel local
storage variables is not backed by any object.
GLSL ES 3.0 does not support interface blocks for shader inputs or outputs.
An interface block is started by a uniform or pixel local keyword, followed
by a block name, followed by an open curly brace ( { ) as follows:
interface-block:
layout-qualifieropt interface-qualifier block-name { member-list } instance-nameopt;
interface-qualifier:
in
out
uniform
__pixel_localEXT
__pixel_local_inEXT
__pixel_local_outEXT
"
Modify the sentence:
"Repeating the uniform interface qualifier for a member's storage qualifier
is optional."
To read:
"Repeating the uniform, __pixel_localEXT, __pixel_local_inEXT, or
__pixel_local_outEXT interface qualifier for a member's storage qualifier
is optional."
Add a new paragraph after the one starting with:
"For uniform blocks, the application uses the block name to identify the
block."
That reads:
"For __pixel_localEXT, __pixel_local_inEXT, and __pixel_local_outEXT storage
blocks, the block name is not used."
Modify the first paragraph of 4.3.8 (Layout Qualifiers) to read:
"Layout qualifiers can appear in several forms of declaration. They can
appear as part of an interface block definition or block member, as shown
in the grammar in the previous section. They can also appear with just an
interface qualifier (a storage qualifier that is in, out, uniform,
__pixel_localEXT, __pixel_local_inEXT, or __pixel_local_outEXT) to
establish layouts of other declarations made with that interface qualifier:
layout-qualifier interface-qualifier ;
"
Then remove paragraph starting with "Interface qualifiers are a subset of
storage qualifiers:" and the subsequent grammar for the interface-qualifier.
This is now described in section 4.3.7.
Add a new paragraph:
"
4.3.8.4 Pixel Local Block Layout Qualifiers
Layout qualifiers can be used for pixel local storage variables. The layout
qualifier identifiers for pixel local storage variables are:
layout-qualifier-id
float-pixel-local-format-qualifier
int-pixel-local-format-qualifier
uint-pixel-local-format-qualifier
float-pixel-local-format-qualifier
r11f_g11f_b10f
r32f
rg16f
rgb10_a2
rgba8
rg16
int-pixel-local-format-qualifier
rgba8i
rg16i
uint-pixel-local-format-qualifier
rgb10_a2ui
rgba8ui
rg16ui
r32ui
None of these have any semantic affect at all on the usage of the variables
being declared; they only describe how data is laid out in the underlying
storage.
The component format must match the base type and the number of components
of member declarations. It is a compile-time error to declare a pixel local
member where the format qualifier does not match the member type and the
number of components.
Pixel local storage layout qualifiers can be declared for global scope, on
a single pixel local storage block, or on a single pixel local storage block
member declaration.
Default layouts are established at global scope for pixel local storage
blocks as
layout(layout-qualifier-id-list) __pixel_localEXT;
layout(layout-qualifier-id-list) __pixel_local_inEXT;
layout(layout-qualifier-id-list) __pixel_local_outEXT;
The initial state of compilation is as if the following were declared:
layout(r32ui) __pixel_localEXT;
layout(r32ui) __pixel_local_inEXT;
layout(r32ui) __pixel_local_outEXT;
Pixel local storage blocks can be declared with optional layout qualifiers,
and so can their individual member declarations. Such block layout
qualification is scoped only to the content of the block. As with global
layout declarations, block layout qualification first inherits from
the current default qualification and then overrides it. Similarly,
individual member layout qualification is scoped just to the member
declaration, and inherits from and overrides the block's qualification.
The float-pixel-local-format-qualifier, the int-pixel-local-format-
qualifier, and the uint-pixel-local-format-qualifier overrides any previous
any previous use of any of these qualifiers; other qualifiers are inherited.
When multiple arguments are listed in a layout declaration, the effect will
be the same as if they were declared one at a time, in order from left to
right, each in turn inheriting from and overriding the result from the
previous qualification.
Example with per-member qualifiers:
__pixel_localEXT FragDataLocal {
layout(r11f_g11f_b10f) mediump vec3 normal;
layout(rgb10_a2ui) mediump uvec4 color;
layout(r32ui) highp uint flags;
};
Example with inherited qualifiers:
layout(rgba8ui) __pixel_localEXT FragDataLocal {
layout(rgb10_a2, r11f_g11f_b10f) mediump vec3 normal; // storage is r11f_g11f_b10f
layout(rgb10_a2ui) mediump uvec4 color;
mediump uvec4 flags; // storage is rgba8ui
};
Example of invalid local block declaration:
layout(rgba8ui) __pixel_localEXT FragDataLocal {
layout(r11f_g11f_b10f) mediump float normal; // error, component counts must match
layout(rgb10_a2ui) mediump vec4 color; // error, base types must match
};
"
Additions to Chapter 7 of the OpenGL ES Shading Language Specification
In Section 7.3 (Built-In Constants), add a new entry:
const mediump int gl_MaxShaderPixelLocalStorageFastSizeEXT = 16
const mediump int gl_MaxShaderPixelLocalStorageSizeEXT = 16
Changes to the OpenGL ES 3.0 Specification, Chapter 3
In Section 3.9, at the end of the last sub-section ("Shader Outputs") add:
"Fragment data values may also be written to pixel local storage blocks.
These values are available for reading in subsequent shader invocations
covering the same pixel. Data values written to pixel local storage block
members are converted to the storage format specified in the shader.
If a shader writes to any user-defined fragment output, the pixel local
storage values for that fragment are lost, and their values in subsequent
shader invocations are undefined.
Similarly, if a shader writes to pixel local storage blocks, the value of
the framebuffer pixel covered by that fragment becomes undefined."
Changes to the OpenGL ES 3.0 Specification, Chapter 4
In Section 4.1.7 ("Blending"), add after the fourth paragraph ("Blending
applies only if ..."):
"Blending only applies for user-defined fragment outputs. If the fragment
shader outputs to pixel local storage blocks, proceed to the next
operation."
In Section 4.1.9 ("Dithering), add after the second paragraph ("Many
dithering selection ..."):
"If the fragment shader outputs to pixel local storage blocks, no dithering
is performed."
In Section 4.4 ("Framebuffer Objects") modify the sentence:
"In particular, a framebuffer object encapsulates state necessary to
describe a collection of color, depth, and stencil logical buffers (other
types of buffers are not allowed)."
to read:
"In particular, a framebuffer object encapsulates state necessary to
describe a collection of color, depth, and stencil logical buffers (other
types of buffers cannot be attached)."
Then add the following paragraph to the end of the Section (before 4.4.1):
"A set of pixel local storage values may also be associated with the
framebuffer. These values are not backed by any framebuffer-attachable
image. This allows the GL to pass information between fragment shader
invocations covering the same pixel without requiring an attached object
to provide the underlying storage backing. The pixel local storage is only
valid while it is enabled as described in section 4.4.3."
Add a new section after 4.4.2 "Attaching Images to Framebuffer Objects" and
increase the section number for the the following subsections:
"4.4.3 Enabling pixel local storage
Fragment shaders have access to pixel local storage blocks, but this access
must be enabled prior to use and disabled after use.
Pixel local storage for the current draw framebuffer is enabled by calling
Enable with SHADER_PIXEL_LOCAL_STORAGE_EXT.
The contents of the pixel local storage for a pixel are initially an
implementation-defined function of the current value of the pixel in the
framebuffer. All pixel local storage variables are guaranteed to be zero if
all color components of the framebuffer are set to zero.
The contents of the pixel local storage persist until color data is flushed
to the framebuffer. After such an event, data in the pixel local storage
is lost and the contents are undefined. Events that cause a flush include:
* calling the GL commands Flush, Finish, and ClientWaitSync
* calling commands such as TexSubImage2D, CopyTexSubImage2D, and
BlitFramebuffer to update a texture that is also attached to the current
draw framebuffer while pixel local storage is enabled
* disabling pixel local storage by calling Disable with SHADER_PIXEL_-
LOCAL_STORAGE_EXT.
If pixel local storage is not enabled, an INVALID_OPERATION error will be
generated if any rendering command is issued while a program object that
accesses pixel local storage is bound.
While pixel local storage is enabled, an INVALID_OPERATION error will be
generated if any of the current draw framebuffer's attachment points are
modified, including changes to the underlying storage backing of objects
attached to these attachment points. An INVALID_OPERATION error will also be
generated on attempts to bind a different framebuffer object, to delete the
currently bound draw framebuffer, or change color buffer selection via
DrawBuffers while pixel local storage is enabled.
Pixel local storage is not supported in combination with multisample
rasterization. Attempting to enable pixel local storage while the value of
SAMPLE_BUFFERS is one will generate an INVALID_OPERATION error.
Pixel local storage is not supported when rendering to multiple draw
buffers. Attempting to enable pixel local storage while the current draw
framebuffer is a user-defined framebuffer and has an image attached to any
color attachment other than color attachment zero will generate an INVALID_-
OPERATION error. Similarly, attempting to enable pixel local storage while
the draw buffer for any color output other than color output zero is not
NONE will generate an INVALID_OPERATION error.
An INVALID_FRAMEBUFFER_OPERATION error will be generated when attempting to
enable pixel local storage while the current draw framebuffer is incomplete.
The total number of bytes of pixel local storage available to a shader is
specified by the value of the implementation-dependent constant MAX_SHADER_-
PIXEL_LOCAL_STORAGE_SIZE_EXT. A compile-time error will be generated if an
attempt is made to utilize more than the space available for pixel local
storage variables. An implementation may choose to subdivide the amount
of pixel local storage into a region for fast access and a region for normal
access. As many pixel local storage variables as possible will be stored,
in order of declaration, in the fast region before any variables will be
allocated in the normal region. The number of bytes available for fast
access is specified by the value of the implementation-dependent constant
MAX_SHADER_PIXEL_LOCAL_STORAGE_FAST_SIZE_EXT. This value will always be less
than or equal to the total amount of pixel local storage.
Pixel local storage is disabled by calling Disable with SHADER_PIXEL_-
LOCAL_STORAGE_EXT.
In the initial state, SHADER_PIXEL_LOCAL_STORAGE_EXT is disabled.
"
Errors
INVALID_OPERATION is generated if the application attempts enable pixel
local storage while the value of SAMPLE_BUFFERS is one.
INVALID_OPERATION is generated if the application attempts to enable pixel
local storage while the current draw framebuffer is a user-defined frame-
buffer object and has an image attached to any color attachment other than
color attachment zero.
INVALID_OPERATION is generated if the application attempts to enable pixel
local storage while the current draw framebuffer is a user-defined frame-
buffer and the draw buffer for any color output other than color
output zero is not NONE.
INVALID_FRAMEBUFFER_OPERATION is generated if the application attempts to
enable pixel local storage while the current draw framebuffer is incomplete.
INVALID_OPERATION is generated if pixel local storage is disabled and the
application attempts to issue a rendering command while a program object
that accesses pixel local storage is bound.
INVALID_OPERATION is generated if pixel local storage is enabled and the
application attempts to bind a new draw framebuffer, delete the currently
bound draw framebuffer, change color buffer selection via DrawBuffers, or
modify any attachment of the currently bound draw framebuffer including
their underlying storage.
New State
Add to Table 6.12 Framebuffer Control
Get Value Type Get Command Initial Value Description Sec.
--------------- ---- ------------ ------------- ----------- -----
SHADER_PIXEL_LOCAL- B IsEnabled FALSE Pixel local 4.4.3
STORAGE_EXT storage.
New Implementation Dependent State
Add to Table 6.32 Implementation Dependent Fragment Shader Limits
State Type Get Command Minimum Value Description Sec.
--------------- ---- ------------ ------------- ----------- -----
MAX_SHADER_PIXEL- Z+ GetIntegerv 16 Amount of fast 4.4.3
LOCAL_STORAGE_FAST- storage in units
_SIZE_EXT of bytes available
for pixel local
storage variables.
MAX_SHADER_- Z+ GetIntegerv 16 Amount of total 4.4.3
PIXEL_LOCAL_STORAGE- storage in units
_SIZE_EXT of bytes available
for pixel local
storage variables.
Examples
(1) Use the extension to write data.
#version 300 es
#extension GL_EXT_shader_pixel_local_storage : enable
__pixel_localEXT FragDataLocal {
layout(r11f_g11f_b10f) mediump vec3 normal;
layout(rgb10_a2) highp vec4 color;
layout(rgba8ui) mediump uvec4 flags;
} gbuf;
void main()
{
/* .... */
gbuf.normal = v;
gbuf.color = texture(sampler, coord);
gbuf.flags = material_id;
}
(2) Use the extension to resolve the data.
#version 300 es
#extension GL_EXT_shader_pixel_local_storage : enable
__pixel_localEXT FragDataLocal {
layout(r11f_g11f_b10f) mediump vec3 normal;
layout(rgb10_a2) highp vec4 color;
layout(rgba8ui) mediump uvec4 flags;
} gbuf;
out highp vec4 fragColor;
void main()
{
fragColor = do_lighting(gbuf.normal, gbuf.color, gbuf.flags, light_pos);
}
Issues
(1) Should errors be raised when this extension is used in combination with
blending and dithering?
RESOLVED.
No. Blending and dithering should be ignored when the shader outputs raw
values.
(2) Should errors be raised when this extension is used in combination with
multisampling?
RESOLVED.
Yes. This can be trivially detected when the pixel local storage is
enabled.
The alternative is that it results in undefined results. As long as the
shader is only run once per fragment, this should sort of work except
the coverage mask could mask out some bits.
(3) Should explicit packing functions be supported?
RESOLVED.
No.
Early versions of this extensions required explicit packing functions
to be used when writing to and reading from the pixel local storage.
This version of the extension does implicit conversions in of these
cases so packing functions are not required.
(4) What is the initial values of local variables?
RESOLVED.
On a cleared framebuffer, the values of pixel local variables will be
some function of the clear color value. But the function may be
different depending on the format of the framebuffer. This makes the
value effectively undefined unless the framebuffer has been cleared to
zero.
See also Issue 5.
(5) Do we need an API to initialize the pixel local variables?
RESOLVED.
No. This is deferred to a future extension.
Given Issue 4, there is no convenient way to initialize these variables
to anything other than zero.
Applications can initialize it by drawing a fullscreen quad that writes
to the local outputs, but that may not be the most efficient way.
An alternative solution is to define a new API to clear the framebuffer
along the lines of:
ClearLocaluiEXT(enum buffer, uint n, const T *values);
(6) Should the raw storage alias the fragment color?
RESOLVED.
Applications may want to mix shaders using pixel local storage and user-
defined outputs. This could be supported if we reserve a number of bits
(where the number depends on the framebuffer format) for the user-
defined outputs.
This approach may make it possible to support this functionality on
non-tile based renderers by directing raw values to a separate buffer
in memory.
This extension currently aliases the storage. Applications can manually
preserve the framebuffer value by using ARM_shader_framebuffer_fetch,
EXT_shader_framebuffer_fetch, or similar extensions to retrieve the
color value and then store this as a local value.
(7) Is there a way to salvage some aspect of multisampling?
RESOLVED.
Multisampling is clearly a desirable feature. The most likely
implementation of this extension, however, is to reuse the pixel local
storage normally used for multisample data to store application-specific
data, thus making this extension incompatible with multisampled
rasterization.
Support for multisampling is left to a future extension.
(8) Should pixel local variables be allowed declared outside interface
blocks?
RESOLVED.
No. This makes the pixel local storage much more difficult to manage.
The ESSL compiler would have to enforce ordering rules shaders to make
sure that all shaders see the pixel local storage declarations in the
same order. This seems to add implementation complexity for no obvious
benefit.
(9) Should packUnitVector3 be added in a separate extension?
RESOLVED.
Extended packing functions is only indirectly related to the core
feature exposed by this extension. They could potentially have other
use-cases. This could be added in the future if needed. See Issue 15.
(10) What happens to the local storage after eglSwapBuffers?
RESOLVED.
The contents of the pixel local storage are lost after a call to
eglSwapBuffers. In this respect, pixel local storage acts as an
ancillary buffer than cannot be preserved.
(11) Can pixel local storage variables be arrays?
RESOLVED.
Yes. There's no reason not to support this.
(12) Are variables declared with the pixel local qualifiers preserved?
RESOLVED.
There are two options: A) the implementation implicitly preserves all
unwritten pixel local variables, and B) the shader must explicitly
preserve unwritten pixel local variables.
Consider the following local storage block:
__pixel_localEXT FragDataLocal {
layout(r11f_g11f_b10f) mediump vec3 normal;
layout(rgb10_a2) highp vec4 color;
layout(rgba8ui) mediump uvec4 flags;
} gbuf;
If a shader only writes to 'color', option B would make 'normal and
'flags' undefined unless the shader also manually assigned these
variables to themselves. This would certainly be unexpected. If a
shader wants to reduce the data, e.g., by only preserving the 'normal'
variable, it can do so by declaring separate __pixel_local_inEXT and
__pixel_local_outEXT blocks.
Option A is chosen.
(13) Can CopyTex[Sub]Image, ReadPixels, and BlitFramebuffer be called
while pixel local storage is enabled?
RESOLVED.
These calls are all supported, but may not be very useful.
For CopyTex[Sub]Image and ReadPixels, the contents of the color buffer
will have undefined contents if the pixel local storage variables have
not yet been resolved.
BlitFramebuffer implicitly writes to the color buffer of the draw
framebuffer and will thus make all pixel local storage variables
associated with it undefined.
(14) What does 'undefined' mean for a pixel local storage variable
or a color value?
RESOLVED.
It simply means that the value has no well-defined meaning to an
application. It does _not_ mean that the value is random nor that it
could have been leaked from other contexts or processes.
(15) Do we need a built-in function to pack unit vectors?
RESOLVED.
No, there is no need for this.
Earlier drafts of this extensions added ESSL built-in functions to pack
and unpack unit vectors (packUnitVector3EXT, unpackUnitVector3EXT).
These would, however, only be useful if they gave performance
improvements over plain ESSL code, which they do not.
The following packing functions have been found to generate equivalent
code to the proposed built-in functions:
highp uint packUnitVector3(mediump vec3 n)
{
highp float p = sqrt(2.0) * sqrt(n.z + 1.0);
return packHalf2x16(n.xy / p);
}
mediump vec3 unpackUnitVector3(highp uint p)
{
highp vec2 fenc = unpackHalf2x16(p);
highp float f = dot(fenc, fenc);
highp float g = sqrt(1.0 - f);
highp vec3 n;
n.xy = 2.0*fenc*g;
n.z = 1.0 - 2.0*f;
return n;
}
(16) When writing to a single output value in a shader, do all local
storage values become invalid immediately? And vice versa?
E.g:
fragmentOutputValue = localstorage.value;
// Does a further access return an undefined value?
fragmentOutputValue += localstorage.value;
RESOLVED: No, these variables retain their values for the life of the
shader.
Fragment outputs and local storage variables are treated as temporary
variables during execution of a shader, rather than accessing the
underlying storage directly. Final values are only written to underlying
storage at the end of a shader's execution. Within a shader instance,
these variables can be read or written safely in any order.
Revision History
Revision 6, 12/03/2014 (Jan-Harald Fredriksen)
Added Issue 16.
Revision 5, 18/02/2014 (Jan-Harald Fredriksen)
Clarified that pixel local storage is undefined after flush commands.
Updated error conditions for MRT to cover the default framebuffer.
Minor wording changes.
Resolved Issue 7.
Expanded Issue 15.
Updated resolution of Issue 3.
Revision 4, 22/12/2013 (Jan-Harald Fredriksen)
Changed name to EXT_shader_pixel_local_storage.
Added MAX_SHADER_PIXEL_LOCAL_STORAGE_FAST_SIZE_EXT.
Clarified memory layouts within local storage blocks.
Revision 3, 14/10/2013 (Jan-Harald Fredriksen)
Fixed a typo.
Modified error conditions with multiple draw buffers.
Revision 2, 27/09/2013 (Jan-Harald Fredriksen)
Increased minimum maximum storage to 16 bytes.
Fixed a couple of typos.
Added Issues 13 and 14.
Added an error condition when enabling pixel local storage on an
incomplete FBO.
Restricted local storage to color attachment zero.
Disallowed changing buffer selection DrawBuffers while pixel local
storage is enabled.
Removed packUnitVector3/unpackUnitVector3 and added Issue 15.
Revision 1, 29/07/2013 (Jan-Harald Fredriksen)
First external draft.