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 : where 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.