D3d lock pool

One Pool

 

D3d rutime memory types include video memory (VM), AGP memory (AM), and system memory (SM ),
All d3d resources are created in these three types of memory. When creating resources, we can specify the following storage flag,
D3dpool_default, d3dpool_managed, d3dpool_systemmem, and d3dpool_scratch.
VM is located on the graphics card memory, the CPU can only access through the AGP or PCI-E bus, read and write speed is very slow,
The number of consecutive VM writes on the CPU is slightly faster than the read speed because 32 or 64 bytes are allocated to the cache when the CPU writes to the VM (depending on the cache line length)
Write buffer, when the buffer is full, it will be written to the VM at a time; SM is the system memory, CPU reads and writes are very fast,
Because SM is cached to Level 2 buffer, but the GPU cannot directly access the system buffer, the resources created in SM are,
GPUs cannot be used directly. am is the most troublesome type and actually exists in the system memory,
However, this part of MEM will not be cached by the CPU, which means that the CPU read and write am will write a cache missing before accessing am through the memory bus,
Therefore, CPU read/write am is slower than SM, but continuous write is slightly faster than read,
The reason is that the CPU write am uses write combining, And the GPU can access am directly through the AGP or PCI-E bus.

If we use d3dpool_default to create resources, it means that d3d runtime can be used according to the specified resources.
Method to automatically use the storage type, generally Vm or AM, the system will not perform additional backup elsewhere, when the device is lost,
These resources are also lost. However, the system does not use d3dpool_systemmem or d3dpool_managed during creation.
To replace it. Note that they are completely different pool types. The texture created to d3dpool_default cannot be locked by the CPU,
Unless it is a dynamic texture. However, the vb ib rendertarget back buffers created in d3dpool_default can be locked.
When you use d3dpool_default to create a resource, if the memory is used up, the managed resource will be swapped out to release enough space.
D3dpool_systemmem and d3dpool_scratch are both in SM. The difference is that when d3dpool_systemmem is used,
The resource format is limited by device performance, because the resource is likely to be updated to AM or VM for use by the graphics system,
But scratch is only limited by runtime, so such resources cannot be used by graphics systems.
D3druntime optimizes d3dusage_dynamic resources. Generally, it is placed in AM, but it cannot be completely guaranteed.
In addition, why static textures cannot be locked, but dynamic textures are all related to the d3d runtime design,
It will be described in the subsequent d3dlock description.

D3dpool_managed indicates that d3d Runtime is used to manage resources. The created resources are copied in two copies, one in SM,
A copy is stored in the VM/AM, L is placed in the SM during creation, and d3d runtime automatically copies data
In the VM, when the resource is modified by the GPU, runtime automatically updates it to the SM when necessary,
After modification in SM, it will also be updated to the VM. Data that is frequently modified by the CPU or GPU,
Do not use the hosting type, which will produce a very expensive synchronization burden. When the lost device occurs,
During reset, runtime automatically uses copy in SM to restore VM data.

 

Binary lock

 

What happens if you lock the default resource? The default resource may be in VM or am. If it is in VM,
A temporary buffer must be opened in the System Content and returned to the data.ProgramAfter the data is filled in to the temporary buffer,
During unlock, the runtime will transmit the temporarily buffered data back to the VM. If the resource d3dusage attribute is not writeonly,
The system also needs to copy a copy of the original data from the VM to the temporary buffer, which is why the writeonly parameter is not specified.
The reason for program performance. Note the need to pay attention to CPU write am, because CPU write am is generally write combining,
That is to say, the write is buffered to a cache line. When the cache line is full, it is flushed to AM,
The first thing to note is that the write data must be weak order (graphic data generally meets this requirement ),
It is said that d3druntime and NV dirver have a small bug, that is, when the CPU is not flushed to AM, the GPU starts to draw related resources.
In this case, use the command flush cache line, such as sfence. Second, try to fill a cache line at a time,
Otherwise there will be extra latency, because the CPU must flush the entire cache line to the target each time, but if we only write part of the line,
The CPU must first read the entire line long data combine from AM and then flush again. Third, write in sequence as much as possible,
Random write will make write combining cumbersome. If it is a random write resource, do not use d3dusage_dynamic to create it,
Use d3dpool_managed to complete writing in SM.

Common textures (d3dpool_default) cannot be locked because they are in the VM and can only be locked through updatesurface and
When updatetexture is used for access, why does d3d not let us lock the static texture, but let us lock the static vb ib? I guess possible
There are two reasons: first, the texture matrix is generally very large, and the texture is stored in two-dimensional mode within the GPU;
Second, the texture is stored in native format inside the GPU, not in plaintext enrgba format. Dynamic texture
This Texture needs to be modified frequently, so d3d will be specially stored. Dynamic textures with high-frequency modifications are not suitable for dynamic attribute creation,
There are two cases: rendertarget written by the GPU and texture video written by the CPU,
We know that dynamic resources are generally placed in the AM, GPU access to the am needs to pass through the AGP/PCI-E bus, the speed is much slower than the VM,
CPU access am is much slower than SM. If the resource is dynamic, it means that the GPU and CPU access resources will be continuously delayed,
Therefore, it is best to create a copy of this type of resource with d3dpool_default and d3dpool_systemmem respectively. It is better to manually perform bidirectional updates on your own.
Do not create rendertarget with the d3dpool_managed attribute. This is extremely inefficient and the cause is analyzed by yourself.
For resources with less frequent changes, we recommend that you use default to create and manually update the resource, because the efficiency of One update is compromised.
The loss is far less than the loss caused by GPU persistent access to AM.

Unreasonable lock will seriously affect program performance, because generally the lock needs to wait for all the draw commands before the Command Buffer
After the execution is completed, the system can return the resource that is being used. Otherwise, it is very likely that the GPU will be modified from the time when the lock is returned to the unlock after the modification.
All are in idle state and there is no reasonable use of GPU and CPU concurrency. dx8.0 introduces a new lock mark d3dlock_discard,
It indicates that the resource will not be read, and only the resource will be fully written. In this way, the driver and runtime come together over the sea and are immediately returned to the application.
In addition, the block VM address pointer is discarded after the unlock, so that the CPU lock does not need to wait for the GPU to use.
After the resources are completed, you can continue to operate the graphic resources (vertex buffer and index buffer). This technology is called "Renaming ).