System memory,AGP memory和video memory

在学习图形学、GPU编程的时候的时候，经常遇到这三种存储区，下面简要总结一下。

system   memory  （main memory） :  

 就是电脑的内存条上的，一般都很大。显卡不能访问 。

video memory:

 就是显示卡上的显存，一般是32，64，128M这样，速度最快，显卡可直接访问 。用来描述电脑上一些可写存储区，通常是RAM，用来保存图形卡所需要的用来驱动显示设备的信息。在现代3D图形卡中，video memory也可用来保存3D向量数据，纹理，缓冲区等等，有时候以共享存储结构的形式出现。

AGP   memory：   

Accelerated Graphics Port，加速图形接口，AGP是一种接口规范，可以使3D图形在普通个人电脑上以更快的速度显示，AGP是一种设计用来更快，更平稳传送3D图形的接口，它使用戈尔那电脑的主内存来刷新显示器显示的图像，支持纹理贴图，零缓冲和阿尔法混合等3D图形技术。它实际上还是内存的一块，但是显示卡通过AGP专用通道对它直接访问，速度在前两者中间。

GPU缓存层次结构：

 

再来看龙书上的说明:

来自龙书P41

1.3.4 Memory Pools
Surfaces and other Direct3D resources can be placed in a variety of
memory pools. The memory pool is specified by one of the members of
the D3DPOOL enumerated type. The memory pools available are:
D3DPOOL_DEFAULT—The default memory pool instructs
Direct3D to place the resource in the memory that is best suited
for the resource type and its usage. This may be video memory,
AGP memory, or system memory. Note that resources in the
default pool must be destroyed (released) prior to an IDirect-
3DDevice9::Reset call, and must be reinitialized after the reset
call.
D3DPOOL_MANAGED—Resources placed in the manage pool are
managed by Direct3D (that is, they are moved to video or AGP
memory as needed by the device automatically). In addition, a
back-up copy of the resource is maintained in system memory.
When resources are accessed and changed by the application, they
work with the system copy. Then, Direct3D automatically updates
them to video memory as needed.
D3DPOOL_SYSTEMMEM—Specifies that the resource be placed in
system memory
D3DPOOL_SCRATCH—Specifies that the resource be placed in system
memory. The difference between this pool and D3DPOOL_
SYSTEMMEM is that these resources must not follow the graphics
device’s restrictions. Consequently, the device cannot access
resources in this pool. But the resources can be copied to and from
each other.

 

创建surface时,需要指定在哪个缓冲区去创建

 

来自《Advanced 3D Game Programming with Direct9X》P42

Surfaces
2D images in Direct3D are wrapped by objects called surfaces. Internally, a surface is just a structure
that manages image data as a contiguous block of memory. Because of this you see the concept of a
surface being used in lots of places in DirectX to take care of different types of data, from vertex buffers
to sound buffers. The structure keeps track of the vital statistics of the surface, such as its height, width,
and format of the pixel. You create them using the Direct3D object and use the IDirect3DSurface9
interface to play with them.

P44

Describing Surfaces
When you create surfaces or request information about surfaces, the capabilities and vital statistics for
the surface are inscribed in a structure called the surface description. The surface description is
represented by the D3DSURFACE_DESC structure and has the following definition:

typedef struct _D3DSURFACE_DESC {
D3DFORMAT Format;
D3DRESOURCETYPE Type;
DWORD Usage;
D3DPOOL Pool;
UINT Size;
D3DMULTISAMPLE_TYPE MultiSampleType;
DWORD MultiSampleQuality;
UINT Width;
UINT Height;
} D3DSURFACE_DESC;

 

 

P49

Surfaces and Memory
Surfaces can exist in system RAM or in the video card's memory. Where you should put the surface
depends on what you want to do with it. Blits between system RAM and video RAM are slow because
the data needs to be transferred over the system bus. The bus usually runs at a lower clock rate than
the system RAM or the video card, causing both of them to sit around waiting for the bits to be sent.
In general, surfaces that get blitted on top of each other should be in the same region of memory if
possible. For example, say you are composing a scene with hundreds of blitted images like in a
complex 2D game. Since you probably won't be able to fit all of the surfaces in video memory, you need
to plan to have at least a few of them in system memory. The blind algorithm would be to blit each of the
surfaces onto the back buffer. The surfaces in video memory would blit much faster, because they not
only don't need to go over the bus, they can be blitted by the 2D hardware. Conversely, the system
memory surfaces can hurt the application greatly.

 

P53

Creating Direct3D Surfaces
Creating surfaces used to be a total pain before version 9.0 came out. You had to fill out massive
annoying structures that contained an unbelievable amount of entries and substructures. Couple that
with poor, badly structured documentation, and it was no wonder that so many people found the
learning curve for DirectX Graphics so steep.
Luckily these days all that is gone and all you have to do is make a simple call to a function called
IDirect3DDevice9::CreateOffscreenPlain- Surface().

