blob: 3d7b948d13bf988d30cb7c0a5afe82903a417d92 [file] [log] [blame]
Name Strings
Roy Blackmer, ATI Technologies
Bruno Stefanizzi, ATI Technologies
Andreas Wolf, ATI Technologies
Evan Hart, ATI Technologies
Bruno Stefanizzi, AMD (bruno.stefanizzi 'at'
Date: March 2, 2009
Revision: 0.2
OpenGL 1.1 is required
ARB_vertex_buffer_object affects the defintion of this extension
EXT_framebuffer_object affects the definition of this extension
This extension is written against the 2.0 version of the OpenGL
Specification, modified with EXT_framebuffer_object.
Traditionally, OpenGL has treated resource management as a task of hardware
virtualization hidden from applications. While providing great portability,
this shielding of information can prevent applications from making
intelligent decisions on the management of resources they create. For
instance, an application may be better served by choosing a different
rendering method if there is not sufficient resources to efficiently
utilize its preferred method.
1) Revealing the management of memory directly is somewhat controversial,
is this really desirable?
The intent of this extension is to provide insight into the consumption
of memory. It does not require that exact values be returned. The
information is intended to be a hint to the application about the
status at a particular moment in time. As such, the value returned does
not need to reveal the exact information, but instead it could return
a conservative value of 80% of actual availability. In any case, it is
highly reccommended that the information be returned in kilobytes.
2) Memory can come from different pools that may interact. How should this
be dealt with?
The queries will enumerate different classes of memory based on modern
OpenGL paradigms. The classes defined so far are texture, vertex
buffer, an render buffer. These correspond to API visible capabilities
such as readable, writable, and mapable. The memory between these pools
may often be shared, so allocations in one pool may reduce all pools.
3) Are the abreviations and names correct?
Probably not.
4) How should the values be returned?
Returning all information about a memory type in a single query is
most optimal. Values are returned as 4 integers: total pool available,
largest pool available, total auxilliary pool available, and largest
auxilliary pool available. Auxilliary pool are for remote memory.
New Functions and Procedures
New Tokens
Accepted by the <value> parameter of GetIntegerv:
Additions to Chapter 2 of the 2.0 Specification (OpenGL Operation)
Additions to Chapter 3 of the 2.0 Specification (Rasterization)
Additions to Chapter 4 of the 2.0 Specification (Per-Fragment Operations
and the Frame Buffer)
Additions to Chapter 5 of the 2.0 Specification (Special Functions)
Additions to Chapter 6 of the 2.0 Specification (State and State Requests)
Section 6.1.x, Memory Information Queries
Inserted between sections 6.1.14 and 6.1.15
Information on the current memory resources available can be queried
RENDERBUFFER_FREE_MEMORY_ATI as the value parameter to GetIntergerv.
These return the memory status for pools of memory used for vertex
buffer objects, textures, and render buffers respectively. The
memory status is not meant to be an exact measurement of the system's
current status (though it may be in some implementations), but it is
instead meant to represent the present load such that an application
can make decisions on how aggressive it can be on the allocation of
resources without overloading the system. The query returns a 4-tuple
integer where the values are in Kbyte and have the following meanings:
param[0] - total memory free in the pool
param[1] - largest available free block in the pool
param[2] - total auxiliary memory free
param[3] - largest auxiliary free block
These values are only useful as a hint as the implementation cannot
guarantee the lack of allocations between commands, and the
information may have changed before the attempt to use it. Auxiliary
memory is memory that an implementation may use as a backup to its
primary pool for a certain type of allocation. The pools are not
guaranteed to be either independent or shared, as this is an
implementation choice.
Additions to the OpenGL Shading Language specification
Additions to the GLX Specification
Dependencies on ARB_vertex_buffer_object or OpenGL version 1.5
If ARB_vertex_buffer_object or OpenGL version 1.5 is supportedd, then
the query for VBO_FREE_MEMORY_ATI is available.
Dependencies on EXT_framebuffer_object
If EXT_framebuffer_object is implemented, then the query for
GLX protocol
Revision History
2009/03/02 (Jon Leech) - format version 0.2 received from ATI
to remove GL_ prefix, assign extension number.