| Name |
| |
| EXT_shader_pixel_local_storage2 |
| |
| Name Strings |
| |
| GL_EXT_shader_pixel_local_storage2 |
| |
| Contributors |
| |
| Jan-Harald Fredriksen, ARM |
| Sandeep Kakarlapudi, ARM |
| James Glanville, Imagination Technologies |
| Tobias Hector, Imagination Technologies |
| |
| Contact |
| |
| Tobias Hector (tobias.hector 'at' imgtec.com) |
| |
| Status |
| |
| Complete |
| |
| Version |
| |
| Revision 0.13 |
| Last Modified Date: October 28, 2015 |
| |
| Number |
| |
| OpenGL ES Extension #253 |
| |
| Dependencies |
| |
| OpenGL ES 3.0 and GLSL ES 3.0 are required. |
| |
| EXT_shader_pixel_local_storage is required. |
| |
| This extension has interactions with EXT_color_buffer_float and |
| EXT_color_buffer_half_float |
| |
| This extension is written against the OpenGL ES Shading Language |
| specification, Language Version 3.00, Document Revision 4 and revision |
| OpenGL ES 3.0.2 of the API specification. |
| |
| Overview |
| |
| This extension builds on EXT_shader_pixel_local_storage by lifting the |
| restriction that pixel local storage is not supported when rendering to |
| multiple draw buffers. |
| |
| Moreover, pixel local storage values are no longer lost when writing to |
| user-defined fragment outputs, and, correspondingly, framebuffer pixel |
| values do not always become undefined when the shader writes to pixel local |
| storage. |
| |
| This extension adds the following capabilities: |
| - support for pixel local storage in combination with multiple user- |
| defined fragment outputs |
| - support for clearing pixel local storage variables |
| - support for multi-word pixel local storage variables |
| |
| New Procedures and Functions |
| |
| void FramebufferPixelLocalStorageSizeEXT(uint target, sizei size); |
| sizei GetFramebufferPixelLocalStorageSizeEXT(uint target); |
| void ClearPixelLocalStorageuiEXT(sizei offset, sizei n, const uint *values); |
| |
| New Tokens |
| |
| Accepted by the <pname> parameters of GetBooleanv, GetIntegerv, |
| GetInteger64v, or GetFloatv: |
| |
| MAX_SHADER_COMBINED_LOCAL_STORAGE_FAST_SIZE_EXT 0x9650 |
| MAX_SHADER_COMBINED_LOCAL_STORAGE_SIZE_EXT 0x9651 |
| |
| Returned by CheckFramebufferStatus: |
| |
| FRAMEBUFFER_INCOMPLETE_INSUFFICIENT_SHADER_COMBINED_LOCAL_STORAGE_EXT 0x9652 |
| |
| New Macro Definitions |
| |
| #define GL_EXT_shader_pixel_local_storage2 1 |
| |
| New Built-in Variables |
| |
| None |
| |
| Changes to the OpenGL ES 3.0 Specification, Chapter 3 |
| |
| In Section 3.9.2, at the end of the last sub-section ("Shader Outputs"), |
| modify the three paragraphs added by GL_EXT_shader_pixel_local_storage, |
| such that it reads: |
| |
| "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 GL_EXT_shader_pixel_local_storage2 is supported a shader may write |
| to both user-defined fragment outputs and to pixel local storage blocks. |
| |
| If GL_EXT_shader_pixel_local_storage2 is not supported and 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"), modify the paragraph added by GL_EXT_shader- |
| _pixel_local_storage to read: |
| |
| "Blending only applies to user-defined fragment outputs. No blending is |
| performed for outputs to pixel local storage blocks. If the fragment |
| shader outputs only to pixel local storage blocks, proceed to the next |
| operation." |
| |
| In Section 4.1.9 ("Dithering), modify the paragraph added by GL_EXT_shader- |
| _pixel_local_storage to read: |
| |
| "Dithering only applies to user-defined fragment outputs. No dithering |
| is performed on outputs to pixel local storage blocks." |
| |
| In Section 4.2.3 ("Clearing the Buffers") add the following: |
| |
| "The command |
| |
| void ClearPixelLocalStorageuiEXT(sizei offset, sizei n, const uint *values); |
| |
| clears a consecutive region of the pixel local storage to a specified set |
| of values. <offset> is the start offset of the region in 32-bit words. <n> |
| is the number of 32-bit words to clear. <values> is an array of <n> 32-bit |
| words that specifies the values the pixel local storage should be cleared |
| to. The words in <n> are packed with the first component in the least |
| significant bits of the word. The most significant bit of each component is |
| packed in the most significant bit location of its location in the word. If |
| <values> is NULL, all pixel local storage in the supplied range has every |
| bit set to 0. |
| |
| Clearing the pixel local storage will clear all values stored in the |
| specified range. This will have the effect of making the value of any user- |
| defined fragment output in this range undefined. Applications can determine |
| the fragment output or pixel local storage variables the range |
| corresponds to by the locations declared in the shader and by the storage |
| sizes described in section 4.3.8.2 ("Output Layout Qualifiers") of the |
| OpenGL ES Shading Language Specification. Further, an implementation is |
| required to allocate variables in storage the following order: pixel local |
| variables first, then fragment outputs. |
| |
| When ClearPixelLocalStorageuiEXT is called, no per-fragment operations or |
| mask operations are applied. |
| |
| An INVALID_VALUE error will be generated if the sum of <offset> and <n> |
| exceeds the total amount pixel local storage available to a shader. An |
| INVALID_OPERATION error will be generated if ClearPixelLocalStorageuiEXT is |
| called while pixel local storage is disabled." |
| |
| Replace Section 4.4.3 ("Enabling pixel local storage") with the following: |
| |
| "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 content of the pixel local storage for a pixel is initially undefined. |
| |
| 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. |
| |
| An INVALID_FRAMEBUFFER_OPERATION error will be generated when attempting to |
| enable pixel local storage while the current draw framebuffer is incomplete. |
| |
| The maximum 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. |
| |
| The maximum number of bytes of combined storage per pixel available to a |
| shader is specified by the value of the implementation-dependent constant |
| MAX_SHADER_COMBINED_LOCAL_STORAGE_SIZE_EXT. This value is the combined |
| storage of color attachments and pixel local storage. A compile-time error |
| will be generated if an attempt is made to utilize more than the combined |
| space for local storage. An INVALID_OPERATION error is generated by any |
| command that draws geometry if the combined storage required for the |
| current draw framebuffer and the pixel local storage of the current program |
| is greater than this value. As for the total amount of pixel local storage, |
| an implementation may choose to subdivide the amount of combined storage |
| into a region for fast access and a region for normal access. The number of |
| bytes available for fast access is specified by the value of the |
| implementation-dependent constant MAX_SHADER_COMBINED_LOCAL_STORAGE_FAST_- |
| SIZE_EXT. This value will always be less than or equal to the total amount |
| of combined 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. |
| |
| If EXT_shader_pixel_local_storage2 is to be used, then the amount of pixel |
| local storage must be known to the framebuffer before pixel local storage |
| is enabled, similar to a framebuffer attachment. |
| |
| The command |
| |
| void FramebufferPixelLocalStorageSizeEXT(uint target, sizei size); |
| |
| specifies the amount of storage required for pixel local variables whilst |
| SHADER_PIXEL_LOCAL_STORAGE_EXT is enabled. <target> specifies the |
| framebuffer that is modified by this function. <size> determines the size, |
| in bytes, required for pixel local storage. An INVALID_VALUE error is |
| generated if <size> is greater than MAX_SHADER_PIXEL_LOCAL_STORAGE_SIZE_- |
| EXT, or if it is not a multiple of 4. An INVALID_OPERATION error is |
| generated if an application tries to call this function whilst SHADER_- |
| PIXEL_LOCAL_STORAGE_EXT is enabled. |
| |
| The amount of storage required for pixel local variables can be |
| determined by the storage sizes described in section 4.3.8.2 ("Output |
| Layout Qualifiers") of the OpenGL ES Shading Language Specification. |
| |
| If the default framebuffer is bound to <target>, then calling this |
| function does not affect framebuffer completeness. |
| |
| The command |
| |
| sizei GetFramebufferPixelLocalStorageSizeEXT(uint target); |
| |
| returns the size of pixel local storage previously set on the framebuffer |
| bound to <target> by FramebufferPixelLocalStorageSizeEXT." |
| |
| Add the following to the list of framebuffer complete conditions in |
| sub-section "Whole Framebuffer Completeness" in section 4.4.4: |
| |
| " - The amount of pixel local storage specified by |
| FramebufferPixelLocalStorageSizeEXT is zero, or the combined size of |
| pixel local storage and fragment outputs is less than MAX_SHADER_- |
| COMBINED_LOCAL_STORAGE_SIZE_EXT. |
| |
| { FRAMEBUFFER_INCOMPLETE_INSUFFICIENT_SHADER_COMBINED_LOCAL_STORAGE_EXT }" |
| |
| Add the following to the list of functions that can affect framebuffer |
| completeness sub-section "Whole Framebuffer Completeness" in section 4.4.4: |
| |
| " - Changing the size of shader pixel local storage with |
| FramebufferPixelLocalStorageSizeEXT." |
| |
| Errors |
| |
| Remove the following error added in EXT_shader_pixel_local_storage: |
| |
| 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. |
| |
| Add the following errors: |
| |
| INVALID_VALUE is generated by ClearPixelLocalStorageuiEXT if the sum of |
| <offset> and <n> exceeds the total amount pixel local storage available to a |
| shader. |
| |
| INVALID_OPERATION is generated if ClearPixelLocalStorageuiEXT is called while |
| pixel local storage is disabled. |
| |
| INVALID_OPERATION is generated by any command that draws geometry if the |
| combined storage required for the current draw framebuffer and the pixel |
| local storage of the current program is is greater than the value of MAX_- |
| SHADER_COMBINED_LOCAL_STORAGE_SIZE_EXT. |
| |
| New State |
| |
| Add to Table 6.13 Framebuffer (state per framebuffer object) |
| |
| State Type Get Command Initial Value Description Sec. |
| --------------- ---- ------------ ------------- ----------- ----- |
| Z+ GetFramebuffer- 0 Amount of pixel 4.4.3 |
| PixelLocal- local storage |
| StorageSizeEXT specified for |
| the framebuffer. |
| |
| New Implementation Dependent State |
| |
| Add to Table 6.32 Implementation Dependent Fragment Shader Limits |
| |
| State Type Get Command Minimum Value Description Sec. |
| --------------- ---- ------------ ------------- ----------- ----- |
| MAX_SHADER_COMBINED- Z+ GetIntegerv 16 Amount of fast 4.4.3 |
| LOCAL_STORAGE_FAST- storage in units |
| _SIZE_EXT of bytes available |
| for per-pixel |
| storage. |
| |
| MAX_SHADER_COMBINED- Z+ GetIntegerv 16 Amount of total 4.4.3 |
| LOCAL_STORAGE_SIZE- storage in units |
| _EXT of bytes available |
| for per-pixel |
| storage. |
| |
| Additions to Chapter 4 ("Variables and Types") of the OpenGL ES Shading Language Specification |
| |
| Replace section "4.3.7 Pixel Local Variables" with the following: |
| |
| "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 local variables. Pixel local 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 qualifier can only be read. Variables declared |
| with the __pixel_local_outEXT qualifier can only be written. |
| |
| Pixel local storage variable reads and writes within a single shader |
| invocation are processed in order. |
| |
| It is legal for a shader to write to both user-defined fragment outputs and |
| pixel local storage variables. |
| |
| Pixel local storage variables may not have initializers and their contents |
| are undefined until written to from a shader or initialized via the API. If |
| a pixel local storage variable is not written to in a fragment shader, the |
| value of that variable is undefined unless it was declared as part of a |
| __pixel_localEXT block. |
| |
| 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 variables |
| consume integer multiples of 4 bytes, as specified in section 4.3.8.4. |
| |
| Pixel local storage blocks may be allocated from the same storage as any |
| user-defined color outputs, but do not alias. Writing to pixel local |
| variables has no effect on any user-defined outputs, and pixel local |
| variables are not affected by writes to any user-defined outputs. |
| |
| 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." |
| |
| In section 4.3.8.2, "Output Layout Qualifiers", add the following to the |
| list of layout qualifiers applicable to fragment outputs only: |
| |
| layout-qualifier-id |
| float-output-format-qualifier |
| int-output-format-qualifier |
| uint-output-format-qualifier |
| generic-output-format-qualifier |
| |
| float-pixel-local-format-qualifier |
| rgb565 |
| r8 |
| rg8 |
| rgb8 |
| rgba8 |
| srgb8_a8 |
| rgb5_a1 |
| rgba4 |
| rgb10_a2 |
| |
| [[ Only if EXT_color_buffer_float is supported ]] |
| r32f |
| rg32f |
| r11f_g11f_b10f |
| rgba32f |
| |
| [[ Only if EXT_color_buffer_half_float or EXT_color_buffer_float is supported ]] |
| r16f |
| rg16f |
| rgba16f |
| |
| [[ Only if EXT_color_buffer_half_float is supported ]] |
| rgb16f |
| |
| int-pixel-local-format-qualifier |
| r8i |
| r16i |
| r32i |
| rg8i |
| rg16i |
| rg32i |
| rgba8i |
| rgba16i |
| rgba32i |
| |
| uint-pixel-local-format-qualifier |
| r8ui |
| r16ui |
| r32ui |
| rg8ui |
| rg16ui |
| rg32ui |
| rgba8ui |
| rgb10_a2ui |
| rgba16ui |
| rgba32ui |
| |
| generic-output-format-qualifier |
| implementation_defined |
| |
| Add the following paragraphs to the end of this section: |
| |
| "The output format qualifiers are optional and must be enabled by calling |
| |
| #extension GL_EXT_shader_pixel_local_storage2: <behavior> |
| |
| before use, where <behavior> is as specified in section 3.4. |
| |
| Each output-format-qualifier specifies the format which each of the |
| user-defined fragment outputs is stored at the end of shader execution. |
| The values are packed to the specified format and stored as raw bits in |
| fragment output storage. |
| |
| By default, the format for each output is set to "implementation_defined", |
| and the underlying implementation will make a decision about how to |
| store it. If any output is set to a format other than implementation_- |
| defined, all formats must be specified. |
| |
| The output-format-qualifier format must match the base type and the |
| number of components of the variable declaration. It is a compile-time |
| error to declare a user-defined output variable where the format qualifier |
| does not match the variable type and the number of components. |
| |
| If EXT_pixel_local_storage2 is enabled, the format of every user-defined |
| fragment output variable should be specified in order to use pixel local |
| storage blocks. Any outputs set as implementation_defined (the default) |
| behave as if consuming all available local storage, leaving no space for |
| pixel local variables, causing a compile time error if pixel local storage |
| blocks also exist in the shader. |
| |
| The specified output-format-qualifier does not need to be constant |
| between shader invocations, but any resolves to the final framebuffer will |
| treat the data as being of the format specified on the active frame- |
| buffer's color attachment rather than the shader defined format. This |
| implies that color attachment values are undefined if the format of the |
| color attachment does not match the format specified in the shader. The |
| number of user-defined outputs and the size specified by their format |
| qualifier must remain consistent between shader invocations, or the values |
| will be undefined. |
| |
| Each user-defined fragment output variable uses memory local to the |
| shading processor. Each format takes up a predetermined number of bytes |
| of storage, as specified in the table below. |
| |
| |----------------|-------| |
| | Format | Bytes | |
| |----------------|-------| |
| | r8 | 4 | |
| | r8ui | 4 | |
| | r8i | 4 | |
| | r16ui | 4 | |
| | r16i | 4 | |
| | r32ui | 4 | |
| | r32i | 4 | |
| | rg8 | 4 | |
| | rg8ui | 4 | |
| | rg8i | 4 | |
| | rg16ui | 4 | |
| | rg16i | 4 | |
| | rg32ui | 8 | |
| | rg32i | 8 | |
| | rgb8 | 4 | |
| | rgb565 | 4 | |
| | rgba8 | 4 | |
| | srgb8_a8 | 4 | |
| | rgb5_a1 | 4 | |
| | rgba4 | 4 | |
| | rgb10_a2 | 4 | |
| | rgba8ui | 4 | |
| | rgba8i | 4 | |
| | rgb10_a2ui | 4 | |
| | rgba16ui | 8 | |
| | rgba16i | 8 | |
| | rgba32ui | 16 | |
| | rgba32i | 16 | |
| | r32f | 4 | |
| | rg32f | 8 | |
| | r11f_g11f_b10f | 4 | |
| | rgba32f | 16 | |
| | r16f | 4 | |
| | rg16f | 4 | |
| | rgb16f | 8 | |
| | rgba16f | 8 | |
| |----------------|-------| |
| |
| The total amount of memory used by a pixel local storage block or a user- |
| defined fragment output can be determined by the size of each variable's |
| format as in the equation below. n is the number of pixel local storage |
| members or output variables in each case. |
| |
| n |
| \¯ |
| /_ i = sizeof(format-qualifier) |
| i=0 |
| |
| The total combined amount of memory used by fragment outputs and pixel |
| local storage can be worked out simply via the following: |
| |
| total memory = sizeof(pixel local storage) + sizeof(fragment outputs)" |
| |
| The total number of bytes of fragment output local storage available is |
| specified by the value of the implementation-dependent constant |
| gl_MaxShaderCombinedLocalStorageSizeEXT. A compile-time error will be |
| generated if the declared outputs use more storage than this value. |
| |
| An implementation may choose to subdivide the amount of local storage into |
| a region for fast access and a region for normal access. As many local |
| variables as possible are allocated into the fast access region before any |
| are allocated into the normal access. Pixel local variables are |
| prioritized and are fully allocated into combined local storage before any |
| fragment output variables are allocated. The number of total bytes |
| available for fast access is specified by the value of the implementation- |
| dependent constant gl_MaxShaderCombinedLocalStorageFastSizeEXT. This value |
| will always be less than or equal to the total amount of combined local |
| storage." |
| |
| In Section 4.3.8.4 ("Pixel Local Block Layout Qualifiers"), add the following |
| |
| (add the following to the list of layout qualifiers for pixel local storage |
| variables) |
| float-pixel-local-format-qualifier |
| rg32f |
| rgba32f |
| rgba16f |
| |
| int-pixel-local-format-qualifier |
| rgba16i |
| r32i |
| rg32i |
| rgba32i |
| |
| uint-pixel-local-format-qualifier |
| rg32ui |
| rgba16ui |
| rgba32ui |
| |
| (add to the end of the description of the pixel local block layout qualifiers) |
| |
| "The size of each pixel local format qualifier is equivalent to that |
| specified for the output format qualifiers in section 4.3.8.2." |
| |
| Additions to Chapter 6 of the OpenGL ES Shading Language Specification |
| |
| In Section 6.4 (Jumps), change the sentence about the discard keyword that |
| currently reads: |
| |
| 'This keyword causes the fragment to be discarded and no updates to the |
| framebuffer will occur.' |
| |
| to: |
| |
| 'This keyword causes the fragment to be discarded and no updates to the |
| framebuffer or any pixel local storage variables will occur.' |
| |
| Additions to Chapter 7 of the OpenGL ES Shading Language Specification |
| |
| In Section 7.3 (Built-In Constants), add new entries: |
| |
| const mediump int gl_MaxShaderCombinedLocalStorageFastSizeEXT = 16 |
| const mediump int gl_MaxShaderCombinedLocalStorageSizeEXT = 16 |
| |
| Examples |
| (1) G-buffer creation pass |
| |
| #version 300 es |
| #extension GL_EXT_shader_pixel_local_storage2 : enable |
| |
| varying vec2 coord; |
| varying vec3 normal; |
| uniform sampler2D albedo_metallicness_texture; |
| uniform sampler2D roughness_texture; |
| |
| uniform float roughness; |
| uniform float albedo; |
| uniform vec3 metallicness; |
| |
| __pixel_localEXT FragDataLocal { |
| layout (r32f) highp float depth; |
| layout (rgba8ui) highp vec4 normal_roughness; |
| layout (rgba8ui) highp vec4 albedo_metallicness; |
| } gbuf; |
| |
| void main() |
| { |
| // Write to pls values |
| gbuf.depth = gl_FragCoord.z; |
| gbuf.normal_roughness = vec4(normal, texture2d(roughness_texture).r); |
| gbuf.albedo_metallicness = texture2d(albedo_metallicness_texture, coord); |
| } |
| |
| (2) Light accumulation step (multiple lights can hit the same pixel) |
| |
| #version 300 es |
| #extension GL_EXT_shader_pixel_local_storage2 : enable |
| |
| uniform vec4 light_position; |
| |
| __pixel_localEXT FragDataLocal { |
| layout (r32f) highp float depth; |
| layout (rgba8ui) highp vec4 normal_roughness; |
| layout (rgba8ui) highp vec4 albedo_metallicness; |
| } gbuf; |
| |
| layout(location = 0, rgba10_a2) out highp vec4 accumulationBuffer; |
| |
| void main() |
| { |
| // Accumulate to the accumulationBuffer, without invalidating the pls data |
| accumulationBuffer = do_lighting(gbuf.depth, gbuf.normal_roughness, gbuf.albedo_metallicness, light_position); |
| } |
| |
| Issues |
| |
| (1) Should there be a way to dumping the PLS contents to memory for |
| debugging purposes? |
| |
| RESOLVED: Not in this extension. |
| |
| A couple of ways this could be supported: |
| A) Reuse ReadPixels. Allow a new combination of <format> and <type> |
| parameters, say, "SHADER_PIXEL_LOCAL_STORAGE" and UNSIGNED_INT. |
| B) Add a new function, say glReadPixelLocalStorage. This would be |
| as the above, except that the <format> and <type> parameters |
| would be implicit. |
| |
| Either approach would probably need a query function to determine |
| the amount of storage used, or a way to specify the amount of storage |
| to retrieve. |
| |
| (2) How are local storage values initialized? |
| |
| RESOLVED: Using ClearPixelLocalStorageuiEXT. |
| |
| EXT_shader_pixel_local_storage stated: |
| "All pixel local storage variables are guaranteed to be zero if |
| all color components of the framebuffer are set to zero." |
| |
| But with this extension, color data and pixel local storage are |
| distinct, so while this guarantee could be made, it may not be the |
| most efficient approach. |
| |
| This is solved by adding an explicit API: ClearPixelLocalStorageuiEXT. |
| |
| (3) Is the proposed resolution to (2) a compatibility break with EXT_- |
| shader_pixel_local_storage? |
| |
| RESOLVED: No. |
| |
| EXT_shader_pixel_local_storage guaranteed that the pixel local |
| storage was initialized to zero if all color components of the |
| framebuffer were set to zero. Given that this only applied to the |
| aliased pixel local storage in the original extension, and aliasing |
| is no longer present, the resolution is not a compatibility break, |
| as the spec itself is a compatibility break. |
| |
| (4) Do we need to know the render target count at compile time? |
| |
| RESOLVED. |
| |
| Yes. Implementations will need to know the render target count and |
| the storage size of each render target in order to allocate and |
| partition the pixel local storage. |
| |
| (5) Do we want to explicitly alias some pixel local storage variables onto |
| color rendertargets? |
| |
| RESOLVED. |
| |
| See Issue 7. |
| |
| (6) Should the maximum PLS storage queries be per framebuffer? |
| |
| RESOLVED: No - glGetInteger with a MAX_COMBINED_LOCAL_STORAGE_SIZE. |
| |
| Dynamic, per framebuffer, queries will have all necessary information, |
| but applications can not access this information until the framebuffer |
| object has been created, which seems undesirable. |
| |
| EXT_shader_pixel_local_storage specified static queries for the |
| amount of available pixel local storage. With this extension, the |
| semantics of that query changes since color and pixel local storage |
| no longer alias. Given that change, we need a query for the |
| total amount of storage available for pixel local storage and color |
| attachments. |
| |
| (7) Do we want to keep the aliasing of pixel local storage variables onto |
| color rendertargets? |
| |
| RESOLVED: No |
| |
| The main benefit of aliasing was that it potentially allows more (fast) |
| local storage. Instead of sharing the local storage between color |
| render targets and pixel local storage variables, all local storage can |
| be allocated to pixel local storage initially. In this case, we expect |
| all pixel local storage to be resolved (and become undefined) when any |
| user-defined color output is written to (and vice versa). |
| |
| However, given the existance (and support) of framebuffer fetch, it |
| seems unnecessary to continue using this - the same effect can be |
| achieved with side-by-side framebuffer fetch and pixel local storage, |
| without the drawback of requiring explicit resolves. |
| |
| (8) Do we want the full range of framebuffer formats to work with this |
| extension? If so, how do we define the sizes of, say rgb565? Does it |
| take up 16bits or is it assumed to be padded to 32 bits? |
| |
| RESOLVED: Add all formats, but storage for all formats is padded |
| to multiples of 32-bits. |
| |
| (9) Do the usual per-fragment operations apply to color outputs in this |
| extension? |
| |
| RESOLVED: Yes. All values written to user-defined color outputs pass |
| through per-fragment operations (including blending, alpha to coverage, |
| etc.) as normal. |
| |
| Revision History |
| |
| Revision 0.13, 28/10/2015 (Tobias Hector) |
| Added enumerant values |
| |
| Revision 0.12, 08/10/2015 (Tobias Hector) |
| Added PLS interactions with the discard keyword. |
| |
| Revision 0.11, 07/10/2015 (Tobias Hector) |
| Specified that PLS variables are undefined if they're not written to, |
| unless they were defined as both input and output (in which case they |
| are preserved). |
| |
| Revision 0.10, 13/07/2015 (Tobias Hector) |
| Re-added error about multisampled rendering |
| |
| Revision 0.9, 10/07/2015 (Tobias Hector) |
| Corrected ClearPixelLocalStorageuiEXT to accept a uint value, instead of int |
| Changed language about combined local storage to be clearer. |
| |
| Revision 0.8, 03/07/2015 (Tobias Hector) |
| Added wording that disallows the default framebuffer becoming incomplete. |
| Added language allowing NULL to be passed into ClearPixelLocalStorageuiEXT |
| Added word alignment to size parameter of FramebufferPixelLocalStorageSizeEXT |
| |
| Revision 0.7, 02/07/2015 (Tobias Hector) |
| Folded in updates from external review. |
| Added interactions with EXT_color_buffer_float and half_float |
| Added multi-word pixel local storage formats |
| Added framebuffer pixel local storage size specification |
| Added framebuffer completeness checks |
| Updated issues list to match updated spec. |
| |
| Revision 0.6, 03/10/2014 (Jan-Harald Fredriksen) |
| Extended padding for all color outputs to 4 bytes. |
| Resolved and updated proposed resolutions for several issues. |
| Added Issue 10 and Issue 11. |
| |
| Revision 0.5, 25/09/2014 (Jan-Harald Fredriksen) |
| Integrated a subset of IMG_fragment_output_format. |
| |
| Revision 0.4, 20/06/2014 (Jan-Harald Fredriksen) |
| Minor wording changes. |
| |
| Revision 0.3, 27/05/2014 (Jan-Harald Fredriksen) |
| Adding Issue 7. |
| |
| Revision 0.2, 18/05/2014 (Jan-Harald Fredriksen) |
| Adding some issues and a new query. |
| |
| Revision 0.1, 21/03/2014 (Jan-Harald Fredriksen) |
| Second internal draft. |
| Adding missing changes compared to EXT_shader_pixel_local_storage. |
| Added proposed resolution of Issue 1. |
| Added Issue 2, Issue 3, and Issue 4. |
| |
| Revision 0, 19/11/2013 (Jan-Harald Fredriksen) |
| First internal draft. |
