Hypothesis !
Author
A Direct3D device does not completely release its memory unless it changes the format or dimentions of the backbuffer.
That seems to be the only thing that completely resets a device''s memory.
Has anyone found otherwise?
I assume you''re talking about lost devices...
1. Set the desktop to 16bit, 1024x768.
2. Run your app fullscreen in 16bit, 640x480.
3. Alt Tab back to the desktop.
4. Change the desktop screen mode to 32bit, 1280x1024
5. Alt Tab back to the app.
That (and similar scenarios) are usually enough to cause you to need a complete lost device restore.
Never assume that "just because it happens to be ok on my machine, I''ll never have to worry about handling lost devices on anyone elses machine". There are lots of interesting graphics chips and things on the way which could cause lost devices during an Alt Tab.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
1. Set the desktop to 16bit, 1024x768.
2. Run your app fullscreen in 16bit, 640x480.
3. Alt Tab back to the desktop.
4. Change the desktop screen mode to 32bit, 1280x1024
5. Alt Tab back to the app.
That (and similar scenarios) are usually enough to cause you to need a complete lost device restore.
Never assume that "just because it happens to be ok on my machine, I''ll never have to worry about handling lost devices on anyone elses machine". There are lots of interesting graphics chips and things on the way which could cause lost devices during an Alt Tab.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
That''s exactly what I''m saying !!!
If you:
1. Set the desktop to 16bit, 1024x768 (or 32 bit, 1024x768)
2. Run your app fullscreen in 16bit, 1024x768 (32 bit, 1024x768)
3. Alt Tab back to the desktop.
4. Alt Tab back to the app.
Repeat steps 3 & 4 several times.
You will eventually get a D3D_OUTOFVIDEOMEMORY error
If you:
1. Set the desktop to 16bit, 1024x768 (or 32 bit, 1024x768)
2. Run your app fullscreen in 16bit, 1024x768 (32 bit, 1024x768)
3. Alt Tab back to the desktop.
4. Alt Tab back to the app.
Repeat steps 3 & 4 several times.
You will eventually get a D3D_OUTOFVIDEOMEMORY error
Oh - I was talking about lost devices: D3DERR_DEVICELOST
If you''re slowly running out of memory it hints at:
1) Your restoration code could be leaking memory - try using the debug D3D runtime with the levels at maximum. Watch the output to see if you get any leaks between the reset.
2) The device driver for the card/chip you''re testing on could be broken. Try this on another chip and with different drivers.
3) You may be causing fragmentation be not releasing resources in exact reverse order and the driver may not be not be so good at defragmentation. Try ensuring you release in exact reverse order. An alternative that some people do when they get a lost device is release *everything* right back to the D3D object pointer and then recreate from scratch - this can help if it is a driver not handling fragmentation.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
If you''re slowly running out of memory it hints at:
1) Your restoration code could be leaking memory - try using the debug D3D runtime with the levels at maximum. Watch the output to see if you get any leaks between the reset.
2) The device driver for the card/chip you''re testing on could be broken. Try this on another chip and with different drivers.
3) You may be causing fragmentation be not releasing resources in exact reverse order and the driver may not be not be so good at defragmentation. Try ensuring you release in exact reverse order. An alternative that some people do when they get a lost device is release *everything* right back to the D3D object pointer and then recreate from scratch - this can help if it is a driver not handling fragmentation.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
1. How would the restoration code be leaking memory, if the only objects loaded are DX8, D3D, D3DDevice ?
2. So far, I''ve tested the code on 3 different systems, each with a different graphics card - same results.
3. That way, every resource, including those in the POOL_MANAGED have to be recreated.
As a matter of fact / interest:
Once the device has lost memory, a new device using the same color depth & dimentions CANNOT be created. However, as soon as they are changed, the device can be created, and all memory is freed up.
Strange phenomenon ??
2. So far, I''ve tested the code on 3 different systems, each with a different graphics card - same results.
3. That way, every resource, including those in the POOL_MANAGED have to be recreated.
As a matter of fact / interest:
Once the device has lost memory, a new device using the same color depth & dimentions CANNOT be created. However, as soon as they are changed, the device can be created, and all memory is freed up.
Strange phenomenon ??
1. RefCounts: any Device->GetD3D calls, any SetTexture calls etc all potentially refcount. Check the debug output with the debug runtime as suggested. No warnings/errors about memory mean no object leaks. But you can''t eliminate that until you''ve checked.
2. So it looks like it''s either your app code or a bug in D3D. We''ve tested Alt-Tab under some extreme situations in our engine and found no such problems. Though everyone does stuff differently, you may be using stuff differently.
The next thing I''d suggest doing is running one of the DirectX SDK samples in fullscreen (Alt-Enter) and repeat the tests on the same machines. If the samples do it too, tell Microsoft (directx@microsoft.com & dxfbug@microsoft.com) and include a DXDIAG dump.
3. Yes. The same would be true if you wanted to change adapter and even in windowed mode when the desktop mode changes (on some cards). Such is life.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
2. So it looks like it''s either your app code or a bug in D3D. We''ve tested Alt-Tab under some extreme situations in our engine and found no such problems. Though everyone does stuff differently, you may be using stuff differently.
The next thing I''d suggest doing is running one of the DirectX SDK samples in fullscreen (Alt-Enter) and repeat the tests on the same machines. If the samples do it too, tell Microsoft (directx@microsoft.com & dxfbug@microsoft.com) and include a DXDIAG dump.
3. Yes. The same would be true if you wanted to change adapter and even in windowed mode when the desktop mode changes (on some cards). Such is life.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
I have to stress the importance of releasing any texture and stream usage as well. Most programs do not do this, and it will cause leaks over time. I''m not sure if I''m picking the proper place to do so my projects, but I always release texture and vertex streams after all calls to Present:
pDevice->Present(NULL, NULL, NULL, NULL);
// Clear texture and stream pointers
pDevice->SetStreamSource(0, NULL, 0);
pDevice->SetTexture(0, NULL);
Jim Adams
home.att.net/~rpgbook
Author, Programming Role-Playing Games with DirectX
and Focus On: Advanced Animation with DirectX
pDevice->Present(NULL, NULL, NULL, NULL);
// Clear texture and stream pointers
pDevice->SetStreamSource(0, NULL, 0);
pDevice->SetTexture(0, NULL);
Jim Adams
home.att.net/~rpgbook
Author, Programming Role-Playing Games with DirectX
and Focus On: Advanced Animation with DirectX
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement