skia / external / github.com / KhronosGroup / OpenGL-Registry / refs/heads/310-issue / . / extensions / ARB / ARB_derivative_control.txt

Name | |

ARB_derivative_control | |

Name Strings | |

GL_ARB_derivative_control | |

Contact | |

John Kessenich (cepheus 'at' frii.com) | |

Contributors | |

Bill Licea-Kane, Qualcomm | |

Notice | |

Copyright (c) 2014 The Khronos Group Inc. Copyright terms at | |

http://www.khronos.org/registry/speccopyright.html | |

Specification Update Policy | |

Khronos-approved extension specifications are updated in response to | |

issues and bugs prioritized by the Khronos OpenGL Working Group. For | |

extensions which have been promoted to a core Specification, fixes will | |

first appear in the latest version of that core Specification, and will | |

eventually be backported to the extension document. This policy is | |

described in more detail at | |

https://www.khronos.org/registry/OpenGL/docs/update_policy.php | |

Status | |

Complete. | |

Approved by the ARB on June 26, 2014. | |

Ratified by the Khronos Board of Promoters on August 7, 2014. | |

Version | |

Last Modified Date: 7-Aug-2014 | |

Revision: 3 | |

Number | |

ARB Extension #163 | |

Dependencies | |

This extension is written against the GLSL 4.40 Specification. | |

OpenGL 4.0 and GLSL 4.00 or later are required. | |

Overview | |

This extension provides control over the spacial granularity at which the | |

underlying implementation computes derivatives. | |

For example, for the coarse-granularity derivative, a single x derivative | |

could be computed for each 2x2 group of pixels, using that same derivative | |

value for all 4 pixels. For the fine-granularity derivative, two | |

derivatives could be computed for each 2x2 group of pixels; one for the top | |

row and one for the bottom row. Implementations vary somewhat on how this | |

is done. | |

To select the coarse derivative, use: | |

dFdxCoarse(p) | |

dFdyCoarse(p) | |

fwidthCoarse(p) | |

To select the fine derivative, use: | |

dFdxFine(p) | |

dFdyFine(p) | |

fwidthFine(p) | |

To select which ever is "better" (based on performance, API hints, or other | |

factors), use: | |

dFdx(p) | |

dFdy(p) | |

fwidth(p) | |

This last set is the set of previously existing built-ins for derivatives, | |

and continues to work in a backward compatible way. | |

IP Status | |

No known IP claims. | |

New Procedures and Functions | |

None. | |

New Tokens | |

None. | |

Modifications to the OpenGL Specification | |

None. | |

Additions to the OpenGL Shading Language | |

Including the following line in a shader can be used to control the | |

language features described in this extension: | |

#extension GL_ARB_derivative_control : <behavior> | |

where <behavior> is as specified in section 3.3. | |

New preprocessor #defines are added to the OpenGL Shading Language: | |

#define GL_ARB_derivative_control 1 | |

Section 4.3.3 Constant Expressions | |

Update the following sentence: | |

"The following built-in functions must return 0 when evaluated with an | |

argument that is a constant expression. | |

dFdx | |

dFdy | |

fwidth | |

dFdxCoarse | |

dFdyCoarse | |

fwidthCoarse | |

dFdxFine | |

dFdyFine | |

fwidthFine" | |

Section 8.13.1 Derivative Functions | |

After "dFdy is approximated similarly, with y replacing x.", add the | |

following: | |

"With multi-sample rasterization, for any given fragment or sample, | |

either neighboring fragments or samples may be considered. | |

"It is typical to consider a 2x2 square of fragments or samples, and | |

compute independent dFdxFine per row and independent dFdyFine per column, | |

while computing only a single dFdxCoarse and a single dFdyCoarse for the | |

entire 2x2 square.Thus, all second-order coarse derivatives, e.g., | |

dFdxCoarse(dFdxCoarse(x)), may be 0, even for non-linear arguments. | |

However, second-order fine derivatives, e.g., dFdxFine(dFdxFine(x)) | |

will properly reflect the difference between the independent fine | |

derivatives computed within the 2x2 square." | |

Remove the following paragraphs: | |

"A GL implementation may use the above or other methods to perform the | |

calculation, subject to the following conditions: | |

"The method may use piecewise linear approximations. Such linear | |

approximations imply that higher order derivatives, dFdx(dFdx(x)) and | |