HRESULT CreateOffscreenPlainSurface (
UINT Width,
UINT Height,
D3DFORMAT Format,
D3DPOOL Pool,
IDirect3DSurface9** ppSurface
HANDLE* pHandle
);

 

Width-----------The width that you want the new surface to be, in pixels.

Height-----------The height that you want the new surface to be, in pixels.

Format-----------A member of the D3DFORMAT enumerated type, specifying the format for the
surface. You can see the full list of possible values for this parameter earlier in the
chapter in the table for D3DSURFACE_DESC structure. However, you will usually
want to set this to D3DFMT_ A8R8G8B8 for 32-bit surfaces. For more information,
see DirectX 9.0 C++ Documentation/DirectX Graphics/Direct3D C++
Reference/Enumerated Types/D3DFORMAT.

Pool-----------The type of surface pool to use

ppSurface-----------Takes the address of a pointer that will be filled with the address of the newly
created surface.

pHandle-----------Reserved. Set this parameter to NULL.

 

Listing 2.1: Creating a new image surface

HRESULTr=0; LPDIRECT3DSURFACE9 pSurface = 0;
r = g_pDevice->CreateOffscreenPlainSurface( 640, 480, D3DFMT_A8R8G8B8,
D3DPOOL_MANAGED, &pSurface, NULL );
if( FAILED(r))
{
// Error
}
// Success!

 

另外创建缓冲区也需要指定位置

龙书P75

3.1 Vertex/Index Buffers
Vertex and index buffers are similar interfaces and share similar methods;
therefore we cover them together. A vertex buffer is simply a
chunk of contiguous memory that contains vertex data. Similarly, an
index buffer is a chunk of contiguous memory that contains index data.
We use vertex and index buffers to hold our data over arrays because
vertex and index buffers can be placed in video memory. Rendering
data from video memory is done much faster than rendering data in
system memory.

 

HRESULT IDirect3DDevice9::CreateVertexBuffer(
UINT Length,
DWORD Usage,
DWORD FVF,
D3DPOOL Pool
IDirect3DVertexBuffer9** ppVertexBuffer,
HANDLE* pSharedHandle
);
HRESULT IDirect3DDevice9::CreateIndexBuffer(
UINT Length,
DWORD Usage,
D3DFORMAT Format,
D3DPOOL Pool,
IDirect3DIndexBuffer9** ppIndexBuffer,
HANDLE* pSharedHandle
);

 

 

Usage—Specifies some additional properties about how the buffer
is used. This value can be zero, indicating no additional properties,
or a combination of one or more of the following flags:
D3DUSAGE_DYNAMIC—Setting this flag makes the buffer
dynamic. See the notes on static and dynamic buffers on the
following page.
D3DUSAGE_POINTS—This flag specifies that the buffer will
hold point primitives. Point primitives are covered in “Particle
Systems” in Chapter 14. This flag is used only for vertex
buffers.
D3DUSAGE_SOFTWAREPROCESSING—Vertex processing is
done in software.
D3DUSAGE_WRITEONLY—Specifies that the application will
only write to the buffer. This allows the driver to place the
buffer in the best memory location for write operations. Note
that reading from a buffer created with this flag will result in an
error.

 

Pool—The memory pool in which the buffer is placed

 

 

Note: A buffer created without the D3DUSAGE_DYNAMIC flag is called
a static buffer. Static buffers are generally placed in video memory
where its contents can be processed most efficiently. However, the
trade-off of making a buffer static is that writing to and reading from
the memory of a static buffer is inherently slow because accessing
video memory is slow. For this reason we use static buffers to hold
static data (data that will not need to be changed (accessed) very frequently).
Terrains and city buildings are examples of good candidates
for static buffers because the terrain and building geometry will usually
not change during the course of the application. Static buffers should
be filled with geometry at application initialization time and never at
run time.
Note: A buffer created with the D3DUSAGE_DYNAMIC flag is called a
dynamic buffer. Dynamic buffers are generally placed in AGP memory
where its memory can be updated quickly. Dynamic buffers are not
processed as quickly as static buffers because the data must be transferred
to video memory before rendering, but the benefit of dynamic
buffers is that they can be updated reasonably fast (fast CPU writes).
Therefore, if you need to update the contents of a buffer frequently, it
should be made dynamic. Particle systems are good candidates for
dynamic buffers because they are animated, and thus their geometry
is usually updated every frame.
Note: Reading video memory and AGP memory from your application
is very slow. Therefore, if you need to read your geometry at run
time, it is best to keep a local system memory copy and then read from
that.