Device loss in d3d

The weekend is idle. Translate a DirectX SDK help document about device loss and troubleshooting methods. PATH is DirectX Graphics-Direct3d 9-programming guide-getting Started-Direct3D devices-lost devices, after the translation was found, the original translation is not so easy, always feel that some places do not reach the meaning of words, the level of English must be improved!

Device loss

A direct3d device is either in the operational or lost state, and in the operational status is normal. The device runs and renders as expected. When some events occur, the device enters the lost state. For example, if the keyboard focus is lost in full screen mode, rendering will fail. One feature of device loss is that all rendering operations will be silent failure, which means that the rendering function can return a correct result even if the rendering operation fails. In this case, the function present returns d3derr_devicelost.

According to the design, there is no detailed list to specify which situations the device will be lost. Some typical scenarios include losing focus. For example, when you press Alt + TAB or a system dialog box is initialized, the device will also be lost due to power management events, such as screen saver? Or otherProgramFull Screen request. In addition, the failure of the function reset may also lead to device loss.

All functions inherited from iunknown can run normally after the device is lost. when the device is lost, these functions have the following three options:

1. d3derr_devicelost is returned.-This means the device has been lost.

2 silently fail: returns s_ OK or other returned values.-If a function is silently fails, the application cannot distinguish whether the result is successful or silently failure.

3. Return a returned value.

Difference between Direct3D9 and direct3d 9ex

A direct3d device may return d3derr_devicelost when calling the present function, which means that all subsequent function calls will fail until the device is reset.

A direct3d 9ex device will never return d3derr_devicelost, but will return other status information. On Vista, there are only two possible causes for device loss, first, hardware is reset (due to hardware hanging), and second, the device driver is stopped. When hardware hanging occurs, you can call idirect3ddevice9ex: resetex to reset the device. If hardware hangs is used, the texture memory will be lost. When the device driver stops, the idirect9ex object must be re-created to resume rendering.

When the rendering area is blocked by other windows, or when the full screen program is minimized, idirect3ddevice9ex: presentex returns s_d3dpresentationoccluded. When the full screen program receives the wm_activateapp message, the rendering will be resumed.

In earlier versions of DirectX, when the application mode changes (between windows and full screen), the only way to restore rendering is to reset the device and re-create all the memory resources and swap chain, on Vista, this is not necessary. When the mode changes, calling the reset function will not lead to loss of texture, surface and other resources, or re-build these resources.

Response device loss

After a lost device is reset, it must re-create resources (including memory resources). If the device is lost, the application will ask the device to determine whether it can be restored to the operational status. If not, the application waits until the device is restored.

If the device can be recovered, the application will destroy all the memory resources and swap chain, and then call the idirect3ddevice9: reset function. This function is the only function that can work after the device is lost, it is also the only function that converts a device from the lost state to the operable state. The reset function fails unless the application releases all resources whose memory type is d3dpool_default, including resources created using the idirect3ddevice9: createrendertarget and idirect3ddevice9: createdepthstencilsurface functions.

In most cases, some frequently called d3d functions do not return any information indicating whether the device is lost. Applications can continue to call these functions, such as idirect3ddevice9: drawprimitive, but will not receive notifications of device loss. However, in d3d, these function calls are ignored before the device is restored to the operational status.

When the application encounters a device loss, you can query the return value of the idirect3ddevice9: testcooperativelevel function to determine what to do.

Lock Operation

Inside, direct3d will do enough work to ensure that the locking operation can be successful when the device is lost. However, it cannot ensure the correctness of the memory resources when they are locked. However, it ensures that no error code is returned, so that the application does not have to worry about the loss of the device when performing the lock operation.

Resources

Resources consume memory. When the device is lost, the device will lose connection with the video memory in the video card, and cannot ensure that the video memory is allocated successfully. Therefore, all resource allocation functions will return d3d_ OK, but in fact all resources are allocated with dummy system memory, because all resources must be released before the device is reset, there is no issue of over-allocating video memory. these dummy surfaces can be locked and copied, and seem to work normally until the application calls the present function and finds that the device has been lost.

All the memory of the video card must be released before the device is reset, which means that the application must release the swap chain created using the idirect3ddevice9: createadditionalswapchain and all the resources created using the d3dpool_default. Instead of releasing d3dpool_managed and d3dpool_systemmem resources. Other status data is automatically destroyed.

We encourage you to develop applications to respond to device loss.CodeCan be used to initialize the device when the device starts.

Get Data

For hardware-implemented single-channel rendering, direct3d allows applications to use idirect3ddevice9: validatedevice to verify the texture and rendering status. This function is usually called during program initialization. It returns d3derr_devicelost when the device is lost.

Direct3d also allows applications to copy generated or previously written images from the video memory to the system memory. Because images may be lost during transmission, direct3d fails to allow these operations when the device is lost.

For Asynchronous queries, when the flush flag is specified, the idirect3dquery9: getdata function returns d3derr_devicelost to inform the program idirect3dquery9: getdata that s_ OK will never be returned.

Copy operation, idirect3ddevice9: getfrontbufferdata will return failure when the device is lost, because there is no primary surface (primary surface) when the device is lost, idirect3ddevice9: createadditionalswapchain will also return failure when the device is lost, the back buffer cannot be created when the device is lost. In these cases, except for idirect3ddevice9: Present, idirect3ddevice9: testcooperativelevel, and idirect3ddevice9: reset, devices are only lost.

Programmable shader

In direct3d 9, vertex pasters and pixel pasters do not have to be re-created after device resetting. They will be remembered that in the previous DirectX, the lost devices need to re-build the pasters.