Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
 
Other projects
   Altirra

Archives

Blog Archive

Why 3D accelerated rendering stops if the machine is locked

If you have video filters in the chain which are using 3D acceleration, VirtualDub aborts rendering as soon as you lock the computer.

There are three reasons for this.

The first is the old bane of Direct3D 9 programming, the "lost device" state. When you lock the workstation, Windows switches desktops to the secure desktop that holds the login dialog. This deactivates the desktop that holds all of your applications, and a side effect is that it also deactivates all Direct3D 9 contexts. All D3D9-based applications are then blocked from doing any rendering as API calls return the error code D3DERR_DEVICELOST. That forces VirtualDub to pause rendering.

The second reason is a bit more annoying. When the "device lost" state is inflicted, it also causes all surfaces on the 3D device to be immediately dropped. This is a problem for VirtualDub because any video frames that are in progress or cached from accelerated filters exist only on the 3D device and are lost. They are kept only on the 3D device because it's really expensive to read them back into system memory. This means that as soon as the lost device state occurs, a number of frames in the video pipeline have been lost. Recovering from this situation means backing up the video pipeline and retrying the frames that were lost, which VirtualDub can't currently do. Therefore, the only course of action possible is to abort the render.

The third reason is the most subtle. Assuming that VirtualDub's renderer could be modified to support backing up and re-rendering the lost frames, that assumes that it knows which frames were lost. In the past, I've seen issues with Direct3D drivers and the runtime where the device lost state wasn't reported until a readback into system memory (GetRenderTargetData) had succeeded. The result is that a bad frame is read back and reported as successfully copied. In a retry-capable scenario, this would mean silent corruption of the video, which would be a very bad thing.

Some or all of these issues could theoretically be bypassed by using a Direct3D 9Ex device object, which is available under Windows Vista or later with a WDDM display driver. Direct3D 9Ex bypasses the lost device emulation that is normally done for D3D9 applications and theoretically would avoid problems with lost devices. I haven't implemented this or tested if it works reliably, however.

To sum it up, if you have enabled 3D filter acceleration in VirtualDub and have a render going... you should leave the machine alone until it's done.

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.