blob: 17a57793e96a6d5af23047095b6eb130c7a1e1a0 [file] [log] [blame]
Name Strings
Graham Sellers, AMD
Pierre Boudier, AMD
Juraj Obert, AMD
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
... +others TBD
Graham Sellers, AMD (graham.sellers 'at'
Copyright (c) 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 3, 2013.
Ratified by the Khronos Board of Promoters on July 19, 2013.
Last Modified Date: 05/11/2017
Revision: 12
ARB Extension #158
OpenGL 1.1 is required.
This extension is written against the OpenGL 4.3 (Core) Specification,
February 14, 2013.
The definition of this extension depends on GL_EXT_direct_state_access
and GL_ARB_direct_state_access.
Recent advances in application complexity and a desire for higher
resolutions have pushed texture sizes up considerably. Often, the amount
of physical memory available to a graphics processor is a limiting factor
in the performance of texture-heavy applications. Once the available
physical memory is exhausted, paging may occur bringing performance down
considerably - or worse, the application may fail. Nevertheless, the amount
of address space available to the graphics processor has increased to the
point where many gigabytes - or even terabytes of address space may be
usable even though that amount of physical memory is not present.
This extension allows the separation of the graphics processor's address
space (reservation) from the requirement that all textures must be
physically backed (commitment). This exposes a limited form of
virtualization for textures. Use cases include sparse (or partially
resident) textures, texture paging, on-demand and delayed loading of
texture assets and application controlled level of detail.
New Procedures and Functions
void TexPageCommitmentARB(enum target,
int level,
int xoffset,
int yoffset,
int zoffset,
sizei width,
sizei height,
sizei depth,
boolean commit);
void TexturePageCommitmentEXT(uint texture,
int level,
int xoffset,
int yoffset,
int zoffset,
sizei width,
sizei height,
sizei depth,
boolean commit);
[[ Note: TexturePageCommitmentEXT is supported if and only if
the EXT_direct_state_access or the ARB_direct_state_access extension
is supported. ]]
New Tokens
Accepted by the <pname> parameter to TexParameter{i f}{v},
TexParameterI{u}v, GetTexParameter{if}v and GetTexParameterIi{u}v:
Accepted by the <pname> parameter of GetTexParameter{if}v and
Accepted by the <pname> parameter to GetInternalformativ:
Accepted by the <pname> parameter to GetIntegerv, GetFloatv, GetDoublev,
GetInteger64v, and GetBooleanv:
Additions to Chapter 8 of the OpenGL 4.3 (Core) Specification (Textures and
Add the "Supports Sparse Allocation" column to Table 8.12, "Sized internal
color formats"
| Sized Internal Format | Supports Sparse Allocation |
| R8 | Y |
| R8_SNORM | Y |
| R16 | Y |
| R16_SNORM | Y |
| RG8 | Y |
| RG8_SNORM | Y |
| RG16 | Y |
| RG16_SNORM | Y |
| R3_G3_B2 | |
| RGB4 | |
| RGB8 | |
| RGB565 | Y |
| RGB8 | |
| RGB8_SNORM | |
| RGB10 | |
| RGB12 | |
| RGB16 | |
| RGB16_SNORM | |
| RGBA2 | |
| RGBA4 | |
| RGB5_A1 | |
| RGBA8 | Y |
| RGB10_A2 | Y |
| RGB10_A2UI | Y |
| RGBA12 | |
| RGBA16 | Y |
| RGBA16_SNORM | Y |
| SRGB8 | |
| SRGB8_ALPHA8 | |
| R16F | Y |
| RG16F | Y |
| RGB16F | |
| RGBA16F | Y |
| R32F | Y |
| RG32F | Y |
| RGB32F | |
| RGBA32F | Y |
| R11F_G11F_B10F | Y |
| RGB9_E5 | Y |
| R8I | Y |
| R8UI | Y |
| R16I | Y |
| R16UI | Y |
| R32I | Y |
| R32UI | Y |
| RG8I | Y |
| RG8UI | Y |
| RG16I | Y |
| RG16UI | Y |
| RG32I | Y |
| RG32UI | Y |
| RGB8I | |
| RGB8UI | |
| RGB16I | |
| RGB16UI | |
| RGB32I | |
| RGB32UI | |
| RGBA8I | Y |
| RGBA8UI | Y |
| RGBA16I | Y |
| RGBA16UI | Y |
| RGBA32I | Y |
| RGBA32UI | Y |
Insert the following paragraph before Table 8.16:
the state is stored in the texture, but only takes effect the next time
storage is allocated for a texture using TexStorage*. If the value of
VIRTUAL_PAGE_SIZE_INDEX_ARB cannot be changed and an error is generated.
Append to Table 8.16: "Texture parameters and their values."
| Name | Type | Legal values |
| VIRTUAL_PAGE_SIZE_INDEX_ARB | int | any non-negative integer |
Add to the Errors table for TexParameter*
INVALID_OPERATION is generated if <pname> is TEXTURE_SPARSE_ARB or
the texture identified by <target> is TRUE.
INVALID_VALUE is generated if <pname> is TEXTURE_SPARSE_ARB, <pname>
is TRUE and <target> is not one of TEXTURE_2D, TEXTURE_2D_ARRAY,
Additions to Section 8.18 of the OpenGL Specification, "Texture Views"
Texture views may be created that reference sparse textures (see
Section 8.20.1), and in such cases, the view is considered to be sparse.
Should a texture view reference part or all of the tail of a sparse
texture, then modifications to the commitment of that tail via the view
affect the tail of the parent texture and all other views that reference
the tail, even for portions of the tail outside the controling view.
Additions to Section 8.19 of the OpenGL Specification, "Immutable-Format
Texture Images"
Add the following bullet point to the list of psuedo-operations performed
by all variants of TexStorage* (p.233):
* If TEXTURE_SPARSE_ARB is TRUE, only virtual address space is
allocated for the texture but physical backing store is not.
Physical store for pages of a virtual texture may be committed and
decommitted by calling TexPageCommitmentARB. The page size chosen
for the texture is taken from the texture's value of
VIRTUAL_PAGE_SIZE_INDEX_ARB. In this case, <width>, <height> and
<depth> must either be integer multiples of the selected virtual
page size in the X, Y and Z dimensions, respectively, or be less
than those dimensions. Additionally, the dimensions of sparse
textures must be compatible with the chosen value of
<internalFormat> as described in Section 8.20.1.
Add to the errors that may be generated by TexStorage*:
An INVALID_OPERATION error is generated if the texture's
TEXTURE_SPARSE_ARB parameter is TRUE and the value of its
VIRTUAL_PAGE_SIZE_INDEX_ARB parameter is greater than or equal to
NUM_VIRTUAL_PAGE_SIZES_ARB for the specified target and internal
An INVALID_VALUE error is generated if the texture's TEXTURE_SPARSE_ARB
parameter is TRUE and any of the following are true:
* <target> is TEXTURE_3D, and <width>, <height>, or <depth>
* <target> is not TEXTURE_3D, and <width> or <height> is greater
<depth> is greater than MAX_SPARSE_TEXTURE_ARRAY_LAYERS_ARB.
An INVALID_VALUE error is generated if the texture's
TEXTURE_SPARSE_ARB parameter is TRUE and <width> or <height> is greater
than the value of MAX_SPARSE_3D_TEXTURE_SIZE_ARB when <target> is
TEXTURE_3D, or if <height> or <depth> is greater than the value of
MAX_SPARSE_ARRAY_TEXTURE_LAYERS_ARB if <target> is a 1D or 2D array
texture target, respectively.
An INVALID_VALUE error is generated if TEXTURE_SPARSE_ARB is TRUE and
<width>, <height> or <depth> is is not an integer multiple of the
page size in the corresponding dimension.
then TexStorage* will generate an INVALID_OPERATION error if
* the texture's TEXTURE_SPARSE_ARB parameter is TRUE,
* <target> is one of TEXTURE_1D_ARRAY, TEXTURE_2D_ARRAY,
* for the virtual page size corresponding to the
VIRTUAL_PAGE_SIZE_INDEX_ARB parameter, either of the following is
- <width> is not a multiple of VIRTUAL_PAGE_SIZE_X_ARB *
2^(<levels>-1), or
- <height> is not a multiple of VIRTUAL_PAGE_SIZE_Y_ARB *
Insert Section 8.20, "Sparse Textures and Commitment" (p.238), renumber
subsequent sections.
Textures may be allocated such that their images' physical backing
store is only partially allocated. Only immutable format textures may
be sparsely allocated. To allocate a sparse texture, set a texture's
TEXTURE_SPARSE_ARB parameter to TRUE before allocating storage for it
with TexStorage*.
Insert Subsection 8.20.1, "Allocation of and Access to Sparse Textures"
Sparse textures are allocated setting a texture's TEXTURE_SPARSE_ARB
parameter to TRUE and then issuing one of the TexStorage* commands.
The dimensions of a sparse texture must be compatible with the internal
format chosen for the texture. Each internal format has zero or more
sparse page sizes that may be selected. The number of available page sizes
for an internal format and the dimensions of the pages may be determined
by calling GetInternalFormat* with the <pname> NUM_VIRTUAL_PAGE_SIZES_ARB
(for the number of available page sizes), VIRTUAL_PAGE_SIZE_X_ARB,
page widths, heights and depths, respectively). Not all internal formats
support sparse allocation. For those formats, the value of
NUM_VIRTUAL_PAGE_SIZES_ARB will be zero. The internal formats which are
guaranteed to support sparse allocation is listed in Table 8.12. Formats
not listed as supported in Table 8.12 may still be supported by some
The VIRTUAL_PAGE_SIZE_INDEX_ARB may be used to select the page layout for
a sparse texture. The value of the texture's VIRTUAL_PAGE_SIZE_INDEX_ARB
parameter is treated as an index into the array of possible page sizes
for the type and requested internal format of the texture, and matches
index of the array of values returned for the VIRTUAL_PAGE_SIZE_{XYZ}_ARB
internal format query.
When a sparsely committed texture is accessed by the GL, accesses that
require only samples contained in committed regions complete as normal.
For operations that access samples from uncommitted regions produce
the following behavior:
* Reads from such regions produce undefined data, but otherwise have
no adverse effect. This includes samples required for the
implementation of texture filtering, mipmap generation and so on.
* Writes to such regions are ignored. The GL may attempt to write to
uncommitted regions but the effect of doing so will be benign.
* Atomic operations with return values on uncommitted regions will
complete normally, but the returned value will be undefined and the
result of the atomic operation will be discarded.
* Reads and writes through framebuffers shall have no adverse effect,
but fragment shaders corresponding to uncommitted regions of the
framebuffer still execute to completion. Visible side effects
of these shaders such as operations on atomic counters, storage
blocks or committed regions of images are still seen, as are
the results of operations such as occlusion queries.
* Access to uncommitted regions by the client (for example through
ReadPixels or GetTexImage) shall have similar effect as through any
other part of the GL --- reads return undefined data and writes are
discarded, with no other ill effect.
Insert Subsection 8.20.2. "Controlling Sparse Texture Commitment"
If a texture is allocated using sparse storage (that is, its
TEXTURE_SPARSE_ARB parameter is TRUE) at the time that its storage is
allocated, it is initially created with only a virtual data store, and no
physical data store. Individual pages of a sparse texture may be made
resident or non resident by calling
void TexPageCommitmentARB(enum target,
int level,
int xoffset,
int yoffset,
int zoffset,
sizei width,
sizei height,
sizei depth,
boolean commit);
with <target> and <level> indicating the level of the texture object whose
residency is to be modified. <xoffset>, <yoffset>, <zoffset>, <width>,
<height> and <depth> are interpreted as they are in TexSubImage3D. An
error will be generated unless <xoffset>, <yoffset> <zoffset>, <width>,
<height> and <depth> specify a region of the texture level that is aligned
to multiples of the page size or to the edges of the texture.
If the value of <commit> is TRUE, then the texture pages contained in
the region defined by the values of <xoffset>, <yoffset>, <zoffset>,
<width>, <height> and <depth> are committed. If they were not committed
before the call, then new physical backing store is allocated and associated
with the sparse pages and their initial content is undefined. If the pages
were already committed, then they remain committed, no error is generated,
and the content of those pages remains unmodified. If the value of
<committed> is FALSE, then the texture pages contained in the region are
made de-committed. Their physical store is de-allocated, and their contents
again become undefined.
For the purposes of commitment, a cube map texture is treated as a 2D
array texture with a depth of six and cube map array textures are treated
as 2D array textures with a depth equal to six times the number of layers
in the cube map array.
For levels of a sparse texture where each dimension is a multiple of the
virtual page size, the residency of individual page-size regions is
controlled by TexPageCommitmentARB and such levels may be partially
populated. When the mipmap chain reaches a level that is not an integer
multiple of the virtual page size in any dimension, padding and memory
layout considerations may make it impossible to treat that level and
subsequent smaller ones as partially populated. The set of levels that
can be partially populated is implementation-dependent. The total number
of levels that may be partially populated may be queried by calling
GetTexParameteriv with the <pname> NUM_SPARSE_LEVELS_ARB.
The collection of texture levels that may not be partially populated, if
any, consists of levels NUM_SPARSE_LEVELS_ARB and higher, and is referred
to as the mipmap 'tail'. The levels comprising the tail are made resident
or non-resident as a unit. The tail is resident if and only if
TexPageCommitmentARB has been called successfully with <level> greater
than or equal to NUM_SPARSE_LEVELS_ARB and the value of <commit> was TRUE
for the last such call.
Views of sparse textures are also considered sparse. Modifications to
commitment of a texture via a view of it affect the parent texture and
any other views containing the modified pages. If a view of a sparse
texture references its tail (or is entirely contained within it),
modifications to commitment of the tail via the view will affect the entire
tail of the parent, even for parts of the tail that are not referenced
by the view. Furthermore, modifications to tail commitment may affect
views referencing other parts of the tail.
An INVALID_OPERATION error is generated if <xoffset> + <width> or
<yoffset> + <height> is greater than the width or height, respectively,
of level <level> of the texture bound to <target>.
An INVALID_OPERATION error is generated if <zoffset> + <depth> is
greater than
* the depth of level <level> of the texture bound to <target>, if
<target> is TEXTURE_3D;
* the number of layers of level <level> of the texture bound to
<target>, if <target> is TEXTURE_2D_ARRAY;
* six times the number of layers of level <level> of the texture bound
to <target>, if <target> is TEXTURE_CUBE_MAP_ARRAY; or
* one, for all other targets.
An INVALID_VALUE error is generated if <xoffset>, <yoffset>, or
<zoffset> is not a multiple of VIRTUAL_PAGE_SIZE_X_ARB,
the texture bound to <target>.
An INVALID_OPERATION error is generated if <width> is not an integer
multiple of VIRTUAL_PAGE_SIZE_X_ARB and <width> plus <xoffset> is not
equal to the width of level <level> of the texture bound to <target>.
An INVALID_OPERATION error is generated if <height> is not an integer
multiple of VIRTUAL_PAGE_SIZE_Y_ARB and <height> plus <yoffset> is not
equal to the height of level <level> of the texture bound to <target>.
An INVALID_OPERATION error is generated if <depth> is not an integer
multiple of VIRTUAL_PAGE_SIZE_Z_ARB and <depth> plus <zoffset> is not
equal to
* the depth of level <level> of the texture bound to <target>, if
<target> is TEXTURE_3D;
* the number of layers of level <level> of the texture bound to
<target>, if <target> is TEXTURE_2D_ARRAY;
* six times the number of layers of level <level> of the texture bound
to <target>, if <target> is TEXTURE_CUBE_MAP_ARRAY; or
* one, for all other targets.
An INVALID_OPERATION error is generated if the value of
<target> is FALSE.
[[ The following is only added if EXT_direct_state_access or
ARB_direct_state_access is supported. ]]
The command
void TexturePageCommitmentEXT(uint texture,
int level,
int xoffset,
int yoffset,
int zoffset,
sizei width,
sizei height,
sizei depth,
boolean commit);
may also be used to control the residency of sparse textures. This
command behaves identically to TexPageCommitmentARB, except that the
texture is identified by the name <texture> instead of via <target>.
An INVALID_OPERATION error is generated if <texture> is not the name of
an existing texture.
All other errors listed for TexPageCommitmentARB also apply to
TexturePageCommitmentEXT, except that references to "the texture bound
to <target>" should be replaced with "the texture <texture>", and all
other references to "<target>" should be replaced with "the target of
texture <texture>".
Additions to the AGL/GLX/WGL Specifications
GLX Protocol
New State
Append to Table 23.15, "Textures (state per texture object) (cont.)"
| Get Value | Type | Get Command | Initial Value | Description | Sec. |
| VIRTUAL_PAGE_SIZE_INDEX_ARB | Z+ | GetTexParameteriv | 0 | Virtual page size index | 8.19 |
| TEXTURE_SPARSE_ARB | B | GetTexParameteriv | FALSE | Texture sparseness | 8.19 |
| NUM_SPARSE_LEVELS_ARB | Z+ | GetTexParameteriv | 0 | Number of potentially sparse levels | 8.19 |
New Implementation Dependent State
Append to Table 6.42, "Implementation Dependent Values"
| Get Value | Type | Get Command | Minimum Value | Description | Sec. |
| MAX_SPARSE_TEXTURE_SIZE_ARB | Z+ | GetIntegerv | 16384 | Maximum 1D/2D/rectangle texture image | 8.19 |
| | | | | dimension for a sparse texture. | |
| MAX_SPARSE_3D_TEXTURE_SIZE_ARB | Z+ | GetIntegerv | 2048 | Maximum 3D texture image dimension | 8.19 |
| | | | | for a sparse texture. | |
| MAX_SPARSE_ARRAY_TEXTURE_LAYERS_ARB | Z+ | GetIntegerv | 2048 | Maximum number of layers in a sparse | 8.19 |
| | | | | array texture. | |
| SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB | B | GetBooleanv | - | TRUE if there are no restrictions on | 8.19 |
| | | | | the allocation of mipmaps in sparse | |
| | | | | textures and FALSE otherwise. | |
Dependencies on OpenGL 4.3 and ARB_texture_view
If the GL version is less than 4.3 or if ARB_texture_view is not supported,
then remove all references to texture views.
Dependencies on GL_EXT_direct_state_access and GL_ARB_direct_state_access
If neither the GL_EXT_direct_state_access nor the
GL_ARB_direct_state_access extensions is supported, remove all references
to TexturePageCommitmentEXT.
1) Do we want to mandate specific page sizes for specific formats?
2) What happened to MIN_SPARSE_LEVEL_AMD from the AMD spec? Do we need it
could not acceptably describe the case where a texture is technically
sparse, but no level of the texture may be sparsely populated. The
AMD specification disallowed creation of such a texture. However, this
extension does allow creation of a texture that is either wholly
resident or non-resident. Furthermore, if a view of a sparse texture
is created starting somewhere in the tail, then that whole view
is essentially sparse.
3) Should it be mandatory to support sparse allocation for compressed
RESOLVED: No, but in all likelihood, implementations will support some
or all compressed texture formats.
4) Are multisample textures supported? What about depth and stencil
format textures?
RESOLVED: No. Depth and stencil format textures are optional to support.
Providing support would be a case of reporting non-zero for
NUM_VIRTUAL_PAGE_SIZES_ARB for those formats. Multi-sample textures
are explicitly not supported by this extension as their targets are
excluded from TexStorage* support. Allowing support for these would
require a new extension, if only to remove the error generated
if one of the multi-sample targets is used with TexStorage* when
the sparse flag is set.
5) Do we need language clarifying completeness and the effects of
residency on completeness?
RESOLVED: Currently, there is no language. Textures allocated by
TexStorage* (which include all sparse textures) are always complete.
Residency doesn't effect that and sampling from them is well defined
(or explicitly undefined).
6) Can commitment fail? What happens if it does?
RESOLVED: An OUT_OF_MEMORY error is generated if physical backing cannot
be allocated for the previously allocated virtual space. No language
is added here as it is implicit that any command can generate
OUT_OF_MEMORY at any time for any reason... which includes new commands
introduced here.
7) Please explain, in plain English, what the rules are governing the size
of a texture's base level, mipmap levels, and the 'tail'.
The base level of the texture must be an integer multiple of the page
size in each dimension. This need not be a power of two or square or
anything of that nature. As we proceed along the mipmap chain, the
current level will become smaller and smaller, at each step halving in
size. At some point, the level dimensions will no longer be an integer
multiple of the page size, where the memory corresponding to that level
and smaller sized levels may not be evenly divided into pages. The
memory allocated to such levels may not be naturally aligned on memory
page boundaries or may be too small to bother with partial residency.
Implementations are permitted to treat such a level and all subsequent
levels as either fully resident or fully non-resident. We refer to
this set of levels as the mipmap "tail". The set of levels belonging
to the tail is implementation-dependent. Some implementations may
start the tail at the first level where any dimension is not the
multiple of a page size; others might pad out such allocations to page
boundaries and start the tail at a much smaller mipmap level. The tail
is made resident or non-resident as a unit; the tail is resident if and
only if <resident> was TRUE for the last call to TexPageCommitmentARB
when <level> was any value in the tail.
Clearly, making the base level a square power of two multiple of the
page size will mean that the greatest part of the texture can be sparse
and will minimize the size of the tail. However, it's perfectly legal,
with a hypothetical 256 x 256 texel page size to create a texture with
a base level of 4096 x 256. Such a texture can be sparse in the base
level, but level 1 would be 2048 x 128, which is no longer a multiple
of the page size, and therefore might be considered as the start of the
Some implementations may store the mipmap chain for array textures
and cubemaps such that the presence and size of mipmaps affects the
alignment of the start of each layer, even in the base level. Consider
an implementation that stores all layers of of level 0, then all of
level 1, then all of level 2 and so on. The presence of a mipmap chain
(or lack thereof) would have no effect on the alignment of layers 1
through N of the array (or cubemap faces). Now, consider an
implementation that stores all of the levels for layer 0, then all
levels of layer 1 and so on. The number and size of the levels of the
texture _would_ have an effect on the alignment of layers 1 through N
of the texture. If the size of the mipmap chain for a single layer
causes the next layer to become misaligned to the page size in linear
address space, then the texture cannot be sparsely populated. This flag
indicates whether the implementation has any restrictions on the size
of the mipmap chain. In particular, these restrictions ensure that,
while the texture may have mipmaps, the total size of the mipmap chain
for each level still satisfies the alignment restrictions required by
that implementation's virtual memory subsystem.
9) What happens when you create a view of a sparse texture?
RESOLVED: That view is sparse, as are views of that view and so on.
Also, if the view hits the tail, then modifications of tail residency
via the view affect the whole tail of the parent texture.
10) Why is there no TexturePageCommitmentARB?
There was originally no documented interaction between this extension
and ARB_direct_state_access. Since implementations that support both
extensions were shipped without TexturePageCommitmentARB, it is not
feasible to add this entry point after the fact. On the other hand,
implementations that support both extensions but *not*
EXT_direct_state_access should also be able to provide a DSA entry
point. Since every known implementation that supports this extension and
ARB_direct_state_access does have the TexturePageCommitmentEXT entry
point, making this fact retroactively part of the spec is an unusual
but pragmatic resolution.
Revision History
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
12 05/11/2017 nhaehnle Add interaction with ARB_direct_state_access
(bug 13684)
11 08/16/2013 pbrown Remove the <target> parameter from the DSA
function TexturePageCommitmentEXT() and also
add more explicit error language. The
parameter removal was agreed to before the
spec was published but didn't get added to the
shipping spec (bug 10445). Add missing
RG8_SNORM and RG16 entries to the formats
table and list them as supporting sparse
textures (bug 10709).
10 08/06/2013 pbrown Add spec langauge for the VIRTUAL_PAGE_SIZE_
INDEX_ARB texture parameter. Remove the
TexStorage error for a negative virtual page
size index, since that can be checked by
TexParameter. Fix the errors section for the
offset and sizes in TexPageCommitmentARB (bug
10387) and remove duplicate introductory
language describing alignment requirements.
Clarify spec language and issue (7) describing
the implementation-dependent sparse mipmap
"tail" (bug 10353) and guarantee that any
level that is a multiple of the page size is
not in the tail. Add spec language describing
TexturePageCommitmentEXT. Add a few missing
"_ARB" suffixes. Remove the "minimum maximum"
9 07/08/2013 gsellers Fix token value clash for
8 07/03/2013 gsellers Change MIN_SPARSE_LEVEL_ARB to
NUM_SPARSE_LEVELS_ARB (new token value).
Add language to describe views of sparse
textures, including tail residency issues.
Add issue 9.
7 06/13/2013 gsellers Assign enums. Add MIN_SPARSE_LEVEL_ARB to
state table.
6 06/07/2013 gsellers Bring back MIN_SPARSE_LEVEL_ARB.
5 06/06/2013 gsellers Multiple updates from bugs 10186, 10329,
10131, and 10353.
4 05/31/2013 gsellers Resolve several issues from bug 10186.
3 04/22/2013 gsellers Add column to tables to indicate which formats
support sparse allocation.
Add requirement that the base level of a sparse
texture must be an integer multiple of the
selected virtual page size.
Document that the tail of a mip-chain becomes
completely resident at the same time.
2 03/07/2013 gsellers Major overhaul from AMD version. Deleted
most things. Added:
* Set texture immutable state before calling
1 01/21/2013 gsellers Initial Revision based on AMD_sparse_texture