AvaloniaUI
/
angle
зеркало из https://github.com/AvaloniaUI/angle.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
angle/extensions/EXT_blend_func_extended.txt

772 строки
33 KiB
Plaintext
Исходник Постоянная ссылка Ответственный История

Name
EXT_blend_func_extended
Name Strings
GL_EXT_blend_func_extended
Contact
Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Contributors
Daniel Koch, NVIDIA
Slawomir Grajewski, Intel
Chris Dalton, NVIDIA
Brian Salomon, Google
From ARB_blend_func_extended...
Graham Sellers, AMD
Mark Young, AMD
Nick Haemel, AMD
Pierre Boudier, AMD
Mais Alnasser, AMD
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
Ian Stewart, NVIDIA
Jon Leech, Khronos
Status
Draft, almost complete
Version
Last Modified Date: July 29, 2015
Revision: 5
Number
XXX
Dependencies
This extension is written against the OpenGL ES 3.1 (June 4, 2014)
specification, but can apply to earlier versions back to ES 2.0.
GLSL version 300 and 310 language is written against The OpenGL ES
Shading Language (July 11, 2012).
GLSL version 100 language is written against The OpenGL ES Shading
Language (May 12, 2009).
The NV_draw_buffers and EXT_draw_buffers extensions trivially affect
the definition of this extension.
The EXT_draw_buffers_indexed extension affects the definition of
this extension.
Overview
This extension provides an ES version of the ARB_blend_func_extended
functionality.
Traditional OpenGL includes fixed-function blending that combines
source colors with the existing content of a render buffer in
a variety of ways. A number of extensions have enhanced this
functionality by adding further sources of blending weights and
methods to combine them. However, the inputs to the fixed-function
blending units are constrained to a source color (as output from
fragment shading), destination color (as the current content of the
frame buffer) or constants that may be used in their place.
This extension adds new blending functions whereby a fragment
shader may output two colors, one of which is treated as the
source color, and the other used as a blending factor for either
source or destination colors. Furthermore, this extension increases
orthogonality by allowing the SRC_ALPHA_SATURATE function to be used
as the destination weight.
Because of the limitations of the OpenGL ES 2.0 shading language,
new built-in variables (gl_SecondaryFragColorEXT,
gl_SecondaryFragDataEXT) are added to the ES 1.00 shading language
rather than introduce more complex features for user-defined fragment
outputs. Because such built-in variable are deprecated in ES 3.0,
these variables are NOT available in the OpenGL ES 3.xx shading
language verisons.
IP Status
No known IP claims.
New Procedures and Functions
void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
uint index, const char * name);
int GetFragDataIndexEXT(uint program, const char * name);
void BindFragDataLocationEXT(uint program, uint colorNumber, const char * name)
int GetProgramResourceLocationIndexEXT(uint program, enum programInterface, const char *name);
New Tokens
Accepted by the <src> and <dst> parameters of BlendFunc and
BlendFunciEXT, and by the <srcRGB>, <dstRGB>, <srcAlpha> and <dstAlpha>
parameters of BlendFuncSeparate and BlendFuncSeparateiEXT:
SRC1_COLOR_EXT 0x88F9
SRC1_ALPHA_EXT 0x8589 // OpenGL 1.5 token value
ONE_MINUS_SRC1_COLOR_EXT 0x88FA
ONE_MINUS_SRC1_ALPHA_EXT 0x88FB
SRC_ALPHA_SATURATE_EXT 0x0308
Accepted in the <props> array of GetProgramResourceiv:
LOCATION_INDEX_EXT 0x930F
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
and GetFloatv:
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT 0x88FC
Additions to Chapter 7 of the OpenGL ES 3.1 Specification (Programs and
Shaders)
Add a row to table 7.2 "GetProgramResourceiv properties and supported
interfaces" (page 82):
Property Supported Interfaces
------------------ --------------------
LOCATION_INDEX_EXT PROGRAM_OUTPUT
Modify section 7.3.1.1 "Naming Active Resources" subsection to include
after the LOCATION paragraph (page 84):
"For the property LOCATION_INDEX_EXT, a single integer identifying the
fragment color index of an active fragment shader output variable
is written to params. If the active variable is not an output for a
fragment shader, the value -1 will be written to params."
Modify (page 87) the paragraph introducing GetProgramResourceLocation
to begin:
"The commands
int GetProgramResourceLocation( uint program,
enum programInterface, const char *name );
int GetProgramResourceLocationIndexEXT( uint program,
enum programInterface, const char *name );
return the location or the fragment color index, respectively,
assigned to the variable named name in interface programInterface
of program object program."
Change the ending of the same paragraph to read:
"For GetProgramResourceLocationIndexEXT, programInterface must be
PROGRAM_OUTPUT. The value -1 will be returned by either command if
an error occurs, if name does not identify an active variable on
programInterface, or if name identifies an active variable that
does not have a valid location assigned, as described above. The
locations returned by these commands are the same locations returned
when querying the LOCATION and LOCATION_INDEX resource properties."
Change the next paragaph to begin:
"A string provided to GetProgramResourceLocation or
GetProgramResourceLocationIndexEXT is considered to match an active
variable if ..."
Change the last paragraph of the section (page 88) to read:
... "If the string specifies an element of an array variable,
GetProgramResourceLocation and GetProgramResourceLocationIndexEXT
return the location or fragment color index assigned to that
element. If it specifies the base name of an array, it identifies
the resources associated with the first element of the array."
Additions to Chapter 14 of the OpenGL ES 3.1 Specification (Programmable
Fragment Processing)
Modify section 14.2.3 "Shader Outputs" subsection to include:
"The binding of a user-defined varying out variable to a fragment color number
can be specified explicitly. The command
void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
uint index, const char * name);
specifies that the varying out variable name in <program> should
be bound to fragment color <colorNumber> when the program is next
linked. <index> may be zero or one to specify that the color
be used as either the first or second color input to the blend
equation, respectively, as described in Section 15.1.5 (Blending).
If <name> was bound previously, its assigned binding is replaced
with colorNumber. <name> must be a null-terminated string. The error
INVALID_VALUE is generated if <colorNumber> is equal or greater
than the value of MAX_DRAW_BUFFERS and <index> is zero,
or if <colorNumber> is equal or greater than the value of
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT and <index> is greater than or
equal to one. The command
void BindFragDataLocationEXT(uint program, uint colorNumber,
const char * name)
is equivalent to calling BindFragDataLocationIndexedEXT with the
same values for <program>, <colorNumber> and <name>, and with <index>
set to zero.
When a program is linked, any varying out variables without
a binding specified through BindFragDataLocationIndexedEXT or
BindFragDataLocationEXT will automatically be bound to fragment
colors and indices by the GL. All such assignments will use color
indices of zero. Such bindings can be queried using the commands
GetFragDataLocation and GetFragDataIndexEXT. Output binding
assignments will cause LinkProgram to fail:
* if the number of active outputs is greater than the value of
MAX_DRAW_BUFFERS_EXT;
* if the program has an active output assigned to a location greater
than or equal to the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
and has an active output assigned an index greater than or equal
to one;
* if more than one varying out variable is bound to the same number
and index; or
* if the explicit binding assignments do not leave enough space
for the linker to automatically assign a location for a varying
out array, which requires multiple contiguous locations.
BindFragDataLocationIndexedEXT may be issued before any shader objects
are attached to a program object. Hence it is allowed to bind any
name (except a name starting with gl_) to a color number and index,
including a name that is never used as a varying out variable in
any fragment shader object. Assigned bindings for variables that
do not exist are ignored."
Add to end of section:
"The command
int GetFragDataIndexEXT(uint program, const char * name);
returns the index of the fragment color to which the variable <name>
was bound when the program object <program> was last linked. If
program has not been successfully linked, the error INVALID_OPERATION
is generated. If name is not a varying out variable, or if an error
occurs, -1 will be returned. The command is equivalent to
GetProgramResourceLocationIndex(program, PROGRAM_OUTPUT, name);"
Additions to Chapter 15 of the OpenGL ES 3.1 Specification (Writing
Fragments and Samples to the Framebuffer)
Modify section 15.1.5.2 "Blend Functions":
Change the first paragraph to read:
"The weighting factors used by the blend equation are determined by
the blend functions. There are four possible sources for weighting
factors. These are the constant color (Rc, Gc, Bc, Ac) (see
BlendColor, p. 211), the first source color (Rs0, Gs0, Bs0, As0),
the second source color (Rs1, Gs1, Bs1, As1), and the destination
color (the existing content of the draw buffer). Additionally the
special constants ZERO and ONE are available as weighting factors."
Modify Table 15.2 (RGB and ALPHA source and destination blend
functions ...) as follows
RGB Blend Factors Alpha Blend Factors
Value (Sr, Sg, Sb) or (Dr, Dg, Db) Sa or Da
----- ---------------------------- -------------------
ZERO (0, 0, 0) 0
ONE (1, 1, 1) 1
SRC_COLOR (Rs0, Gs0, Bs0) As0
ONE_MINUS_SRC_COLOR (1, 1, 1) - (Rs0, Gs0, Bs0) 1 - As0
DST_COLOR (Rd, Gd, Bd) Ad
ONE_MINUS_DST_COLOR (1, 1, 1) - (Rd, Gd, Bd) 1 - Ad
SRC_ALPHA (As0, As0, As0) As0
ONE_MINUS_SRC_ALPHA (1, 1, 1) - (As0, As0, As0) 1 - As0
DST_ALPHA (Ad, Ad, Ad) Ad
ONE_MINUS_DST_ALPHA (1, 1, 1) - (Ad, Ad, Ad) 1 - Ad
CONSTANT_COLOR (Rc, Gc, Bc) Ac
ONE_MINUS_CONSTANT_COLOR (1, 1, 1) - (Rc, Gc, Bc) 1 - Ac
CONSTANT_ALPHA (Ac, Ac, Ac) Ac
ONE_MINUS_CONSTANT_ALPHA (1, 1, 1) - (Ac, Ac, Ac) 1 - Ac
SRC_ALPHA_SATURATE (f, f, f) 1 New (for ES 2.x)
SRC1_COLOR_EXT (Rs1, Gs1, Bs1) As1 New
ONE_MINUS_SRC1_COLOR_EXT (1, 1, 1) - (Rs1, Gs1, Bs1) 1 - As1 New
SRC1_ALPHA_EXT (As1, As1, As1) As1 New
ONE_MINUS_SRC1_ALPHA_EXT (1, 1, 1) - (As1, As1, As1) 1 - As1 New
For ES 2.0, remove table's footnote saying (ES 3.x already has this
removed):
SRC_ALPHA_SATURATE is valid only for source RGB and alpha
blending functions.
Add the following subsections to Section 5.1.5 Blending, at the end
of the subsection 15.1.5.2 "Blend Functions":
"15.1.5.X Dual Source Blending and Multiple Draw Buffers
Blend functions that require the second color input, <Rs1, Gs1, Bs1,
As1> (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
ONE_MINUS_SRC1_ALPHA_EXT) may consume hardware resources that could
otherwise be used for rendering to multiple draw buffers. Therefore,
the number of draw buffers that can be attached to a frame buffer
may be lower when using dual-source blending.
The maximum number of draw buffers that may be attached to a
single frame buffer when using dual-source blending functions is
implementation dependent and can be queried by calling GetIntegerv
with the symbolic constant MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT. When
using dual-source blending, MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT should be
used in place of MAX_DRAW_BUFFERS_EXT to determine the maximum number
of draw buffers that may be attached to a single frame buffer. The
value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must be at least 1. If
the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT is 1, then dual-source
blending and multiple draw buffers cannot be used simultaneously.
If either blend function is set to one of the second source factors
(SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
ONE_MINUS_SRC1_ALPHA_EXT) for any draw buffer and any draw buffers
equal to or greater than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
have values other than NONE, the error INVALID_OPERATION is generated
by drawing commands.
15.1.5.Y Generation of Second Color Source for Blending
Rendering using any of the blend functions that consume the second
input color (SRC1_COLOR_EXT, ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT
or ONE_MINUS_SRC1_ALPHA_EXT) using a shader that does not output
a second source color will produce undefined results. To produce
input for the second source color, a shader must be used that outputs
a second source color.
When using a GLSL version 300 es or higher fragment shader with
dual-source blending functions, the color output varyings are bound
to the first (index 0) and second (index 1) inputs of a draw buffer
using BindFragDataLocationIndexedEXT as described in the "Shader
Outputs" subsection of Section 3.12.2 or by layout qualifiers for
location=/n/ and index=/m/. Data written to the first of these outputs
becomes the first source color input to the blender (corresponding
to SRC_COLOR and SRC_ALPHA). Data written to the second of these
outputs generates the second source color input to the blender
(corresponding to SRC1_COLOR_EXT and SRC1_ALPHA_EXT).
Alternatively if the GLSL version 100 fragment shader is used (where
user-defined color outputs are unsupported, hence a user-defined
color output is not available for BindFragDataLocationIndexEXT), the
gl_FragColor and gl_SecondaryFragColorEXT fragment outputs correspond
to the first and second source color respectively. Similarly the
gl_FragData and gl_SecondaryFragDataEXT fragment output arrays
correspond to the first and second source color respectively of each
color buffer output.
If the second color input to the blender is not written in the
shader, or if no output is bound to the second input of a blender,
the result of the blending operation is not defined.
Other shading languages may define similar methods for producing
the first and second color inputs to blending equations."
Additions to the OpenGL ES Shading Language 1.00 Specification
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_blend_func_extended : <behavior>
where <behavior> is as specified in section 3.4.
A new preprocessor #define is added to the OpenGL ES Shading Language:
#define GL_EXT_blend_func_extended 1
Modify paragraphs in section 7.2 "Fragment Shader Special Variables" as follows:
First paragraph, second sentence:
"Fragment shaders output values to the OpenGL ES pipeline using
the built-in variables gl_FragColor, gl_SecondaryFragColorEXT,
gl_FragData, and gl_SecondaryFragDataEXT, unless the discard keyword
is executed."
Second paragraph, first sentence:
"It is not a requirement for the fragment shader to write to
either gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData, or
gl_SecondaryFragDataEXT."
Add after the fourth paragraph:
"Writing to gl_SecondaryFragColorEXT specifies a second fragment color
that will be used by the subsequent fixed functionality pipeline for
dual source blending. If subsequent fixed functionality consumes the
second fragment color and an execution of a fragment shader does
not write a value to gl_SecondaryFragColorEXT then the secondary
fragment color consumed is undefined."
Add after the fifth paragraph:
"The variable gl_SecondaryFragDataEXT is an array. Writing to
gl_SecondaryFragDataEXT[n] specifies the secondary fragment data that
will be used by the subsequent fixed functionality pipeline for data n
for dual source blending. If subsequent fixed functionality consumes
secondary fragment data and an execution of a fragment shader does
not write a value to it, then the secondary fragment data consumed
is undefined."
Modify the sixth paragraph to read:
"If a shader statically assigns a value to gl_FragColor or
gl_SecondaryFragColorEXT, it may not assign a value to any
element of gl_FragData or gl_SecondaryFragDataEXT. If a shader
statically writes a value to any element of gl_FragData or
gl_SecondaryFragDataEXT, it may not assign a value to gl_FragColor
or gl_SecondaryFragColorEXT. That is, a shader may assign values to
either the set of gl_FragColor and gl_SecondaryFragColorEXT or the
set of gl_FragData and gl_SecondaryFragDataEXT, but not both."
Modify the eighth paragraph to read:
"If a shader executes the discard keyword, the fragment is discarded,
and the values of gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData,
and gl_SecondaryFragDataEXT become irrelevant."
Add these built-in variable to the list "accessible from a fragment shader":
mediump vec4 gl_SecondaryFragColorEXT;
mediump vec4 gl_SecondaryFragDataEXT[gl_MaxDualSourceDrawBuffersEXT];
Add to section 7.4 "Built-In Constants" the following constant:
const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
Additions to the OpenGL ES Shading Language 3.00 and 3.10 Specification
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_blend_func_extended : <behavior>
where <behavior> is as specified in section 3.4.
A new preprocessor #define is added to the OpenGL ES Shading Language:
#define GL_EXT_blend_func_extended 1
Modify section 4.4.2 "Output Layout Qualifiers":
Change the second paragraph to read:
"Fragment shaders allow output layout qualifiers only on the interface
qualifier out. The layout qualifier identifier for fragment shader
outputs is:
layout-qualifier-id
location = integer-constant
index = integer-constant
Each of these qualifiers may appear at most once. If index is
specified, location must also be specified. If index is not
specified, the value 0 is used."
Add an additional example to the end of the fourth paragraph's example:
"And,
layout(location = 3, index = 1) out vec4 factor;
will establish that the fragment shader output factor is copied out
to fragment color 3 as the second (index one) input to the blend
equation."
Change the first sentence of the second to last paragraph to read:
"If there is more than one fragment output, the location must
be specified for all outputs unless the EXT_blend_func_extended
extension is enabled in which case more than one unassigned fragment
output locations are allowed though they must be assigned to unique
locations assigned with glBindFragDataLocationIndexedEXT prior to
linking."
Add to section 7.4 "Built-In Constants" the following constant:
const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
Dependencies on OpenGL ES 3.0
If OpenGL ES 3.0 or higher is not supported (meaning OpenGL ES 2.0
support only), remove all references to the functions:
BindFragDataLocationIndexedEXT
GetFragDataIndexEXT
BindFragDataLocationEXT
GetProgramResourceLocationIndexEXT
Also ignore the additions to chapters 7 and 14 and the paragraph in
section 15.1.5.Y related to GLSL version 300 es or higher.
When OpenGL ES 3.0 or higher, the "Additions to the OpenGL ES
Shading Language 1.00 Specification" applies to the version 100
shading language, but not later versions.
Dependencies on OpenGL ES 3.1
If OpenGL ES 3.1 or higher is not supported (meaning OpenGL ES 3.0
or earlier), remove all references to the function
GetProgramResourceLocationIndexEXT
because program resource queries are added by ES 3.1.
Also ignore the additions to chapter 7.
Dependencies on EXT_draw_buffers or NV_draw_buffers
Using dual-source blending functions may consume additional outputs
from hardware shading units and therefore can reduce the number
of draw buffers that may be attached to a single frame buffer when
dual-source blending functions are enabled. In this case, the value
of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT may be less than the value of
MAX_DRAW_BUFFERS_EXT. If EXT_draw_buffers or NV_draw_buffers is not
supported then the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must
be 1. Furthermore, the discussion in the subsection entitled "Dual
Source Blending and Multiple Draw Buffers" may be discarded.
Dependencies on EXT_draw_buffers_indexed
If EXT_draw_buffers_indexed is not supported, all references to
BlendFunciEXT and BlendFuncSeparateiEXT should be removed. In this
case, the blend functions for all attached draw buffers will be the
same.
Errors
The error INVALID_OPERATION is generated by Begin or any
procedure that implicitly calls Begin if any draw buffer has a
blend function requiring the second color input (SRC1_COLOR_EXT,
ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT or ONE_MINUS_SRC1_ALPHA_EXT),
and a framebuffer is bound that has more than the value of
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT-1 active color attachments.
New State
None
While no changes to table 20.12 (Pixel Operations) are strictly
necessary, new enumerations are supported for the BLEND_SRC_RGB,
BLEND_SRC_ALPHA, BLEND_DST_RGB, and BLEND_DST_ALPHA state to support
SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, and
ONE_MINUS_SRC1_ALPHA_EXT (and for ES 2.0, SRC_ALPHA_SATURATE_EXT).
New Implementation Dependent State
Get Value Type Get Command Minimum Value Description Sec.
--------- ---- ----------- ------------- ------------------- ------
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 15.1.5
active draw buffers
when using dual-source
blending
Example Use Cases
There are several potential uses for this functionality. A first
example is in the implementation of sub-pixel accurate font rendering
algorithms. Given a known layout of pixel elements (red, green
and blue components), coverage may be calculated independently for
each element and passed to the blender in the second source color
as a per-channel opacity. To use this mode, use the following blend
functions:
glBlendFunc(GL_SRC1_COLOR_EXT, GL_ONE_MINUS_SRC1_COLOR_EXT);
As a second example, consider a partially reflective colored glass
window. It will attenuate light passing through it, and reflect
some of the light that strikes it. Using an appropriate combination
of functions, this effect may be simulated in a single pass using
only fixed-function blending hardware. In this case, the following
blend functions may be used:
glBlendFunc(GL_SRC_ALPHA, GL_SRC1_COLOR_EXT);
Issues
0. What should this extension be named?
RESOLVED: EXT_blend_func_extended, matching the name of
ARB_blend_func_extended upon which this extension is based but
providing a multi-vendor extension for ES implementations.
1. Is this extension compatible with the ARB_blend_func_extended
version?
RESOLVED: Yes. This extension is 100% functionally identical to
ARB_blend_func_extended but for the ES 2.x and 3.x APIs.
The token values are _EXT suffixed but have the same values as
the ARB_blend_func_extended tokens.
Philosophically if this extension is going for 100% parity and
functionality with ARB_blend_func_extended, it should simply add
all the stuff in ARB_blend_func_extended...
2. Should the next commands be EXT suffixed?
RESOLVED: Yes. This is not an OES extension.
This means source code coming from a desktop environment should
call eglGetProcAddress on function names with the EXT suffix.
However because extension functions are called through function
pointers, this is only a minor change isolated to function pointer
initialization.
2. Should this extension allow ES 2.0 contexts to use
GL_SRC_ALPHA_SATURATE for the destination blend function?
RESOLVED: Yes, the ARB_blend_func_extended extension adds support
for using GL_SRC_ALPHA_SATURATE as the destination factor as "bonus"
functionality.
ES 3.x already allows GL_SRC_ALPHA_SATURATE for the destination
factor so this additional functionality is new only to ES 2.0 contexts
supporting this extension.
We expect no GPU hardware capable of dual-source blending to not
also support GL_SRC_ALPHA_SATURATE as the destination factor.
3. Should this extension provide the glBindFragDataLocation and
glBindFragDataLocationIndexed functionality?
RESOLVED: Yes. With EXT suffixes.
4. Should this really be OES_blend_func_extended?
RESOLVED: Go with EXT is for expediency.
Additionally this extension supports functionality such
GL_SRC_ALPHA_SATURATE that all desktop GPU hardware is assumed to
have. ES-only vendors might not want this in an OES extension.
The same could be said for the glBindFragDataLocation* functionality.
5. Does this extension need an interaction with
OES_blend_equation_separate?
RESOLVED: No, that's an ES 1.1 extension. ES 2.0 and on all support
separate blend functions.
6. Are there any OpenGL ES Shading Language interactions?
RESOLVED: Yes, to use this extension, a #extension line will be needed
in the shader requesting the EXT_blend_func_extended functionality.
Example:
#extension GL_EXT_blend_func_extended : require
The ARB_blend_func_extended functionality does NOT require a special
#extension line to use its functionality because the ARB version
relies on existing GLSL functionality that allows for multiple
fragment outputs as part of supporting multiple render targets.
In the ARB version, then glBindFragDataLocationIndexed can bind
these unassigned locations to different source output colors.
But GLSL OpenGL ES 3.00 and 3.10 both explicitly preclude more than
one fragment shader output with an unassigned location. Hence a
#extension is needed to relax this error condition. And then this
extension's glBindFragDataLocationIndexedEXT must be used to assign
locations as necessary.
7. Can the indexed location be assigned explicitly in the shader?
RESOLVED: Yes, for ES 3.x shaders where the GLSL ES 3.x supports
layout qualifiers. ES 2.0 does not support the layout qualifier or
user-defined fragment outputs.
8. Should both the layout qualifier mechanism and the
glBindFragDataLocationIndexed-style API for specifying the index of
a user-defined fragment shader output be supported?
RESOLVED: Yes, both should be supported. This makes it easier
for existing applications to port to ES 3.0 as both mechanisms are
available.
FYI: The "layout(location=0,index=1)" type syntax for dual-source
blending was introduced to OpenGL in GLSL 3.30 and 4.00 in
conjunction with OpenGL 3.3 and 4.0 respectively. The original
ARB_blend_func_extended was written with respect to OpenGL 3.2 and
intended to support dual-source blending without the need to extend
the GLSL language by instead supporting assignment if the fragment
output index via glBindFragDataLocationIndexed.
9. How to support OpenGL ES 2.0 where user-defined fragment shader
outputs are not supported?
RESOLVED: Introduce new gl_SecondaryFragColorEXT and
gl_SecondaryFragDataEXT built-in variables for specifying the second
source color.
These built-ins are only available in the ES 1.00 shader language
version.
It is important to provide an ES 2.0 mechanism because WebGL 1.0 is
based on ES 2.0. Chrome's internal command buffer mechanism is also
based around ES 2.0 and Skia intends to use this extension.
This includes adding a gl_MaxDualSourceDrawBuffersEXT
implementation-dependent constant.
10. Does the version 100 syntax (gl_SecondaryFragColorEXT,
gl_SecondaryFragDataEXT) work in an ES 3.0 context?
RESOLVED: Yes. For compatibility reasons, an ES 3.0 context
advertising EXT_blend_func_extended must support the built-ins for
the fragment shader secondary color outputs.
11. How many elements should be in the gl_SecondaryFragDataEXT array?
RESOLVED: The gl_SecondaryFragDataEXT array should have as
many elements as the GLSL built-in implementation constant
gl_MaxDualSourceDrawBuffersEXT which should be the value of the
context's GL_MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT implementation-dependent
constant.
This means the number of elements in gl_SecondaryFragDataEXT is
different than the number of gl_FragData elements.
12. What precision should the gl_SecondaryFragColorEXT and
gl_SecondaryFragDataEXT be?
RESOLVED: mediump. This is consistent with gl_FragColor and
gl_FragData.
13. Should gl_MaxDualSourceDrawBuffersEXT be exposed in both ES 2.0
(where it sizes the gl_SecondaryFragDataEXT array) and also 3.x
contexts (where there is no fixed-function array)?
RESOLVED: Implementation-wise, it is easiest to expose this
implementation-dependent constant for all ES contexts.
As a practical matter, we don't expect any implementations will
advertise any value other than 1 for this constant.
Note: There is no implementation-dependent GLSL constant comparable
to gl_MaxDualSourceDrawBuffersEXT in ARB_blend_func_extended
(or OpenGL 3.3/4.0 introducing the ARB_blend_func_extended
functionality).
14. Any more issues?
RESOLVED: See the issues in the ARB_blend_func_extended
specification. This extension resolves those issues to match the
ARB extension version.
Revision History
Rev. Date Author Changes
---- -------- --------- -----------------------------------------
1 05/22/15 mjk Initial revision.
2 07/06/15 mjk Proper ES 2.0 interactions; complete.
3 07/08/15 mjk Feedback from Brian
4 07/08/15 mjk Feedback from Daniel
5 07/29/15 mjk ES 3.x contexts (as well as 2.0) expose
gl_MaxDualSourceDrawBuffersEXT
Ссылка в новой задаче Показать git blame Копировать постоянную ссылку