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