Name ARB_vertex_attrib_64bit Name Strings GL_ARB_vertex_attrib_64bit Contact Graham Sellers, AMD (graham.sellers 'at' amd.com) Pat Brown, NVIDIA (pbrown 'at' nvidia.com) Piers Daniell, NVIDIA (pdaniell 'at' nvidia.com) Contributors Barthold Lichtenbelt, NVIDIA Bill Licea-Kane, AMD Eric Werness, NVIDIA Graham Sellers, AMD Greg Roth, NVIDIA Jeff Bolz, NVIDIA Nick Haemel, AMD Pierre Boudier, AMD Piers Daniell, NVIDIA Notice Copyright (c) 2010-2013 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 9, 2010. Approved by the Khronos Board of Promoters on July 23, 2010. Version Last Modified Date: June 10, 2014 Revision: 10 Number ARB Extension #99 Dependencies This extension is written against the OpenGL 3.2 specification (Compatibility Profile). This extension is written against version 1.50 (revision 09) of the OpenGL Shading Language Specification. OpenGL 3.0 and GLSL 1.30 are required. ARB_gpu_shader_fp64 (or equivalent functionality) is required. This extension interacts with OpenGL 3.1 implementations not supporting ARB_compatibility and with the core profile of OpenGL 3.2. This extension interacts with EXT_direct_state_access. This extension interacts with NV_gpu_shader5. This extension interacts with NV_vertex_attrib_integer_64bit. This extension interacts with ARB_explicit_attrib_location, ARB_separate_shader_objects, OpenGL 3.3, and OpenGL 4.1. Overview This extension provides OpenGL shading language support for vertex shader inputs with 64-bit floating-point components and OpenGL API support for specifying the value of those inputs using vertex array or immediate mode entry points. This builds on the support for general-purpose support for 64-bit floating-point values in the ARB_gpu_shader_fp64 extension. This extension provides a new class of vertex attribute functions, beginning with "VertexAttribL" ("L" for "long"), that can be used to specify attributes with 64-bit floating-point components. This extension provides no automatic type conversion between attribute and shader variables; single-precision attributes are not automatically converted to double-precision or vice versa. For shader variables with 64-bit component types, the "VertexAttribL" functions must be used to specify attribute values. For other shader variables, the "VertexAttribL" functions must not be used. If a vertex attribute is specified using the wrong attribute function, the values of the corresponding shader input are undefined. This approach requiring matching types is identical to that used for the "VertexAttribI" functions provided by OpenGL 3.0 and the EXT_gpu_shader4 extension. Additionally, some vertex shader inputs using the wider 64-bit components may count double against the implementation-dependent limit on the number of vertex shader attribute vectors. A 64-bit scalar or a two-component vector consumes only a single generic vertex attribute; three- and four-component "long" may count as two. This approach is similar to the one used in the current GL where matrix attributes consume multiple attributes. Note that 64-bit generic vertex attributes were nominally supported beginning with the introduction of vertex shaders in OpenGL 2.0. However, the OpenGL Shading Language at the time had no support for 64-bit data types, so any such values were automatically converted to 32-bit. Support for 64-bit floating-point vertex attributes in this extension can be combined with other extensions. In particular, this extension provides an entry point that can be used with EXT_direct_state_access to directly set state for any vertex array object. Also, the related NV_vertex_attrib_integer_64bit extension provides an entry point to specify bindless vertex attribute arrays with 64-bit components, integer or floating-point. IP Status No known IP claims. New Procedures and Functions void VertexAttribL1d(uint index, double x); void VertexAttribL2d(uint index, double x, double y); void VertexAttribL3d(uint index, double x, double y, double z); void VertexAttribL4d(uint index, double x, double y, double z, double w); void VertexAttribL1dv(uint index, const double *v); void VertexAttribL2dv(uint index, const double *v); void VertexAttribL3dv(uint index, const double *v); void VertexAttribL4dv(uint index, const double *v); void VertexAttribLPointer(uint index, int size, enum type, sizei stride, const void *pointer); void GetVertexAttribLdv(uint index, enum pname, double *params); void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, uint index, int size, enum type, sizei stride, intptr offset); (note: VertexArrayVertexAttribLOffsetEXT is provided only if EXT_direct_state_access is supported.) New Tokens Returned in the parameter of GetActiveAttrib: DOUBLE DOUBLE_VEC2 0x8FFC DOUBLE_VEC3 0x8FFD DOUBLE_VEC4 0x8FFE DOUBLE_MAT2 0x8F46 DOUBLE_MAT3 0x8F47 DOUBLE_MAT4 0x8F48 DOUBLE_MAT2x3 0x8F49 DOUBLE_MAT2x4 0x8F4A DOUBLE_MAT3x2 0x8F4B DOUBLE_MAT3x4 0x8F4C DOUBLE_MAT4x2 0x8F4D DOUBLE_MAT4x3 0x8F4E Note: These enums are defined in ARB_gpu_shader_fp64, which is required by this extension. They are included here only for completeness. Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification (OpenGL Operation) Modify Section 2.7, Vertex Specification (p. 24) (delete third paragraph, p. 33, beginning with "The resulting attribute values are undefined") (rework the description of the VertexAttribI* commands, and add support for new VertexAttribL* commands, p. 33) To load values into a generic shader attribute declared as a signed or unsigned integer or integer vector, use the commands void VertexAttribI{1,2,3,4}{i,ui}( uint index, T values ); void VertexAttribI{1,2,3,4}{i,ui}v( uint index, T values ); void VertexAttribI4{b,s,ub,us}v( uint index, T values ); These commands specify values that are extended to full signed or unsigned integers, then loaded into the generic attribute at slot index in the same fashion as described above. To load values into a generic shader attribute declared as a double, or into vectors or matrices thereof, use the commands void VertexAttribL{1,2,3,4}d(uint index, T values); void VertexAttribL{1,2,3,4}dv(uint index, T values); These commands specify one, two, three or four values. Note that attribute variables declared with "double" types must be loaded with VertexAttribL*d{v}; loading attributes with VertexAttrib*d{v} will produce undefined results. For all VertexAttrib* commands, the error INVALID_VALUE is generated if is greater than or equal to MAX_VERTEX_ATTRIBS. The full set of VertexAttrib* commands specify generic attributes whose components are one of the data types: * floating-point values (VertexAttrib*), * signed or unsigned integers (VertexAttribI*), and * double-precision floating-point values (VertexAttribL*d*) The values loaded into a shader attribute variable bound to generic attribute are undefined if the data type of the attribute components specified by the most recent VertexAttrib* command do not match the data type of the variable. Modify Section 2.8, Vertex Arrays, p. 34 (insert new paragraph after first paragraph, p. 37) The command void VertexAttribLPointer(uint index, int size, enum type, sizei stride, const void *pointer); specifies state for a generic vertex attribute array associated with a shader attribute variable declared with 64-bit double precision components. must be DOUBLE. , , and behave as defined in all other vertex commands; may be one, two, three or four. Each component of an array specified by VertexAttribLPointer will be encoded into one or more generic attribute components as specified for the VertexAttribL* commands in Section 2.7. The error INVALID_VALUE is generated if is greater than or equal to MAX_VERTEX_ATTRIBS. (modify pseudo-code, p. 38, to handle VertexAttribLPointer) ... for (j = 1; j < genericAttributes; j++) { if (generic vertex attribute j array enabled) { if (generic attribute j array set by VertexAttribLPointer) { VertexAttribL[size][type]v(j, generic vertex attribute j array element i); } else if (generic attribute j array set by VertexAttribIPointer) { VertexAttribI[size][type]v(j, generic vertex attribute j array element i); } else if (generic vertex attribute j array normalization flag is set, and type is not FLOAT or DOUBLE) { VertexAttrib[size]N[type]v(j, generic vertex attribute j array element i); } else { VertexAttrib[size][type]v(j, generic vertex attribute j array element i); } } } if (generic attribute 0 array enabled) { if (generic attribute 0 array set by VertexAttribLPointers) { VertexAttribL[size][type]v(0, generic vertex attribute 0 array element i); } else if (generic attribute 0 array set by VertexAttribIPointer) { VertexAttribI[size][type]v(0, generic vertex attribute 0 array element i); } else if (generic vertex attribute 0 array normalization flag is set, and type is not FLOAT or DOUBLE) { VertexAttrib[size]N[type]v(0, generic vertex attribute 0 array element i); } else { VertexAttrib[size][type]v(0, generic vertex attribute 0 array element i); } } else if (vertex array enabled) { ... Modify the "Add to the end of Section 2.10 (Vertex Array Objects)" section of EXT_direct_state_access (add a new function prototype to the initial list of commands) void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, uint index, int size, enum type, sizei stride, intptr offset); (No edits are made to the language added in this section. The same general rules described in EXT_direct_state_access apply here -- identifies a vertex array object used instead of the currently bound one, is used in place of the buffer object bound to ARRAY_BUFFER, and the command otherwise behaves like VertexAttribLPointer with set to .) Modify Section 2.14.3, Vertex Attributes, p. 86 (replace last paragraph, p. 86) When an attribute variable declared using one of the scalar or vector data types enumerated in Table X.1 and is bound to a generic attribute index , its value(s) are taken from the components of generic attribute . Scalars are extracted from the x component; two-, three-, and four-component vectors are extracted from the, (x, y), (x, y, z), or (x, y, z, w) components, respectively. Data type Command ------------------------------- ---------------------------------- int int8_t int16_t int32_t VertexAttribI1i ivec2 i8vec2 i16vec2 i32vec2 VertexAttribI2i ivec3 i8vec3 i16vec3 i32vec3 VertexAttribI3i ivec4 i8vec4 i16vec4 i32vec4 VertexAttribI4i uint uint8_t uint16_t uint32_t VertexAttribI1ui uvec2 u8vec2 u16vec2 u32vec2 VertexAttribI2ui uvec3 u8vec3 u16vec3 u32vec3 VertexAttribI3ui uvec4 u8vec4 u16vec4 u32vec4 VertexAttribI4ui float float16_t float32_t VertexAttrib1{f,b,s,i,ub,us,ui,d} vec2 f16vec2 f32vec2 VertexAttrib2{f,b,s,i,ub,us,ui,d} vec3 f16vec3 f32vec3 VertexAttrib3{f,b,s,i,ub,us,ui,d} vec4 f16vec4 f32vec4 VertexAttrib4{f,b,s,i,ub,us,ui,d} double float64_t VertexAttribL1d dvec2 f64vec2 VertexAttribL2d dvec3 f64vec3 VertexAttribL3d dvec4 f64vec4 VertexAttribL4d Table X.1: Scalar and vector vertex attribute types and VertexAttrib* commands used to set the values of the corresponding generic attribute. When an attribute variable is declared as a mat2, mat3x2, mat4x2, its matrix columns are taken from the (x, y) components of generic attributes and +1 (mat2, dmat2), from attributes through +2 (mat3x2), or from attributes through +3 (mat4x2). When an attribute variable is declared as a mat2x3, mat3 or mat4x3, its matrix columns are taken from the (x, y, z) components of generic attributes i and +1 (mat2x3), from attributes through +2 (mat3), or from attributes i through +3 (mat4x3). When an attribute variable is declared as a mat2x4, mat3x4 or mat4, its matrix columns are taken from the (x, y, z, w) components of generic attributes and +1 (mat2x4), from attributes through +2 (mat3x4), or from attributes through +3 (mat4). When an attribute variable is declared as a double-precision matrix (dmat2, dmat3, dmat4, dmat2x3, dmat2x4, dmat3x2, dmat3x4, dmat4x2, dmat4x3), its matrix columns are taken from the same generic attributes as the equivalent single-precision matrix type, with values specified using the VertexAttribL* or VertexAttribLPointer commands. For the 64-bit double precision types listed in Table X.1, no default attribute values are provided if the values of the vertex attribute variable are specified with fewer components than required for the attribute variable. For example, the fourth component of a variable of type dvec4 will be undefined if specified using VertexAttribL3dv or using a vertex array specified with VertexAttribLPointer and a size of three. (modify the second paragraph, p. 87) ... exceeds MAX_VERTEX_ATTRIBS. For the purposes of this comparison, attribute variables of the type dvec3, dvec4, dmat2x3, dmat2x4, dmat3, dmat3x4, dmat4x3, and dmat4 may count as consuming twice as many attributes as equivalent single-precision types. While these types use the same number of generic attributes as their single-precision equivalents, implementations are permitted to consume two single-precision vectors of internal storage for each three- or four-component double-precision vector. (extend the list of types in the first paragraph, p. 88) ... UNSIGNED_INT_VEC3, UNSIGNED_INT_VEC4, DOUBLE, DOUBLE_VEC2, DOUBLE_VEC3, DOUBLE_VEC4, DOUBLE_MAT2, DOUBLE_MAT3, DOUBLE_MAT4, DOUBLE_MAT2x3, DOUBLE_MAT2x4, DOUBLE_MAT3x2, DOUBLE_MAT3x4, DOUBLE_MAT4x2, or DOUBLE_MAT4x3. (add the following entries to table 2.13: OpenGL Shading Language type tokens returned by GetActiveUniform and GetActiveUniformsiv, and corresponding shading language keywords declaring each such type., p. 96) Type Name Token | Keyword --------------------------------- DOUBLE | double DOUBLE_VEC2 | dvec2 DOUBLE_VEC3 | dvec3 DOUBLE_VEC4 | dvec4 DOUBLE_MAT2 | dmat2 DOUBLE_MAT3 | dmat3 DOUBLE_MAT4 | dmat4 DOUBLE_MAT2x3 | dmat2x3 DOUBLE_MAT2x4 | dmat2x4 DOUBLE_MAT3x2 | dmat3x2 DOUBLE_MAT3x4 | dmat3x4 DOUBLE_MAT4x2 | dmat4x2 DOUBLE_MAT4x3 | dmat4x3 Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization) None. Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification (Per-Fragment Operations and the Frame Buffer) None. Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification (Special Functions) Modify Section 5.4.1, Commands Not Usable in Display Lists, p. 358 (add to "Vertex arrays" list) VertexAttribLPointer, and VertexArrayVertexAttribLOffsetEXT. (note: GetVertexAttribL* commands are also not allowed in display lists, but is already covered by blanket language in "Other queries") Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification (State and State Requests) Modify Section 6.1.15, Shader and Program Queries, p. 384 (add to the last list of commands, p. 387) void GetVertexAttribLdv(uint index, enum pname, double *params); (modify the third paragraph, p. 388) The query CURRENT_VERTEX_ATTRIB returns the current value for the generic attribute . GetVertexAttribdv and GetVertexAttribfv read and return the current attribute values as four single-precision floating-point values; GetVertexAttribiv reads them as floating-point values and converts them to four integer values; GetVertexAttribIiv reads and returns them as signed integers; GetVertexAttribIuiv reads and returns them as four unsigned integers; GetVertexAttribLdv reads and returns them as four double-precision floating-point values. The results of the query are undefined if the current attribute values are read using one data type but were specified using a different one. The error INVALID_OPERATION is generated if index is zero, as there is no current value for generic attribute zero. Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) Specification (Invariance) None. Additions to the AGL/GLX/WGL Specifications None. Modifications to The OpenGL Shading Language Specification, Version 1.50 (Revision 09) Including the following line in a shader can be used to control the language features described in this extension: #extension GL_ARB_vertex_attrib_64bit : where is as specified in section 3.3. New preprocessor #defines are added to the OpenGL Shading Language: #define GL_ARB_vertex_attrib_64bit 1 Modify Section 4.3.4, Inputs, p. 31 (modify third paragraph of the section, p. 31, allowing double-precision vertex shader inputs) ... Vertex shader inputs can only be single- or double-precision floating-point scalars, vectors, or matrices, or signed and unsigned integers and integer vectors. Vertex shader inputs can also form arrays of these types, but not structures. GLX Protocol !!! TBD !!! Dependencies on OpenGL 3.1 and OpenGL 3.2 When using an OpenGL 3.1 context without support for the ARB_compatibility extension or the core profile of OpenGL 3.2, remove the pseudocode describing the operation of ArrayElement. The core profile specifies commands like DrawArrays and DrawElements more concisely. Additionally, remove edits relevant to (deleted) display list functionality. Dependencies on EXT_direct_state_access If EXT_direct_state_access is not supported, references to the function VertexArrayVertexAttribLOffsetEXT should be removed. Dependencies on NV_gpu_shader5 If NV_gpu_shader5 is not supported, references to the sized data types provided by these extensions (e.g., int8_t, float16_t, u16vec4, f64vec2) in Table X.1 should be removed. The full set of types in the table is provided for completeness. Dependencies on NV_vertex_attrib_integer_64bit The extension NV_vertex_attrib_integer_64bit provides similar VertexAttribL* support for 64-bit signed and unsigned integer vertex shader inputs. That extension also uses the VertexAttribLPointer function to specify 64-bit integer vertex attribute arrays. Even if an application only uses 64-bit floating-point values in their vertex shader, NV_vertex_attrib_integer_64bit may still be useful. That extension also provides the VertexAttribLFormatNV function, which allows the "bindless" vertex attribute array support provided by the NV_vertex_buffer_unified_memory extension to be used with 64-bit components, integer or floating-point. Dependencies on ARB_explicit_attrib_location, ARB_separate_shader_objects, OpenGL 3.3, and OpenGL 4.1 If ARB_explicit_attrib_location (or OpenGL 3.3) is supported, vertex shader input variables (including ones with double-precision components) can select associated generic attributes with an explicit location layout qualifier in lieu of calling BindAttribLocation. If ARB_separate_shader_objects (or OpenGL 4.1) is supported, the layout location qualifier introduced by this extension is extended to apply to inputs for non-vertex shaders and outputs for non-fragment shaders. As this extension requires ARB_gpu_shader_fp64 (or OpenGL 4.0), such inputs and outputs can have double-precision component types. When these extensions are supported, there are special rules for the number of locations consumed by "dvec3" and "dvec4" types, which require more storage than is available in a four-component single-precision vector. The rules are: * dvec3/dvec4 vertex inputs consume one location (generic vertex attribute), but can count as two vectors for the purposes of determining if the vertex shader consumes too many inputs * dvec3/dvec4 inputs and outputs for other stages consume two locations The relevant spec edits (modifying language introduced by ARB_explicit_attrib_location) can be found in the ARB_separate_shader_objects extension. Errors For all VertexAttrib* commands, the error INVALID_VALUE is generated if is greater than or equal to MAX_VERTEX_ATTRIBS. For VertexAttribLPointer, VertexAttribLFormat, and VertexArrayVertexAttribLOffsetEXT, the error INVALID_VALUE is generated if is greater than or equal to MAX_VERTEX_ATTRIBS. New State None. New Implementation Dependent State None. Issues (1) Should we allow 64-bit double-precision vertex attributes in the OpenGL API? If so, how should we handle 64-bit double-precision values? RESOLVED: Yes, we will allow vertex shader inputs to have any scalar or vector type, including sized types. Doubles appear to the API as any other type. The new 'L' versions of the entry points are added to distinguish 64-bit attributes from existing DOUBLE support, where doubles are down-converted to floats. (2) How does the handling of 64-bit vertex attribute components in this extension interact with the existing vertex attribute functions that support doubles? RESOLVED: While it is possible for fixed-function pipeline implementations to operate directly on doubles, most (if not all) such implementations simply convert doubles to floats. The OpenGL Shading Language has not supported double-precision types to date, so all previous shading language inputs needed to be converted to float by necessity. While it would be possible to support the existing double-precision vertex APIs (e.g., VertexAttrib4dv) to feed shading language variables with double-precision types, any such approach involves the prohibitive dynamic typing overhead discussed above. As a result, we chose to create a parallel VertexAttribL* API. A similar approach was chosen for the integer attributes in OpenGL 3.0, where there was a pre-existing set of vertex APIs that accepted integers that were converted to floating-point values via straight value conversion or normalization. Re-using existing integer APIs to feed the (new) integer variable types would have required similarly expensive dynamic typing. (3) How should we handle vertex attributes for three- and four-component vectors with double-precision components? How do we support these with vertex arrays? RESOLVED: Double-precision attributes may consume twice as much internal storage as their single-precision counterparts. For the purposes of determining if a vertex shader uses "too many" attribute vectors in LinkProgram, implementations are permitted (but not required) to count "dvec3" and "dvec4" vertex shader inputs as consuming twice as many input vectors as corresponding single-precision types. Implementations are required to count inputs of type "double" and "dvec2" as a single vector, since these types require no more storage than a "vec4". Note however, that for the purposes of mapping inputs to generic vertex attributes, "dvec3" and "dvec4" inputs are counted as consuming one attribute/location. For example, if a vertex shader specifies: layout(location=4) in dvec4 attribs[4]; the values for the four elements of "attribs" will be taken from vertex attributes 4-7, though "attribs" may be counted as consuming eight vectors worth of attributes. (4) Are default values supported for vertex attributes with 64-bit components? RESOLVED: No. With existing APIs, calling VertexAttrib3f() defines a FOUR-component vector where the fourth component assumes the value 1.0. No such defaults are provided for 64-bit components; if you load the values of an attribute of type "dvec4" with VertexAttribL3dv(), the value of the fourth component of the attribute variable will be undefined. The APIs for loading 64-bit vertex attributes were designed to limit the amount of data type conversion required of the implementation; providing new type-dependent default values runs contrary to that design. Note that the original defaults were present in part to accommodate fixed-function vertex and fragment processing, where certain operations were defined in the most general form but reasonable defaults allowed targeted optimizations. For example, vertex transformations were defined to operate on four-component object coordinates, even though four-component input positions are relatively rare. Specifying a default W value of 1.0 allows for a fully-general implementation that doesn't need to do special cases based on the input position, but can still choose to do so as an optimization. Programmable shaders, on the other hand, can easily be written to ignore irrelevant components and substitute constants themselves. (5) Should this have a separate extension string entry or be simply implied by extensions such as ARB_gpu_shader5 or ARB_gpu_shader_fp64? RESOLVED: Treat as a separate extension, since there may be several such extensions with varying capabilities. Additionally, we provide a separate GLSL "#extension" identifier for this extension because ARB_gpu_shader_fp64 was adopted without support for vertex inputs with 64-bit components. (6) How does this extension provide 64-bit vertex attribute components for assembly programs supported by NV_gpu_program5? RESOLVED: NV_gpu_program5 allows programs to declare input variables with 64-bit components using the "LONG ATTRIB" declaration syntax. These inputs will be matched up against corresponding vertex attributes in the same manner as with GLSL. Also, as with GLSL, the values of each vertex program input must be specified with the correct API function (VertexAttrib* vs. VertexAttribL*). Revision History Rev. Date Author Changes ---- -------- -------- ----------------------------------------------- 10 06/10/14 Jon Leech Fix typo in name of EXT_direct_state_access (Bug 7704). 9 08/01/11 pbrown Clarify that "dvec3" and "dvec4" vertex shader inputs consume only a single "location" for the purpose of matching inputs to generic vertex attributes, but may consume two vectors for the purposes of determining if too many attribute vectors are used (bug 7809). Also, add missing language describing the set of attributes consumed by matrix vertex attributes (copied from OpenGL 4.1), with fixes to explicitly address "dmat*" types. Fix issue (3) to match. 8 01/18/11 Jon Leech Make description of component data types match the commands specifying them (Bug 7235). 7 07/06/10 pbrown Fix cut-and-paste errors in table mapping GLSL types to API entry points. 6 04/09/10 pdaniell ARBify the spec for inclusion in OpenGL 4.1. 5 03/21/10 pbrown Minor wording updates to the spec overview, dependencies, issues, and body. 4 01/29/10 pbrown Update extension to accomodate the removal of fp64 vertex inputs from ARB_gpu_shader_fp64 (bug 5953). The API support for enumerating fp64 inputs and the GLSL support allowing fp64 vertex inputs now belongs to this extension. For the GLSL support, we add a "#extension" token to specify that fp64 vertex inputs should be allowed. Also, update several issues. 3 gsellers Updates based on discussion 2 gsellers EXT'ify. 1 pbrown Internal revisions.