DX Transfer Rate

Although DX was born at the beginning to improve game development efficiency, the performance of the game is basically achieved by relying on the video card. From this perspective, dx is actually manipulating the video card, furthermore, the surface or image in the game is just a two-dimensional array data, and DX is processing this two-dimensional matrix. Just like cuda, we can also organize common data into such two-dimensional data and deliver it to DX for surface or image processing. With the powerful performance of modern graphics cards, we can process a large amount of data.

After using dx to process data on the video card end, you can use the CPU to encode the data from the video memory to the memory, and then get a game recording tool similar to fraps.

For the current hardware architecture, data goes through the PCI bus of the main board from the display memory to the memory (I wonder if the Intel I5 processor combines the nanqiao chip with the PCI bus to improve the data transmission speed ?), This process will certainly consume time. Query the data transmission rate of the current mainstream PCI bus on the Wiki (AGP 8x is 2.1 GB/s and PCI-e 16x is 4 Gb/s), and find that even 1080 p, the 60 fps hd video source (1920*1080*12/8*60 = 178 Mb/s) can basically meet the data transmission requirements. However, in the actual coding process, it is found that the time spent in this process is far greater than the expected value. Why?

Later trackingCodeIt is found that the consumption of performance is mainly based on the idirect3dsurface9: lockrect function. This function can copy the data stored in the video to a buffer in the memory. It is true that this process does take some time, but it should not be so long!

 

The problem occurs on DX's data allocation and management:

Http://members.gamedev.net/jhoxley/directx/DirectXForumFAQ.htm#D3D_13

In this articleArticleIn detail, the DX memory data allocation and management are parsed. For the Chinese translation version, refer to here.

Because it was previously thought that the main board bus restricted the transmission rate of the video memory data to the memory data, which led to the overall speed decline, but as explained in the above article:

In the end, the locking operation is slow. in most cases, the disaster is not caused by bandwidth (refers to the transfer of VRAM to system RAM), but by the delay caused by blocking.

We can see that the main cause of the dramatic reduction in data transmission rate is the blocking caused by the synchronization of the CPU and GPU clock sequence during the lock operation.

 

Is there a solution?

There are some ways to use DX screenshots on the Internet, one of which is to create an "off-screen (offline)" surface (allocating resources in the system memory ), copy the original video storage data (rendertarget or surface) to the offline surface, and then directly lock the offline surface, because the lock operation on this off-screen surface does not involve the CPU lock mechanism, that is, the data in this offline surface is always lockedable, after you lock it, the GPU does not need to wait for CPU synchronization, which saves a lot of time.

Important code:

Lpdirect3dsurface9 surf;
If (failed (hR = lpdevice-> createoffscreenplainsurface (mode. Width, mode. Height, d3dfmt_a8r8g8b8, d3dpool_systemmem, & surf, null) // note that the fourth parameter cannot be d3dpool_default
{
Return hr;
}

// Call idirect3ddevice9: getrendertargetdata to copy the data to surf.

...

surf-> lockrect (...);