• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    NV_query_resource
4
5Name Strings
6
7    GL_NV_query_resource
8
9Contact
10
11    Kevin Lefebvre, NVIDIA (klefebvre 'at' nvidia.com)
12
13Contributors
14
15Status
16
17    Under review.  Target release in NVIDIA 387.00 drivers.
18    NVIDIA's Tegra drivers will not expose this extensions.
19
20Version
21
22    Last Modified Date: May 4, 2017
23    Author Revision: 0.1
24
25Number
26
27     OpenGL Extension #511
28
29Dependencies
30
31    OpenGL 2.0 is required.
32    The extension is written against the OpenGL 2.0 Specification.
33
34Overview
35
36    OpenGL implementations manage the residence of textures, shaders, and
37    other graphical objects in GPU accessible memory (whether in on-board
38    video memory or addressable system memory is implementation dependent).
39    With more insight into OpenGL's memory usage 1) applications could make
40    educated decisions on better utilizing the limited GPU resources,
41    2) users could better optimize their workflow when working with multiple
42    tools, and 3) administrators can make better decisions regarding resource
43    allocation and system configurations.
44
45    The purpose of this extension is to return a more detailed breakdown
46    of memory usage in terms of the OpenGL objects residing in memory
47    (textures, render buffers, buffer objects, system reserved objects, ...).
48    This extension differs from GL_NVX_gpu_memory_info in that this extension
49    returns detailed memory usage at the object level for video memory while
50    the other extension only reports total vidmem usage.
51
52    For the purposes of this specification the term vidmem refers to video
53    memory resident on the graphics card that is directly accessible to the
54    GPU at the highest performance level.
55
56New Procedures and Functions
57
58    int QueryResourceNV(enum queryType, int pname, unsigned int bufSize,
59                        int *buffer);
60
61New Tokens
62
63    Accepted by the <queryType> parameter of QueryResource:
64
65        QUERY_RESOURCE_TYPE_VIDMEM_ALLOC_NV         0x9540
66
67    New enums defined:
68
69        QUERY_RESOURCE_MEMTYPE_VIDMEM_NV            0x9542
70        QUERY_RESOURCE_SYS_RESERVED_NV              0x9544
71        QUERY_RESOURCE_TEXTURE_NV                   0x9545
72        QUERY_RESOURCE_RENDERBUFFER_NV              0x9546
73        QUERY_RESOURCE_BUFFEROBJECT_NV              0x9547
74
75Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
76
77    none
78
79Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
80
81    none
82
83Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment
84Operations and the Frame Buffer)
85
86    none
87
88Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)
89
90    none
91
92Additions to Chapter 6 of the OpenGL 2.0 Specification (State and
93State Requests)
94
95    Section 6.1.x GPU Query Resource
96
97    The command QueryResourceNV returns GL object usage of video memory in the
98    application provided buffer. Both a summary of the total vidmen allocated
99    by the driver is written along with a more detailed breakdown of memory
100    used by the GL objects created by the application (textures, render buffers
101    buffer objects, ...). Memory sizes reported are in kilobytes.
102
103    Due to various factors with the OpenGL driver the amount of memory in use
104    by GL objects may not equal the amount of memory actually allocated.
105    Alignment issues, freed but not released objects, or  memory block
106    sub-allocation options may result in the driver holding more memory than
107    what can be accounted for by the total memory used by the GL objects. This
108    command will report both the memory used by GL objects and the amount of
109    memory free but allocated by the driver.
110
111    Currently the queryType parameter only accepts the type VIDMEM_ALLOC_NV
112    leaving future extensions possible. The param parameter is reserved for
113    future usage. The bufSize parameter indicates the size of the application
114    provided buffer in ints where the query results are returned. The buffer
115    parameter points to this return buffer. The commands return value is the
116    number of ints written in the return buffer. If the return value is
117    negative then the buffer is too small to hold the returned data. If the
118    buffer pointer is NULL then the return value specifies the size of buffer
119    needed to hold the results from the query call.
120
121    The format of the returned data from a query is a series of int's of the
122    form:
123
124    fixedHeader
125        size - size of fixed header(in int's)
126        version - data stream version number (version = 1 at this time)
127        devCount - count of devices
128    deviceBlk[i from 0 to devCount - 1]
129        size - size of per device info including detail blocks (in int's)
130        numAllocs - number of GL object allocations
131        vidmem - size of vidmem in use by GL objects
132        vidmemFree - size of vidmem allocated but not in use
133        detailCount - number of detail blocks
134        detailBlk[j from 0 to detailCount - 1]
135            size - size of single detail block (in int's)
136            memType - only vidmem at this time
137            objType - GL object type
138            numAllocs - number of objects of this objType
139            vidmem - amount of memory used for this objType
140
141    For decoding the detail blocks the following constants are defined:
142
143        memType:
144            QUERY_RESOURCE_MEMTYPE_VIDMEM_NV
145
146        objType:
147            QUERY_RESOURCE_SYS_RESERVED_NV
148            QUERY_RESOURCE_TEXTURE_NV
149            QUERY_RESOURCE_RENDERBUFFER_NV
150            QUERY_RESOURCE_BUFFEROBJECT_NV
151
152Errors
153
154    None
155
156New State
157
158    None
159
160Issues
161
162    1) With Windows 10 comes additional capabilities with respect to how much
163       vidmem an applicaiton can really gain access to and what happens when
164       the application comes under memory pressure. These capabilities include
165       OS vidmem budget levels, application setting a vidmem reservation as a
166       hint to the OS in an attempt to reduce memory thrashing, and what
167       allocations will be forced out of vidmem (into sysmem if the allocation
168       permits it). Should this extension try to report some of this
169       information?
170
171       PROPOSED RESOLUTION: This extension as written currently describes the
172       mem usage at a point in time that is only valid at the time of
173       calling. If this level of information is not sufficient to meet the
174       ISV and User needs then we should consider adding some of the Window 10
175       capabilities (abstracted for other OS/s if possible) in a follow-on
176       extension.
177
178Revision History
179
180    Rev.    Date    Author     Changes
181    ----  -------- ---------  ------------------------------------------------
182    1     05/04/17 klefebvre  First draft
183
184          Changes from NVX version of extension:
185            - fix function prototype of QueryResourceNV
186            - remove queryType SUMMARY, default to DETAILED, leave queryType
187              parameter for future extension
188            - add size entries to each return record to support future
189              addition of data and have backwards compatability to decoder
190            - rework format of buffer return data
191
192
193