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
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ 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

Comments posted:


I was wondering was it possible to have the entire program to run and compress running off of the graphics like badaboom program. When I render or compress it takes forever. Awesome program by the way

mykejackal - 23 08 09 - 20:41


To cope with the 3rd problem, how about calling GetRenderTargetData like every N frames and then, if you notice that some frames have been lost, backtrack at least N+1 frames and continue from there. If you make N large enough, the performance hit of reading back the frames should not be noticeable, and you can still continue with only N frames lost...
-Darkstar

Darkstar - 24 08 09 - 00:45


What was the reason back then for the device-lost event? In principle it could be handled by DirectX transparently. Maybe it was performance.

tobi - 24 08 09 - 02:17


Unless by "leaving the machine alone" you allow the screensaver to kick in, which also might lock the desktop. Heh. (And even if password protection isn't enabled, screensavers run in a separate desktop too, right?)

James - 24 08 09 - 05:31


This is a showstopper for me. Applications can't prevent the system from begin locked, especially not background jobs that make take hours to complete.

OpenGL doesn't have this problem.

Glenn Maynard - 24 08 09 - 05:49


Now I know why my GeoForms screensaver crashes when I want to continue working - because the welcome screen comes up.

Mirage - 24 08 09 - 09:03


that's bad :(

Hunter - 24 08 09 - 18:47


If you're going for 9EX, why not try for 10? Knowing you, you probably have a good reason, but I want to read it.

goodone91 - 29 08 09 - 06:08


"If you're going for 9EX, why not try for 10?"
Because 9EX is available on all DX9 hardware with a WDDM driver, which is most DX9 hardware (a famous exception is Intel's old GMA 900, part of the 915G chipset), but 10 requires new hardware.

Yuhong Bao - 01 09 09 - 06:40


That's one factor, but it's also much easier to adapt a DX9 engine to DX9Ex. You don't have to do too much other than swap the interface pointers and switch managed pool allocations to default pool.

Phaeron - 01 09 09 - 15:05

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.