| Name |
| |
| NV_fragment_program4 |
| |
| Name Strings |
| |
| (none) |
| |
| Contact |
| |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Status |
| |
| Shipping for GeForce 8 Series (November 2006) |
| |
| Version |
| |
| Last Modified Date: 05/26/09 |
| NVIDIA Revision: 6 |
| |
| Number |
| |
| 335 |
| |
| Dependencies |
| |
| OpenGL 1.1 is required. |
| |
| NV_gpu_program4 is required. This extension is supported if |
| "GL_NV_gpu_program4" is found in the extension string. |
| |
| ATI_draw_buffers and ARB_draw_buffers trivially affects the definition of |
| this specification. |
| |
| ARB_fragment_program_shadow trivially affects the definition of this |
| specification. |
| |
| NV_primitive_restart trivially affects the definition of this extension. |
| |
| This extension is written against the OpenGL 2.0 specification. |
| |
| Overview |
| |
| This extension builds on the common assembly instruction set |
| infrastructure provided by NV_gpu_program4, adding fragment |
| program-specific features. |
| |
| This extension provides interpolation modifiers to fragment program |
| attributes allowing programs to specify that specified attributes be |
| flat-shaded (constant over a primitive), centroid-sampled (multisample |
| rendering), or interpolated linearly in screen space. The set of input |
| and output bindings provided includes all bindings supported by |
| ARB_fragment_program. Additional input bindings are provided to determine |
| whether fragments were generated by front- or back-facing primitives |
| ("fragment.facing"), to identify the individual primitive used to generate |
| the fragment ("primitive.id"), and to determine distances to user clip |
| planes ("fragment.clip[n]"). Additionally generic input attributes allow |
| a fragment program to receive a greater number of attributes from previous |
| pipeline stages than possible using only the pre-defined fixed-function |
| attributes. |
| |
| By and large, programs written to ARB_fragment_program can be ported |
| directly by simply changing the program header from "!!ARBfp1.0" to |
| "!!NVfp4.0", and then modifying instructions to take advantage of the |
| expanded feature set. There are a small number of areas where this |
| extension is not a functional superset of previous fragment program |
| extensions, which are documented in the NV_gpu_program4 specification. |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| None. |
| |
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) |
| |
| Modify Section 2.X, GPU Programs |
| |
| (insert after second paragraph) |
| |
| Fragment Programs |
| |
| Fragment programs are used to compute the transformed attributes of a |
| fragment, in lieu of the set of fixed-function operations described in |
| sections 3.8 through 3.10. Fragment programs are run on a single fragment |
| at a time, and the state of neighboring fragments is not explicitly |
| available. (In practice, fragment programs may be run on a block of |
| fragments, and neighboring fragments' attributes may be used for texture |
| LOD calculations or partial derivative approximation.) The inputs |
| available to a fragment program are the interpolated attributes of a |
| fragment, which include (among other things) window-space position, |
| primary and secondary colors, and texture coordinates. The results of the |
| program are one (or more) colors and possibly a new window Z coordinate. |
| A fragment program can not modify the (X,Y) location of the fragment. |
| |
| Modify Section 2.X.2, Program Grammar |
| |
| (replace third paragraph) |
| |
| Fragment programs are required to begin with the header string |
| "!!NVfp4.0". This header string identifies the subsequent program body as |
| being a fragment program and indicates that it should be parsed according |
| to the base NV_gpu_program4 grammar plus the additions below. Program |
| string parsing begins with the character immediately following the header |
| string. |
| |
| (add the following grammar rules to the NV_gpu_program4 base grammar) |
| |
| <instruction> ::= <SpecialInstruction> |
| |
| <varModifier> ::= <interpModifier> |
| |
| <SpecialInstruction> ::= "KIL" <opModifiers> <killCond> |
| | "DDX" <opModifiers> <instResult> "," |
| <instOperandV> |
| | "DDY" <opModifiers> <instResult> "," |
| <instOperandV> |
| |
| <killCond> ::= <instOperandV> |
| |
| <interpModifier> ::= "FLAT" |
| | "CENTROID" |
| | "NOPERSPECTIVE" |
| |
| <attribBasic> ::= <fragPrefix> "fogcoord" |
| | <fragPrefix> "position" |
| | <fragPrefix> "facing" |
| | <attribTexCoord> <optArrayMemAbs> |
| | <attribClip> <arrayMemAbs> |
| | <attribGeneric> <arrayMemAbs> |
| | "primitive" "." "id" |
| |
| <attribColor> ::= <fragPrefix> "color" |
| |
| <attribMulti> ::= <attribTexCoord> <arrayRange> |
| | <attribClip> <arrayRange> |
| | <attribGeneric> <arrayRange> |
| |
| <attribTexCoord> ::= <fragPrefix> "texcoord" |
| |
| <attribClip> ::= <fragPrefix> "clip" |
| |
| <attribGeneric> ::= <fragPrefix> "attrib" |
| |
| <fragPrefix> ::= "fragment" "." |
| |
| <resultBasic> ::= <resPrefix> "color" <resultOptColorNum> |
| | <resPrefix> "depth" |
| |
| <resultOptColorNum> ::= /* empty */ |
| |
| <resPrefix> ::= "result" "." |
| |
| (add the following subsection to section 2.X.3.1, Program Variable Types) |
| |
| Explicitly declared fragment program attribute variables may have one or |
| more interpolation modifiers that control how per-fragment values are |
| computed. |
| |
| An attribute variable declared as "FLAT" will be flat-shaded. For such |
| variables, the value of the attribute will be constant over an entire |
| primitive and will taken from the provoking vertex of the primitive, as |
| described in Section 2.14.7. If "FLAT" is not specified, attributes will |
| be interpolated as described in Chapter 3, with the exception that |
| attribute variables bound to colors will still be flat-shaded if the shade |
| model (section 2.14.7) is FLAT. If an attribute variable declared as |
| "FLAT" corresponds to a texture coordinate replaced by a point sprite |
| (s,t) value (section 3.3.1), the value of the attribute is undefined. |
| |
| An attribute variable declared as "CENTROID" will be interpolated using a |
| point on or inside the primitive, if possible, when doing multisample line |
| or polygon rasterization (sections 3.4.4 and 3.5.6). This method can |
| avoid artifacts during multisample rasterization when some samples of a |
| pixel are covered, but the sample location used is outside the primitive. |
| Note that when centroid sampling, the sample points used to generate |
| attribute values for adjacent pixels may not be evenly spaced, which can |
| lead to artifacts when evaluating partial derivatives or performing |
| texture LOD calculations needed for mipmapping. If "CENTROID" is not |
| specified, attributes may be sampled anywhere inside the pixel as |
| permitted by the specification, including at points outside the primitive. |
| |
| An attribute variable declared as "NOPERSPECTIVE" will be interpolated |
| using a method that is linear in screen space, as described in equation |
| 3.7 and the appoximation that follows equation 3.8. If "NOPERSPECTIVE" is |
| not specified, attributes must be interpolated with perspective |
| correction, as described in equations 3.6 and 3.8. When clipping lines or |
| polygons, an alternate method is used to compute the attributes of |
| vertices introduced by clipping when they are specified as "NOPERSPECTIVE" |
| (section 2.14.8). |
| |
| Implicitly declared attribute variables (bindings used directly in a |
| program instruction) will inherit the interpolation modifiers of any |
| explicitly declared attribute variable using the same binding. If no such |
| variable exists, default interpolation modes will be used. |
| |
| For fragments generated by point primitives, DrawPixels, and Bitmap, |
| interpolation modifiers have no effect. |
| |
| Implementations are not required to support arithmetic interpolation of |
| integer values written by a previous pipeline stage. Integer fragment |
| program attribute variables must be flat-shaded; a program will fail to |
| load if it declares a variable with the "INT" or "UINT" data type |
| modifiers without the "FLAT" interpolation modifier. |
| |
| There are several additional limitations on the use of interpolation |
| modifiers. A fragment program will fail to load: |
| |
| * if an interpolation modifier is specified when declaring a |
| non-attribute variable, |
| |
| * if the same interpolation modifier is specified more than once in a |
| single declaration (e.g., "CENTROID CENTROID ATTRIB"), |
| |
| * if the "FLAT" modifier is used together with either "CENTROID" or |
| "NOPERSPECTIVE" in a single declaration, |
| |
| * if any interpolation modifier is specified when declaring a variable |
| bound to a fragment's position, face direction, fog coordinate, or any |
| interpolated clip distance, |
| |
| * if multiple attribute variables with different interpolation modifiers |
| are bound to the same fragment attribute, or |
| |
| * if one variable is bound to the fragment's primary color and a second |
| variable with different interpolation modifiers is bound the the |
| fragment's secondary color. |
| |
| (add the following subsection to section 2.X.3.2, Program Attribute |
| Variables) |
| |
| Fragment program attribute variables describe the attributes of a fragment |
| produced during rasterization. The set of available bindings is |
| enumerated in Table X.X. |
| |
| Most attributes correspond to per-vertex attributes that are interpolated |
| over a primitive; such attributes are subject to the interpolation |
| modifiers described in section 2.X.3.1. The fragment's position, facing, |
| and primitive IDs are the exceptions, and are generated specially during |
| rasterization. Since two-sided color selection occurs prior to |
| rasterization, there are no distinct "front" or "back" colors available to |
| fragment programs. A single set of colors is available, which corresponds |
| to interpolated front or back vertex colors. |
| |
| If geometry programs are enabled, attributes will be obtained by |
| interpolating per-vertex outputs written by the geometry program. If |
| geometry programs are disabled, but vertex programs are enabled, |
| attributes will be obtained by interpolating per-vertex outputs written by |
| the vertex program. In either case, the fragment program attributes |
| should be read using the same component data type used to write the vertex |
| output attributes in the geometry or vertex program. The value of any |
| attribute corresponding to a vertex output not written by the geometry or |
| vertex program is undefined. |
| |
| If neither geometry nor vertex programs are used, attributes will be |
| obtained by interpolating per-vertex values computed by fixed-function |
| vertex processing. All interpolated fragment attributes should be read as |
| floating-point values. |
| |
| Fragment Attribute Binding Components Underlying State |
| -------------------------- ---------- ---------------------------- |
| fragment.color (r,g,b,a) primary color |
| fragment.color.primary (r,g,b,a) primary color |
| fragment.color.secondary (r,g,b,a) secondary color |
| fragment.texcoord (s,t,r,q) texture coordinate, unit 0 |
| fragment.texcoord[n] (s,t,r,q) texture coordinate, unit n |
| fragment.fogcoord (f,-,-,-) fog distance/coordinate |
| * fragment.clip[n] (c,-,-,-) interpolated clip distance n |
| fragment.attrib[n] (x,y,z,w) generic interpolant n |
| fragment.texcoord[n..o] (s,t,r,q) texture coordinates n thru o |
| * fragment.clip[n..o] (c,-,-,-) clip distances n thru o |
| fragment.attrib[n..o] (x,y,z,w) generic interpolants n thru o |
| * fragment.position (x,y,z,1/w) window position |
| * fragment.facing (f,-,-,-) fragment facing |
| * primitive.id (id,-,-,-) primitive number |
| |
| Table X.X: Fragment Attribute Bindings. The "Components" column |
| indicates the mapping of the state in the "Underlying State" column. |
| Bindings containing "[n]" require an integer value of <n> to select an |
| individual item. Interpolation modifiers are not supported on variables |
| that use bindings labeled with "*". |
| |
| If a fragment attribute binding matches "fragment.color" or |
| "fragment.color.primary", the "x", "y", "z", and "w" components of the |
| fragment attribute variable are filled with the "r", "g", "b", and "a" |
| components, respectively, of the fragment's primary color. |
| |
| If a fragment attribute binding matches "fragment.color.secondary", the |
| "x", "y", "z", and "w" components of the fragment attribute variable are |
| filled with the "r", "g", "b", and "a" components, respectively, of the |
| fragment's secondary color. |
| |
| If a fragment attribute binding matches "fragment.texcoord" or |
| "fragment.texcoord[n]", the "x", "y", "z", and "w" components of the |
| fragment attribute variable are filled with the "s", "t", "r", and "q" |
| components, respectively, of the fragment texture coordinates for texture |
| unit <n>. If "[n]" is omitted, texture unit zero is used. |
| |
| If a fragment attribute binding matches "fragment.fogcoord", the "x" |
| component of the fragment attribute variable is filled with either the |
| fragment eye distance or the fog coordinate, depending on whether the fog |
| source is set to FRAGMENT_DEPTH_EXT or FOG_COORDINATE_EXT, respectively. |
| The "y", "z", and "w" coordinates are undefined. |
| |
| If a fragment attribute binding matches "fragment.clip[n]", the "x" |
| component of the fragment attribute variable is filled with the |
| interpolated value of clip distance <n>, as written by the vertex or |
| geometry program. The "y", "z", and "w" components of the variable are |
| undefined. If fixed-function vertex processing or position-invariant |
| vertex programs are used with geometry programs disabled, clip distances |
| are obtained by interpolating the per-clip plane dot product: |
| |
| (p_1' p_2' p_3' p_4') dot (x_e y_e z_e w_e), |
| |
| for clip plane <n> as described in section 2.12. The clip distance for |
| clip plane <n> is undefined if clip plane <n> is disabled. |
| |
| If a fragment attribute binding matches "fragment.attrib[n]", the "x", |
| "y", "z", and "w" components of the fragment attribute variable are filled |
| with the "x", "y", "z", and "w" components of generic interpolant <n>. |
| All generic interpolants will be undefined when used with fixed-function |
| vertex processing with no geometry program enabled. |
| |
| If a fragment attribute binding matches "fragment.texcoord[n..o]", |
| "fragment.clip[n..o]", or "fragment.attrib[n..o]", a sequence of 1+<o>-<n> |
| bindings is created. For texture coordinate bindings, it is as though the |
| sequence "fragment.texcoord[n], fragment.texcoord[n+1], |
| ... fragment.texcoord[o]" were specfied. These bindings are available |
| only in explicit declarations of array variables. A program will fail to |
| load if <n> is greater than <o>. |
| |
| If a fragment attribute binding matches "fragment.position", the "x" and |
| "y" components of the fragment attribute variable are filled with the |
| floating-point (x,y) window coordinates of the fragment center, relative |
| to the lower left corner of the window. The "z" component is filled with |
| the fragment's z window coordinate. If z window coordinates are |
| represented internally by the GL as fixed-point values, the z window |
| coordinate undergoes an implied conversion to floating point. This |
| conversion must leave the values 0 and 1 invariant. The "w" component is |
| filled with the reciprocal of the fragment's clip w coordinate. |
| |
| If a fragment attribute binding matches "fragment.facing", the "x" |
| component of the fragment attribute variable is filled with +1.0 or -1.0, |
| depending on the orientation of the primitive producing the fragment. If |
| the fragment is generated by a back-facing polygon (including point- and |
| line-mode polygons), the facing is -1.0; otherwise, the facing is +1.0. |
| The "y", "z", and "w" coordinates are undefined. |
| |
| If a fragment attribute binding matches "primitive.id", the "x" component |
| of the fragment attribute variable is filled with a single integer. If a |
| geometry program is active, this value is obtained by taking the primitive |
| ID value emitted by the geometry program for the provoking vertex. If no |
| geometry program is active, the value is the number of primitives |
| processed by the rasterizer since the last time Begin was called (directly |
| or indirectly via vertex array functions). The first primitive generated |
| after a Begin is numbered zero, and the primitive ID counter is |
| incremented after every individual point, line, or polygon primitive is |
| processed. For polygons drawn in point or line mode, the primitive ID |
| counter is incremented only once, even though multiple points or lines may |
| be drawn. For QUADS and QUAD_STRIP primitives that are decomposed into |
| triangles, the primitive ID is incremented after each complete quad is |
| processed. For POLYGON primitives, the primitive ID counter is zero. The |
| primitive ID is zero for fragments generated by DrawPixels or Bitmap. |
| Restarting a primitive topology using the primitive restart index has no |
| effect on the primitive ID counter. The "y", "z", and "w" components of |
| the variable are always undefined. |
| |
| (add the following subsection to section 2.X.3.5, Program Results.) |
| |
| Fragment programs produce final fragment values, and the set of result |
| variables available to such programs correspond to the final attributes of |
| a fragment. Fragment program result variables may not be declared as |
| arrays. |
| |
| The set of allowable result variable bindings is given in Table X.X. |
| |
| Binding Components Description |
| ----------------------------- ---------- ---------------------------- |
| result.color (r,g,b,a) color |
| result.color[n] (r,g,b,a) color output n |
| result.depth (*,*,d,*) depth coordinate |
| |
| Table X.X: Fragment Result Variable Bindings. |
| Components labeled "*" are unused. |
| |
| If a result variable binding matches "result.color", updates to the "x", |
| "y", "z", and "w" components of the result variable modify the "r", "g", |
| "b", and "a" components, respectively, of the fragment's output color. |
| |
| If a result variable binding matches "result.color[n]" and the |
| ARB_draw_buffers program option is specified, updates to the "x", "y", |
| "z", and "w" components of the color result variable modify the "r", "g", |
| "b", and "a" components, respectively, of the fragment output color |
| numbered <n>. If the ARB_draw_buffers program option is not specified, |
| the "result.color[n]" binding is unavailable. |
| |
| If a result variable binding matches "result.depth", updates to the "z" |
| component of the result variable modify the fragment's output depth value. |
| If the "result.depth" binding is not in used in a variable written to by |
| any instruction in the fragment program, the interpolated depth value |
| produced by rasterization is used as if fragment program mode is not |
| enabled. Otherwise, the value written by the fragment program is used, |
| and the fragment's final depth value is undefined if the program did not |
| end up writing a depth value due to flow control or write masks. Writes |
| to any component of depth other than the "z" component have no effect. |
| |
| (modify Table X.13 in section 2.X.4, Program Instructions, to include the |
| following.) |
| |
| Modifiers |
| Instruction F I C S H D Inputs Out Description |
| ----------- - - - - - - ---------- --- -------------------------------- |
| DDX X - X X X F v v partial derivative relative to X |
| DDY X - X X X F v v partial derivative relative to Y |
| KIL X X - - X F vc - kill fragment |
| |
| (add the following subsection to section 2.X.6, Program Options.) |
| |
| Section 2.X.6.Y, Fragment Program Options |
| |
| + Fixed-Function Fog Emulation (ARB_fog_exp, ARB_fog_exp2, ARB_fog_linear) |
| |
| If a fragment program specifies one of the options "ARB_fog_exp", |
| "ARB_fog_exp2", or "ARB_fog_linear", the program will apply fog to the |
| program's final color using a fog mode of EXP, EXP2, or LINEAR, |
| respectively, as described in section 3.10. |
| |
| When a fog option is specified in a fragment program, semantic |
| restrictions are added to indicate that a fragment program will fail to |
| load if the number of temporaries it contains exceeds the |
| implementation-dependent limit minus 1, if the number of attributes it |
| contains exceeds the implementation-dependent limit minus 1, or if the |
| number of parameters it contains exceeds the implementation-dependent |
| limit minus 2. |
| |
| Additionally, when the ARB_fog_exp option is specified in a fragment |
| program, a semantic restriction is added to indicate that a fragment |
| program will fail to load if the number of instructions or ALU |
| instructions it contains exceeds the implementation-dependent limit minus |
| 3. When the ARB_fog_exp2 option is specified in a fragment program, a |
| semantic restriction is added to indicate that a fragment program will |
| fail to load if the number of instructions or ALU instructions it contains |
| exceeds the implementation-dependent limit minus 4. When the |
| ARB_fog_linear option is specified in a fragment program, a semantic |
| restriction is added to indicate that a fragment program will fail to load |
| if the number of instructions or ALU instructions it contains exceeds the |
| implementation-dependent limit minus 2. |
| |
| Only one fog application option may be specified by any given fragment |
| program. A fragment program that specifies more than one of the program |
| options "ARB_fog_exp", "ARB_fog_exp2", and "ARB_fog_linear", will fail to |
| load. |
| |
| + Precision Hints (ARB_precision_hint_fastest, ARB_precision_hint_nicest) |
| |
| Fragment program computations are carried out at an implementation- |
| dependent precision. However, some implementations may be able to perform |
| fragment program computations at more than one precision, and may be able |
| to trade off computation precision for performance. |
| |
| If a fragment program specifies the "ARB_precision_hint_fastest" program |
| option, implementations should select precision to minimize program |
| execution time, with possibly reduced precision. If a fragment program |
| specifies the "ARB_precision_hint_nicest" program option, implementations |
| should maximize the precision, with possibly increased execution time. |
| |
| Only one precision control option may be specified by any given fragment |
| program. A fragment program that specifies both the |
| "ARB_precision_hint_fastest" and "ARB_precision_hint_nicest" program |
| options will fail to load. |
| |
| + Multiple Color Outputs (ARB_draw_buffers, ATI_draw_buffers) |
| |
| If a fragment program specifies the "ARB_draw_buffers" or |
| "ATI_draw_buffers" option, it will generate multiple output colors, and |
| the result binding "result.color[n]" is allowed, as described in section |
| 2.X.3.5. If this option is not specified, a fragment program that |
| attempts to bind "result.color[n]" will fail to load, and only |
| "result.color" will be allowed. |
| |
| The multiple color outputs will typically be written to an ordered list of |
| draw buffers in the manner described in the ARB_draw_buffers extension |
| specification. |
| |
| + Fragment Program Shadows (ARB_fragment_program_shadow) |
| |
| The ARB_fragment_program_shadow option introduced a set of "SHADOW" |
| texture targets and made the results of depth texture lookups undefined |
| unless the texture format and compare mode were consistent with the target |
| provided in the fragment program instruction. This behavior is enabled by |
| default in NV_gpu_program4; specifying the option is not illegal but has |
| no additional effect. |
| |
| (add the following subsection to section 2.X.7, Program Declarations.) |
| |
| Section 2.X.7.Y, Fragment Program Declarations |
| |
| No declarations are supported at present for fragment programs. |
| |
| |
| (add the following subsection to section 2.X.8, Program Instruction Set.) |
| |
| Section 2.X.8.Z, DDX: Partial Derivative Relative to X |
| |
| The DDX instruction computes approximate partial derivatives of the four |
| components of the single floating-point vector operand with respect to the |
| X window coordinate to yield a result vector. The partial derivatives are |
| evaluated at the sample location of the pixel. |
| |
| f = VectorLoad(op0); |
| result = ComputePartialX(f); |
| |
| Note that the partial derivates obtained by this instruction are |
| approximate, and derivative-of-derivate instruction sequences may not |
| yield accurate second derivatives. Note also that the sample locations |
| for attributes declared with the CENTROID interpolation modifier may not |
| be evenly spaced, which can lead to artifacts in derivative calculations. |
| |
| DDX supports only floating-point data type modifiers and is available only |
| to fragment programs. |
| |
| Section 2.X.8.Z, DDY: Partial Derivative Relative to Y |
| |
| The DDY instruction computes approximate partial derivatives of the four |
| components of the single operand with respect to the Y window coordinate |
| to yield a result vector. The partial derivatives are evaluated at the |
| center of the pixel. |
| |
| f = VectorLoad(op0); |
| result = ComputePartialY(f); |
| |
| Note that the partial derivates obtained by this instruction are |
| approximate, and derivative-of-derivate instruction sequences may not |
| yield accurate second derivatives. Note also that the sample locations |
| for attributes declared with the CENTROID interpolation modifier may not |
| be evenly spaced, which can lead to artifacts in derivative calculations. |
| |
| DDY supports only floating-point data type modifiers and is available only |
| to fragment programs. |
| |
| Section 2.X.8.Z, KIL: Kill Fragment |
| |
| The KIL instruction evaluates a condition and kills a fragment if the test |
| passes. A fragment killed by the KIL instruction is discarded, and will |
| not be seen by subsequent stages of the pipeline. |
| |
| A KIL instruction may be specified using either a floating-point or |
| integer vector operand or a condition code test. |
| |
| If a floating-point or integer vector is provided, the fragment is |
| discarded if any of its components are negative: |
| |
| tmp = VectorLoad(op0); |
| if ((tmp.x < 0) || (tmp.y < 0) || |
| (tmp.z < 0) || (tmp.w < 0)) |
| { |
| exit; |
| } |
| |
| Unsigned integer vector operands are permitted; however, KIL.U will have |
| no effect as no component is negative by definition. |
| |
| If a condition code test is provided, the fragment is discarded if any |
| component of the test passes: |
| |
| if (TestCC(rc.c***) || TestCC(rc.*c**) || |
| TestCC(rc.**c*) || TestCC(rc.***c)) |
| { |
| exit; |
| } |
| |
| KIL supports all three data type modifiers. |
| |
| KIL is available only to fragment programs. |
| |
| Replace Section 2.14.8, and rename it to "Vertex Attribute Clipping" |
| (p. 70). |
| |
| After lighting, clamping or masking and possible flatshading, vertex |
| attributes, including colors, texture and fog coordinates, shader varying |
| variables, and point sizes computed on a per vertex basis, are clipped. |
| Those attributes associated with a vertex that lies within the clip volume |
| are unaffected by clipping. If a primitive is clipped, however, the |
| attributes assigned to vertices produced by clipping are produced by |
| interpolating attributes along the clipped edge. |
| |
| Let the attributes assigned to the two vertices P_1 and P_2 of an |
| unclipped edge be a_1 and a_2. The value of t (section 2.12) for a |
| clipped point P is used to obtain the attribute associated with P as |
| |
| a = t * a_1 + (1-t) * a_2 |
| |
| unless the attribute is specified to be interpolated without perspective |
| correction in a fragment program. In that case, the attribute associated |
| with P is |
| |
| a = t' * a_1 + (1-t') * a_2 |
| |
| where |
| |
| t' = (t * w_1) / (t * w_1 + (1-t) * w_2) |
| |
| and w_1 and w_2 are the w clip coordinates of P_1 and P_2, |
| respectively. If w_1 or w_2 is either zero or negative, the value of the |
| associated attribute is undefined. |
| |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
| |
| None |
| |
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None |
| |
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) |
| |
| None |
| |
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and |
| State Requests) |
| |
| None |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None |
| |
| Dependencies on ARB_draw_buffers and ATI_draw_buffers |
| |
| If neither ARB_draw_buffers nor ATI_draw_buffers is supported, then the |
| discussion of the ARB_draw_buffers option in section 2.X.6.Y should be |
| removed, as well as the result bindings of the form "result.color[n]" and |
| "result.color[n..o]". |
| |
| Dependencies on ARB_fragment_program_shadow |
| |
| If ARB_fragment_program_shadow is not supported, then the discussion of |
| the ARB_fragment_program_shadow option in section 2.X.6.Y should be |
| removed. |
| |
| Dependencies on NV_primitive_restart |
| |
| The spec describes the behavior that primitive restart does not affect the |
| primitive ID counter, including for POLYGON primitives (where one could |
| argue that the restart index starts a new primitive without a new Begin to |
| reset the count. If NV_primitive_restart is not supported, references to |
| that extension in the discussion of the "primitive.id" attribute should be |
| removed. |
| |
| Errors |
| |
| None |
| |
| New State |
| |
| None |
| |
| New Implementation Dependent State |
| |
| None |
| |
| Issues |
| |
| (1) How should special interpolation controls be specified? |
| |
| RESOLVED: As a special modifier to fragment program attribute variable |
| declarations. It was decided that the fragment program was the most |
| natural place to put the control. This wouldn't require making a large |
| number of related state changes controlling interpolation whenever the |
| fragment program used. The final mechanism using special interpolation |
| modifiers was chosen because it fit well with the other variable |
| modifiers (for data storage size and data type) provided by |
| NV_gpu_program4. Examples: |
| |
| FLAT ATTRIB texcoords[4] = { fragment.texcoord[0..3] }; |
| CENTROID ATTRIB texcoord4 = fragment.texcoord[4]; |
| CENTROID NOPERSPECTIVE ATTRIB |
| attribs[3] = { fragment.attrib[0..2] }; |
| |
| There were a variety of options considered, including: |
| |
| * special declarations in vertex or geometry programs to specify the |
| interpolation type, |
| |
| * special declarations in the fragment program to specify one or more |
| interpolation type modifiers per binding, such as: |
| |
| INTERPOLATE fragment.texcoord[0..3], FLAT; |
| INTERPOLATE fragment.texcoord[4], CENTROID; |
| INTERPOLATE fragment.attrib[0..2], CENTROID, NOPERSPECTIVE; |
| |
| * fixed-function state specifying the interpolation mode |
| |
| glInterpolateAttribNV(GL_TEXTURE0, GL_FLAT); |
| glInterpolateAttribNV(GL_GENERIC_ATTRIB0, GL_CENTROID_NV); |
| |
| Recent updates to GLSL provide similar functionality (for centroid) with |
| a similar approach, using a modifier on varying variable declarations. |
| |
| (2) How should perspective-incorrect interpolation (linear in screen |
| space) and clipping interact? |
| |
| RESOLVED: Primitives with attributes specified to be |
| perspective-incorrect should be clipped so that the vertices introduced |
| by clipping should have attribute values consistent with the |
| interpolation mode. We do not want to have large color shifts |
| introduced by clipping a perspective-incorrect attribute. For example, |
| a primitive that approaches, but doesn't cross, a frustum clip plane |
| should look pretty much identical to a similar primitive that just |
| barely crosses the clip plane. |
| |
| Clipping perspective-incorrect interpolants that cross the W==0 plane is |
| very challenging. The attribute clipping equation provided in the spec |
| effectively projects all the original vertices to screen space while |
| ignoring the X and Y frustum clip plane. As W approaches zero, the |
| projected X/Y window coordinates become extremely large. When clipping |
| an edge with one vertex inside the frustum and the other out near |
| infinity (after projection, due to W approaching zero), the interpolated |
| attribute for the entire visible portion of the edge should almost |
| exactly match the attribute value of the visible vertex. |
| |
| If an outlying vertex approaches and then goes past W==0, it can be said |
| to go "to infinity and beyond" in screen space. The correct answer for |
| screen-linear interpolation is no longer obvious, at least to the author |
| of this specification. Rather than trying to figure out what the |
| "right" answer is or if one even exists, the results of clipping such |
| edges is specified as undefined. |
| |
| (3) If a shader wants to use interpolation modifiers without using |
| declared variables, is that possible? |
| |
| RESOLVED: Yes. If "dummy" variables are declared, all interpolants |
| bound to that variable will get the variable's interpolation modifiers. |
| In the following program: |
| |
| FLAT ATTRIB tc02[3] = { fragment.texcoord[0..2] }; |
| MOV R0, fragment.texcoord[1]; |
| MOV R1, fragment.texcoord[3]; |
| |
| The variable R0 will get texture coordinate set 1, which will be |
| flat-shaded due to the declaration of "tc02". The variable R1 will get |
| texture coordinate set 3, which will be smooth shaded (default). |
| |
| (4) Is it possible to read the same attribute with different interpolation |
| modifiers? |
| |
| RESOLVED: No. A program that tries to do that will fail to compile. |
| |
| (5) Why can't fragment program results be declared as arrays? |
| |
| RESOLVED: This is a limitation of the programming model. If an |
| implementation needs to do run-time indexing of fragment program result |
| variables (effectively writing to "result.color[A0.x]"), code such as |
| the following can be used: |
| |
| TEMP colors[4]; |
| ... |
| MOV colors[A0.x], R1; |
| MOV colors[3], 12.3; |
| ... |
| # end of the program |
| MOV result.color[0], colors[0]; |
| MOV result.color[1], colors[1]; |
| MOV result.color[2], colors[2]; |
| MOV result.color[3], colors[3]; |
| |
| (6) Do clip distances require that the corresponding clip planes be |
| enabled to be read by a fragment program? |
| |
| RESOLVED: No. |
| |
| (7) How do primitive IDs work with fragment programs? |
| |
| RESOLVED: If a geometry program is enabled, the primitive ID is |
| consumed by the geometry program and is not automatically available to |
| the fragment program. If the fragment program needs a primitive ID in |
| this case, the geometry program can write out a primitive ID using the |
| "result.primid" binding, and the fragment program will see the primitive |
| ID written for the provoking vertex. |
| |
| If no geometry program is enabled, the primitive ID is automatically |
| available, and specifies the number of primitives (points, lines, or |
| triangles) processed by since the last explicit or implicit Begin call. |
| |
| (8) What is the primitive ID for non-geometry commands that generate |
| fragments, such as DrawPixels, Bitmap, and CopyPixels. |
| |
| RESOLVED: Zero. |
| |
| (9) How does the FLAT interpolation modifier interact with point sprite |
| coordinate replacement? |
| |
| RESOLVED: The value of such attributes are undefined. Specifying these |
| two operations together is self-contradictory -- FLAT asks for an |
| interpolant that is constant over a primitive, and point sprite |
| coordinate interpolation asks for an interpolant that is non-constant |
| over a point sprite. |
| |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- -------------------------------------------- |
| 6 05/26/09 pbrown Fix documentation of KIL to support integer |
| operands, as indicated in the opcodes table |
| in NV_gpu_program4. |
| |
| 5 03/11/09 pbrown Fix section numbers for option/declaration |
| sections. |
| |
| 4 11/06/07 pbrown Documented interaction between the FLAT |
| interpolation modifier and point sprite |
| coordinate replacement. |
| |
| 1-3 pbrown Internal spec development. |
