The original post is shown below, notes: Dxflag: for example, d3dusage_dynamic, d3dpool_default, d3dpool_managed, and d3dpool_systemmem give the driver some tips that we want to use these resources (static, dynamic ...), Whether these resources are managed or driven by the driver is determined. Some tendencies are: pool:
- D3dpool_default: resources are placed based on usage, which is basically video MEM and AGP mem.
- D3dpool_managed: there will be a backup in systemmemory. If necessary, copy to video/AGP mem.
- D3dpool_systemmem: Resources in the pure system memory. Basically, you don't need to do GPU-related directly or do something similar to updatesurface.
-
Usage: the driver is prompted which memory is allocated.
The AGP memory is determined by the BIOS. There is a viewer, memory. The allocated memory will be crossed out from the system memory, and the CPU end will not be able to do anything other than graphics. AGP is an Uncached memory, that is, the read and write speed on the CPU side is not fast, but it is faster than that on the CPU to read and write video memory. GPU reading speed is not fast, and it is slower than that on the video memory. Lockdriver will use a method similar to "buffer renaming" to optimize the lock. Such a flag like discard will have a good impact on the lock efficiency. First, we can see that the specified two identifiers are hints to the driver for how the buffer will be used, to optimize how the card accesses the data. they make sense even without AGP memory. on systems with AGP memory, there are three classes of memory: 1) system memory. This is cached, and reasonably fast to read from and write to with the CPU. however, it typically needs an additional copy before the graphics card can use it. system and scratch pool memory goes here.2) AGP memory. this is still CPU-local Ram, but it is not cached. this means that it's slow to read from, and it's slow to write to, unless you write sequentially, without doing too much other memory Traffic inbetween, and overwrite every byte, so that the write combiners don't need to fetch lines from Ram to do a combine. thus, generating software-transformed vertices as a stream into this buffer might still be fast. for the GPU, The AGP memory is directly accessible, so no additional copy is needed. dynamic pool memory goes here.3) video memory. this is Ram that's local to the GPU. it typic Ally has insanely high throughput. it is accessible over the bus for the CPU, but going over the bus is really slow; typically both for reading and for writing. thus writing directly into this memory (or even worse, reading out of it), is not recommended. default pool memory goes here. on systems with PCI-Express, some of the AGP vs system memory differences are supported Ced, but the usage hints you're Giving the driver ("I will change the data by writing it sequentially" vs "I will not change the data much") are still useful for optimizing performance. video memory is the memory chips physically located on the card. the card can easily access this memory, while reading it from the CPU is extremely slow. AGP memory a part of your main memory on the motherboard that has been set aside for talking t O the graphics card. the card and your CPU can access this memory at a decent speed. this pageshows that your BIOS "AGP aperture size" controls the size of your AGP memory, and explains how "cing the AGP aperture size won't save you any Ram. again, what setting the AGP aperture size does is limit the amount of ram the AGP bus can appropriate when it needs. it is not used unless absolutely ne Cessary. so, setting a 64 mb agp aperture doesn't mean 64 MB of your RAM will be used up as AGP memory. it will only limit the maximum amount that can be used by the AGP bus to 64 MB (with a usable AGP memory size of only 26 MB ). "1) video memory can mean one of two things depending on the context the term is used in:. video memory is generally any memory which is used by the graphics chip. b. video me Mory (correctly "local video memory") is memory that exists on the graphic card itself (I. e. RAM chips that live on the graphics card, they are 'local' to the graphics chip ). 2) AGP memory is main memory on your system motherboard that has been specially assigned for graphics use. the "AGP aperture" setting in your system BIOS controls this assignment. the more you have assigned for AGP use, the Le Ss you have for general system use. AGP memory is sometimes also known as "non-local video memory ". 3A) 'local' video memory is very fast for the graphics chip to read from and write to because it is 'local' to the graphics chip.3b) 'local' video memory is extremely slow to read from using for the system CPU, and reasonably slow to write to using the system CPU. this is for a number of reasons; par Tly because the memory is physically on a different board (the graphics card) to the CPU (I. e. it's not 'local' for the CPU); partly because that memory isn' t cached at all for reads using the CPU, and only burst cached for writes; partly due to the way data transfers over bus standards such as AGP must be done.4a) AGP memory is reasonably fast for the graphics chip to read from or write to, But n Ot as fast as local video memory.4b) AGP memory is fairly slow to read from using the system CPU because it is marked as "Write combined" so any reads don't benefit from the L2 and L1 caches (I. e. each read is too tively a cache-Miss ). AGP memory is however faster than local video memory to read from using the CPU since it is local to the cpu.4c) AGP memory is reasonably fast to write to using th E system CPU. although not fully cached, "Write combined" memory uses a small buffer that collects sequential writes to memory (32 or 64 bytes iirc) and writes them out in one go. this is why sequential access of vertex data using the CPU is preferable for performance.5) d3dusage_dynamic is only a hint to the display driver about how you intend using that resource, usually it will give you AGP mem Ory, But It isn' t guaranteed (so don't rely it !). 6) generally, for vertex buffers which you need to lock () and update using the CPU regularly at runtime shocould be d3dusage_dynamic, and all others shocould be static.7) graphics drivers use techniques such as "buffer renaming" where multiple copies of the buffer are created and cycled through to reduce the chance of stallwhen dynamic resources are locked. this is why it's essential to use the d3dlo Ck_discard and d3dlock_nooverwrite locking flags correctly if you want good performance. it's also one of the specified reasons you shouldn't rely on the data pointer from a lock () after the resource has been unlocked.8) general advice for good performance: -Treat all graphics resources as write-only for the CPU, fig. CPU reads from graphics resources is a recipe fo R slowness. -CPU writes to locked graphics resources shoshould be done sequentially. -It's better to write all of a vertex out to memory with the CPU than it is to skip elements of it. skipping can harm the specified tiveness of write combining, and even cause hidden reads in some situations (and reads are bad-see abve ). since the "local video memory" is fast for video card to manipulate, and the video Card dedicated to graphics process, why bother to use the "AGP memory "? Is that only because the "local video memory" may be not enough for graphic data storage? What role does the CPU play in the process of graphics ?? Yes. That's one of the main reasons. AGP comes from a time (~ 10 years ago !) When a typical graphics card wowould have, say, 2 MB of local video memory and a typical PC system had 64-128 MB of main system memory, so it made sense to set some system memory aside for situations where there wasn' t enough local memory. in these days of monster graphics cards with 512 MB of local video memory, it's less likely used as an overflow. another reason is dynamic graphics data-any data that needs to be regularly modified with the CPU is usually better off in AGP memory (It's write combined, but it's local to the CPU too, so uses less CPU time to access) not very much these days. mostly application-side jobs like writing vertex data into locked buffers, object culling, traversing scene graphs, loading resources into main memory, things like that. on the d3d and device driver side: handling the d3d API, swizzling and other conversion when some types of resources are locked/unlocked [I believe some GPUs can even do their own swizzling now though], and setting up the command buffer for the GPU. before hardware T & L, the CPU also handled all vertex processing. the fact that modern GPUs now handle so much of the graphics pipeline makes avoiding unnecessary serialization between CPU and GPU all the more important (I. e. stils where one has a resource locked and the other wants to use it), thus things like buffer renaming. serialization between CPU and GPU throws away the GPUs processing ability.
