D3D Resource Management

Http://www.sineysoft.com/blog/post/D3D_rm.html

Summary

Managed textures, also known as "automatic texture Management", is introduced in DX6 for the first time. After a series of improvements and enhancements, the automatically managed resource types in DX9 are added to textures, vertex buffering, and vertex index buffering. All these resources use a unified public interface. By using the D3D Resource Manager, applications can easily handle device loss and slightly excessive memory usage.

Sometimes developers may encounter some difficulties in using managed resources, which is attributed to the abstract features of the system. In most cases, using managed objects is a good option, but sometimes it uses unmanaged resources for performance considerations. This article will discuss how to handle the differences between managed and non-managed resources in general.

 

Content

L Display memory

L managed resources

L drive resource control

L default Resource

L system memory resources

L general suggestions

 

Display memory

To enable the resource to use the video memory, the GPU needs to access and locate the resource through the memory. GPU access (Local video memory) memory is very efficient, and some resources (such as RenderTarget, depth, template buffer) must be located locally (Local video memory. Due to the emergence of AGP, GPU can directly access some system memory, and the memory area of this subsystem is the so-called non-local video memory. Of course, this part of memory (memory) it cannot be used. Non-local video memory can only be accessed by the GPU, which is less efficient than accessing local video memory. It should be clear that all devices in the AGP will become invalid when they are lost, and they must be restored.

 

Some integrated graphics cards use a Unified Memory Architecture, so that the main Memory can be addressable by any device in the system. D3D supports UMA without modifying any code. In this way, we configure the system memory as a local memory, and the hardware ensures that the resource is located just like the traditional structure.

 

Managed resources

Most resources should be created using the POOL_MANAGED method, that is, managed resources. All managed resources will be created in the system memory and copied to the memory as needed. When a device is lost, the system memory is automatically copied to the video memory. Since not all managed resources need to be sent to the video memory at a time, you can submit more than the minimum memory capacity required for rendering each frame, however, this will cause a large amount of video content to be written to the disk due to paging operations, which is very time-consuming. This is also why it is so time-consuming to restore the device because a large amount of disk data needs to be copied to the memory.

DX will add a timestamp to each resource for the last use, so that when the memory allocation fails, it will release the least recently used resources (LRU algorithm ). UseSetPriorityFunctions can mark the importance of resources. Important resources are better than timestamps. Therefore, high priority should be set for commonly used resources, you don't have to worry about the resource being released because the timestamp expires. In DX9, the memory management information provided by the driver is very limited, and a large amount of resources may have to be cleared during runtime to allocate enough memory. Setting a proper priority is very useful, so that D3D does not clear the resources that are immediately needed. Applications can be forcibly called.EvictManagedResourcesClear all managed resources, but if the next frame needs to reload these resources, this will be very time-consuming, but this function needs to be significantly changed in those scenarios (such as entering the next level) in this case, it is very useful.

If a lot of resources are required for rendering in the "current frame", it will be troublesome. It is not ideal to schedule resources using the above LRU method, in this case, the MRU resource scheduling method is used, that is, the active resources are cleared first. Note: The concept of "current frame" here refers to the frame to be rendered between BeginScene and EndScene.

If you want more information about managed resourcesIDirect3DQuery9API query, but this API can only be used in debug runtimes. In a released version, the application cannot make any assumptions by modifying the interface information.

Understanding how resource management works can help us debug and adjust programs. What's important is that the application should not rely too much on the resource management method of the current Runtime Library (or driver, driver updates may cause changes in behavior. In the future, D3D will have a set of time-tested resource management methods.

Resources managed by drivers

The D3D driver can freely implement the "manage textures by driver" feature. Through the D3DCAPS2_CANMANAGERESOURCE segment, You can query whether the hardware driver supports this feature. In this way, the driver will replace the D3D Runtime Library to manage resources. A few of the hardware levels support this feature, but most of the hardware is different. You can consult your product provider to obtain this information. Generally, you can use the D3DCREATE_DISABLE_DRIVER_MANAGEMENT method to create a device. In this way, the D3D Runtime library is used to manage resources.

Default Resource Management (unmanaged resources)

Although managed resources are simple, easy to use, and efficient, sometimes we want to write something directly into the video memory. In this case, we need to use POOL_DEFAULT to create resources. Using this method will increase the complexity of the program. The code needs to cope with the loss of all devices, and you need to carefully consider when to copy data to the video memory. If the specified USAGE_WRITEONLY tag is incorrect or the rendering Target is locked, the performance is seriously affected.

Locking a POOL_DEFAULT type of resources may cause the GPU to stop running, which is different from a POOL_MANAGED type of resources unless indicated by some features. Depending on the current location of the resource, the pointer obtained after the lock is also different. It may be a temporary system memory or direct to the AGP memory. If it is a temporary system memory, the Unlock will send this data to the video memory, because if the video card resources are not only write-only ), data will have to be sent to a temporary memory when it is locked. If it is directed to the AGP memory area, temporary copying can be avoided, but the cache behavior will reduce performance.

