O'Reilly logo

OpenGL Insights by Christophe Riccio, Patrick Cozzi

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Monitoring
Graphics Memory Usage
Aleksandar Dimitrijevi
´
c
38.1 Introduction
The str uggle to achieve higher levels of realism in computer graphics always l eads
to high memory demands. Despite the fact that modern graphics accelerators are
equipped with more and more onboard memory with each new generation, applica-
tions’ demands grow even faster. Since memory is a limited and expensive resource,
an application needs tools to help it make clever decisions on how this resource can
be used more effectively.
Until several years ago, OpenGL implementations hid resource management
from applications. The resource shielding was justified by stating that it enabled
a hardware abstraction and a higher level of portability. However, the knowledge
about the environment in which an application is executing is more than useful.
There is a wide variety of graphics cards, each card with different GPU power and an
arbitrary amount of onboard memory. Furthermore, nowadays many computers are
equipped with more than one graphics card that can be used for scalable rendering
(see Chapter 27). Which of them should be used for a specific task depends on their
capabilities (see Chapter 9). Even on a single-accelerator system, an application can
make wise decisions, like which level of detail or algorithms to apply, according to
available resources. Knowledge about the maximum available resources is useful for
the initial setup, but the current state must be tracked during the whole applications
life. The reasons for varying available resources can be various, from the complexity
535
38
536 VI Debugging and Profiling
of the current scene to a competition between different applications for the same
resource.
In this chapter, we take a look at graphics memory allocation and how its current
status can be retrieved using two vendor-specific OpenGL extensions.
38.2 Graphics Memory Allocation
Graphics memory can be classified into two major categories: dedicated and shared.
Dedicated graphics memory is memory associated with the graphics subsystem, and
it is exclusively accessed by graphics applications. It can be either onboard memory
(dedicated video memory) or a portion of system memory (system video memory).
Onboard memory is a privilege of discrete graphics adapters. It usually uses a wide
and high-speed local bus, resulting in much better performance compared to sys-
tem memory. Integrated graphics adapters can only use portions of system memory
as dedicated video memory. The allocation of system video memory can be done
by BIOS or by a driver. System BIOS allocation is done at a system startup, ef-
fectively hiding a portion of the memory from the operating system, while driver’s
memory allocation happens during operating system boot. In the second case, the
operating system reports dedicated graphics memory as a part of system memory al-
though it is exclusively owned by the graphics driver and cannot be used for other
purposes.
Shared system memory is a portion of the system memory that can be used by
the graphics subsystem when needed. This memory can be used by nongraphics
applications as well; hence, there is no guarantee that it is available. The amount of
shared system memory reported by the operating system, like Vista or Windows 7,
is the maximum amount. The actual amount depends on the system load. More
detailed information about memory classification and reporting through Windows
Display Driver Model (WDDM) can be found in [Microsoft 06].
Total available graphics memory is a sum of dedicated graphics memory and
shared system memory. The highest performance is achieved if the graphics objects
are stored in dedicated graphics memory. However, in some applications, the capacity
of dedicated memory is not enough to store all objects. If newly allocated objects, or
objects currently being used, cannot be stored in dedicated memory, the driver has
to evict some of the objects already stored in order to make space for new ones. An
GL
OUT OF MEMORY exception should be raised only if the object cannot be allocated
in dedicated or in shared system memory.
Querying memory status is not a part of the OpenGL core functionality, but
the two major graphics cards vendors have published some useful extensions for the
purpose. The following sections give a closer look at those extensions.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required