blob: ca3e53208de11d992bf4873e5124ddef62f0cf6d [file] [log] [blame]
Name Strings
Graham Sellers, AMD (graham.sellers 'at'
Pat Brown, NVIDIA (pbrown 'at'
Piers Daniell, NVIDIA (pdaniell 'at'
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
Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at
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
Complete. Approved by the ARB on June 9, 2010.
Approved by the Khronos Board of Promoters on July 23, 2010.
Last Modified Date: June 10, 2014
Revision: 10
ARB Extension #99
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.
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
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 <type> parameter of GetActiveAttrib:
DOUBLE_MAT2x3 0x8F49
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
<index> 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 <index> 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.
<type> must be DOUBLE. <index>, <size>, and <stride> behave as defined in
all other vertex commands; <size> 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 <index> 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 -- <vaobj>
identifies a vertex array object used instead of the currently bound one,
<buffer> is used in place of the buffer object bound to ARRAY_BUFFER, and
the command otherwise behaves like VertexAttribLPointer with <pointer>
set to <offset>.)
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
<i>, its value(s) are taken from the components of generic attribute <i>.
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
<i> and <i>+1 (mat2, dmat2), from attributes <i> through <i>+2 (mat3x2),
or from attributes <i> through <i>+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 <i>+1 (mat2x3), from
attributes <i> through <i>+2 (mat3), or from attributes i through <i>+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 <i> and <i>+1 (mat2x4), from attributes <i> through
<i>+2 (mat3x4), or from attributes <i> through <i>+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)
(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
Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification
(Per-Fragment Operations and the Frame Buffer)
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
(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
<index>. 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)
Additions to the AGL/GLX/WGL Specifications
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 : <behavior>
where <behavior> 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.
For all VertexAttrib* commands, the error INVALID_VALUE is generated if
<index> is greater than or equal to MAX_VERTEX_ATTRIBS.
For VertexAttribLPointer, VertexAttribLFormat, and
VertexArrayVertexAttribLOffsetEXT, the error INVALID_VALUE is generated if
<index> is greater than or equal to MAX_VERTEX_ATTRIBS.
New State
New Implementation Dependent State
(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
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
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
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.