above, are undefined. | |

"The method may assume that the function evaluated is continuous. Therefore | |

derivatives within nonuniform control flow are undefined." | |

Change the last paragraph before the table to say | |

"In some implementations, varying degrees of derivative accuracy for dFdx | |

and dFdy may be obtained by providing GL hints (section 21.4 "Hints" of the | |

OpenGL Graphics System Specification), allowing a user to make an image | |

quality versus speed trade off.These hints have no effect on dFdxCoarse, | |

dFdyCoarse, dFdxFineand dFdyFine." | |

Add the following built-in functions to the table: | |

genType dFdxFine(genType p) | |

"Returns the partial derivative of p with respect to the window x | |

coordinate. Will use local differencing based on the value of p for the | |

current fragment and its immediate neighbor(s)." | |

genType dFdyFine(genType p) | |

"Returns the partial derivative of p with respect to the window y | |

coordinate. Will use local differencing based on the value of p for the | |

current fragment and its immediate neighbor(s)." | |

genType fwidthFine(genType p) | |

"Return abs(dFdxFine(p)) + abs(dFdyFine(p))." | |

genType dFdxCoarse(genType p) | |

"Returns the partial derivative of p with respect to the window x | |

coordinate. Will use local differencing based on the value of p for the | |

current fragment's neighbors, and will possibly, but not necessarily, | |

include the value of p for the current fragment. That is, over a | |

given area, the implementation can compute x derivatives in fewer | |

unique locations than would be allowed for dFdxFine(p)." | |

genType dFdyCoarse(genType p) | |

"Returns the partial derivative of p with respect to the window y | |

coordinate. Will use local differencing based on the value of p for the | |

current fragment's neighbors, and will possibly, but not necessarily, | |

include the value of p for the current fragment. That is, over a | |

given area, the implementation can compute y derivatives in fewer | |

unique locations than would be allowed for dFdyFine(p)." | |

genType fwidthCoarse(genType p) | |

"Returns abs(dFdxCoarse(p)) + abs(dFdyCoarse(p))." | |

Change the existing descriptions to the following: | |

genType dFdx(genType p) | |

"Returns either dFdxFine(p) or dFdxCoarse(p), based on implementation | |

choice, presumably whichever is the faster, or by whichever is selected | |

in the API through quality-versus-speed hints." | |

genType dFdy(genType p) | |

"Returns either dFdyFine(p) or dFdyCoarse(p), based on implementation | |

choice, presumably whichever is the faster, or by whichever is selected | |

in the API through quality-versus-speed hints." | |

Doing the above change would remove: | |

[Old Language to remove...] | |

"These two functions are commonly used to estimate the | |

filter width used to anti-alias procedural textures. We | |

are assuming that the expression is being evaluated in | |

parallel on a SIMD array so that at any given point in | |

time the value of the function is known at the grid points | |

represented by the SIMD array. Local differencing | |

between SIMD array elements can therefore be used to | |

derive dFdx, dFdy, etc." | |

getType fwidth(getType p) | |

"Returns abs(dFdx(p)) + abs(dFdy(p))." | |

Additions to the AGL/EGL/GLX/WGL Specifications | |

None. | |

GLX Protocol | |

None. | |

Errors | |

No new API errors. | |

New State | |

None. | |

New Implementation Dependent State | |

None. | |

Conformance Tests | |

TBD | |

Issues | |

1. Allow support on pre-4.0 versions? | |

Resolution: No, require 4.0. | |

2. Define higher-order derivatives? Currently we say they are undefined, | |

but don't see why they can't say more (like coarse is 0, and fine might | |

be something you'd expect). | |

dFdxFine(dFdyFine(a)) should work | |

dFdxCoarse(dFdyCoarse(a)) should work or be 0 | |

Generally, the descriptive part of the derivative section may need | |

slight tweaking, based on the decisions made. | |

Resolution: Yes, be more specific about how higher-order derivitives | |

behave. See the changes to the descriptive part of section 8.13.1. | |

Revision History | |

Revision 1, 17-Apr-2014 (JohnK) | |

- Create first version. | |

Revision 2, 12-May-2014 (JohnK) | |

- Write overview section | |

Revision 3, 7-Aug-2014 (JohnK) | |

- Match the core specification WRT to Bill's input derivatives, etc. | |

- Add Bill as a contributor. | |

- Close the issues. |