To avoid write-combing performance degradation due to a read/write cycle ), it is recommended that you use the system memory as an alternative if your program needs random access to the AGP memory and you do not want to use managed resources, in this way, when you generate data, you can lock the data and copy it. This will not cause too much performance loss. The performance loss here is generally caused by the buffer "Write search" operation. (Note: here, the translator of the word cache write-combing does not know the corresponding Chinese meaning, and can only translate it literally)

For some types of resources, the use of the LOCK_NOOVERWRITE mark will make adding data more efficient, but multiple locks and Unlock the same resource still need to be avoided as far as possible, appropriate use of a variety of lock tags is very important for efficiency optimization, just as it is best to use cache-friendly data access methods to fill the locked memory area.

Mixed Use of managed resources and default Resources

The mixed allocation of managed and non-managed resources may cause memory fragments and disrupt the memory areas used by managed resources. It is recommended that you use unmanaged resources before using managed resources, or use the EvictManagedResources function to clear managed resources before using unmanaged resources. Remember, all unmanaged resources will be resident in the memory, so that other memory needs will not be used.

Note: Unlike the previous DX version, when the video memory is insufficient, if the allocation of unmanaged resources fails, DX9 will automatically clear the managed resources, which may lead to potential memory fragments, even place resources in an inappropriate place (such as a static image area with non-local memory ). Therefore, it is best to allocate all the unmanaged resources before using managed resources.

Dynamic default Resource

If the data needs to be updated frequently, it is best to use unmanaged resources and use the USAGE_DYNAMIC tag, so that the driver will decide the most suitable place to place the data that needs to be updated frequently. This usually means that it is stored in a non-local video memory, so that the access speed may be relatively slow for the GPU. For the UMA architecture, the driver will place the data in special places with high CPU access efficiency.

This usage (Dynamic default resource type) is generally used for Buffer filling of soft skins and CPU-based particle systems vertex/vertex indexes. The LOCK_DISCARD mark can ensure that resources are still in use, the locking operation does not cause the system to stop and pause. In this case, using managed resources will update the system memory and then copy it to the video memory. For non-local memory of the system, redundant copying is not required.

Standard pasters cannot be locked. They can only be updated through the UpdateSurface and UpdateTexture functions. Some systems support dynamic textures, which can be locked by using the LOCK_DISCARD mark, but this requires checking the hardware capabilities of D3DCAPS2_DYNAMICTEXTURES. For highly dynamic textures (such as video and program-generated textures), it is best to use unmanaged resources and system memory resources, and update Textures through the UpdateTexture function. For high-frequency particle updates, the UpdateTexture function may be the best choice.

With limited bus-memory bandwidth, static texture resources should be stored in POOL_MANAGED mode, which ensures the best use of local memory and better efficiency. For "semi-static" resources, using dynamic resources sometimes improves efficiency.

System memory resources

Resources can be created in POOL_SYSTEMMEM mode. However, they cannot be used for graphic pipelines. They can only update resources of the POOL_DEFAULT type for source data, which is done through the UpdateSurface and UpdateTexture functions. Their locking operation is also very simple, although they may also cause the system to stop running because of the aforementioned reasons.

Although resources are created in the system memory, the formats and capabilities (such as the maximum size) supported by POOL_SYSTEMMEM are limited by hardware and drivers. POOL_SCRATCH, which creates resources in the system memory, does not have this restriction. It supports all formats and capabilities, but cannot be accessed directly by devices. SCRATCH resources are generally used for content creation tools.

 

General suggestions

Understanding the technical implementation details of resource management can greatly help you achieve your program's performance goals, it is very complicated to plan how your resources are handed over to D3D and design a good structure so that necessary data can be loaded in time. Therefore, we provide some good practical experience as a general principle:

L preprocessing your resources. Do not waste time-consuming resources, resource conversion, and resource optimization. Although this is convenient for development, it is intolerable for users. Preprocessing these resources can accelerate loading and faster use. Your users will also find that your program runs faster.

L avoid creating too many resources on each frame. For too many resources, you can divide them into multiple frames or do not rush to release those resources that are not currently used.

L ensure that all resource channels are disconnected at the end of a frame. (For example, vertex stream, texture stages, and vertex index ).

L for textures, we recommend that you use the compression texture (DXTn) format. We recommend that you use mip-map or splice a small texture into a large texture.

L we recommend that you use vertex indexes, which reduces the amount of data transferred.

L exercise caution when optimizing resource management for the transition. If your program is overly dependent on certain features of the driver, hardware, and operating system, modifications to these programs and hardware will lead to potential performance problems.