친구와의 견해차이는 참으면서도 낯선 사람과의 견해차이는 異端이요 陰謀로 몰아붙이는 것이 인간.―B.애트킨슨
* 원문 : DirectX->DirectX 8.1 (C++)->DirectX Graphics->Programming Guide->Using Direct3D->About Device->Lost Devices
- 일단은 급한대로 수업때 필요한 내용만 번역했습니다.
개요 #
D3D 디바이스는 두가지 상태 - 작동 상태(operational state)와 비작동 상태(lost state) - 를 가지고 있다. 작동 상태는 말그대로 디바이스의 보통 상태를 말한다. 이 상태에서는 모든 기능을 잘 실행하고 예측한데로 모든 것을 화면에 잘 출력한다. 풀스크린 상태에서 키보드 포커스를 잃는 것과 같은 특정 이벤트가 발생하면, 디바이스는 비작동 상태에 들어가며 이것은 랜더링 작업을 할 수 없게 한다. 비작동 상태는 모든 랜더링 명령들을 경고없이 조용하게 실패하게 함으로써 프로그래머에게 경고하며, 심지어는 랜더링이 안되는 데도 반환값은 오류가 없다고 나올 수 있다. 이 상태에서는 IDirect3DDevice8::Present()함수에 의해 D3DERR_DEVICELOST 에러가 반환됨으로써 확인할 수 있다.
SDK를 디자인하는 측면에서 보더라도, 디바이스가 비작동상태가 될 수 있는 모든 경우를 정의할 수는 없다. ALT+TAB 키를 눌렀거나 또는 시스템 대화상자가 초기화 되었을 경우, 포커스를 잃은 경우들은 몇몇 정형적인 예제라고 할 수 있다. 디바이스는 또한 전원 관리 이벤트의 원인에 의해서도 비작동모드로 들어갈 수 있고, 또는 풀스크린 모드를 사용하는 또다른 어플리케이션이 실행되었을 경우도 들 수 있다. 덧붙이자면, IDirect3DDevice8::Reset()함수가 실패할 경우에도 무조껀 디바이스는 비작동상태로 들어가버린다.
주의 : 디바이스가 비작동상태일때 실행되는 것을 보증하는 메소드들은 IDirect3DDevice8::TestCooperativeLevel(), IDirect3DDevice8::Reset(), IUnknown::Release() 뿐이다. 이 상태에서 다른 함수들을 호출하는 것은 모두 오작동을 하게 된다.
비작동상태의 디바이스 처리하기 #
만약 디바이스가 비작동상태라면, 어플리케이션은 디바이스에게 작동상태로 복구할 수 있는지 여부를 물어볼 수 있다. 만약 아니라면 어플리케이션은 디바이스가 복구될 수 있을때까지 기다려야만 한다.
디바이스가 복구될 수 있다면, 어플리케이션은 디바이스가 모든 비디오 메모리 자원과 백버퍼등의 모든 페이지 플리핑관련 자원들을 헤제함으로써 디바이스를 대기시킬수 있다. 그런다음, 어플리케이션은 IDirect3DDevice8::Reset()함수를 실행한다. 이 함수는 디바이스가 비작동상태일때 사용할 수있는 함수이며 디바이스를 작동상태로 돌려놓는 역할을 한다. D3DPOOL_DEFAULT 옵션하에서 할당된 모든 자원들 - IDirect3DDevice8::CreateRenderTarget, IDirect3DDevice8::CreateDepthStencilSurface함수로 생성된 것들도 포함한다 - 을 해제할 때까지 이 함수는 계속 실패하게 된다.
대부분의 경우, D3D에서 빈번히 호출되는 함수들은 디바이스가 비작동상태여부에 대해서는 아무것도 반환하지 않는다. IDirect3DDevice8::DrawPrimitive()함수같은 것들이 대표적인 예인데, 비작동모드라고 경고해주는 에러없이 어플리케이션은 정상적으로 수행되는 것처럼 보일 것이다. 내부적으로는, 이 명령들은 디바이스가 작동모드로 복구될때까지 계속 실행을 취소당한다.
어플리케이션은 IDirect3DDevice8::TestCooperativeLevel()함수의 반환값으로 비작동모드에 진입했는지 여부를 진단할 수 있다. 만약 D3D_OK면 디바이스는 작동모드이며, 비작동모드지만 현재는 복구할 수 없는 상황이면 D3DERR_DEVICELOST를 반환한다. 이것의 예는 풀스크린 모드일때 ALT + Tab을 눌러서 포커스를 잃은 경우를 들 수 있다. 이때 어플리케이션은 디바이스를 리셋할 수 있을때까지 기다려야한다. D3DERR_DEVICENOTRESET을 반환할때가 바로 리셋이 가능한 때이다. IDirect3DDevice8::Present()로부터의 반환값은 아직도 D3DERR_DEVICELOST라는 것에 주의하자. 모든 경우에서 심지어 디바이스가 비작동상태가 아니더라도 Reset()을 호출하기전에 비디오 메모리 자원들을 해제하는 것은 반드시 거쳐야만하는 일이다.
요약하면, 다음과 같은 과정을 거쳐서 다시 D3D 디바이스를 복구한다.
잠금(Lock) 명령 #
Internally, Direct3D does enough work to ensure that a lock operation will succeed after a device is lost. However, it is not guaranteed that the video-memory resource's data will be accurate during the lock operation. It is guaranteed that no error code will be returned. This allows applications to be written without concern for device loss during a lock operation.
Resources #
Resources can consume video memory. Because a lost device is disconnected from the video memory owned by the adapter, it is not possible to guarantee allocation of video memory when the device is lost. As a result, all resource creation methods are implemented to succeed by returning D3D_OK, but do in fact allocate only dummy system memory. Because any video-memory resource must be destroyed before the device is resized, there is no issue of over-allocating video memory. These dummy surfaces allow lock and copy operations to appear to function normally until the application calls IDirect3DDevice8::Present and discovers that the device has been lost.
All video memory must be released before a device can be reset from a lost state to an operational state. This means that the application should release any swap chains created with IDirect3DDevice8::CreateAdditionalSwapChain and any resources placed in the D3DPOOL_DEFAULT memory class. The application need not release resources in the D3DPOOL_MANAGED or D3DPOOL_SYSTEMMEM memory classes. Other state data is automatically destroyed by the transition to an operational state.
You are encouraged to develop applications with a single code path to respond to device loss. This code path is likely to be similar, if not identical, to the code path taken to initialize the device at startup.
Retrieved Data #
Direct3D allows applications to validate texture and render states against single pass rendering by the hardware using IDirect3DDevice8::ValidateDevice. This method, which is typically invoked during initialization of the application, will return D3DERR_DEVICELOST if the device has been lost.
Direct3D also allows applications to copy generated or previously written images from video-memory resources to nonvolatile system-memory resources. Because the source images of such transfers might be lost at any time, Direct3D allows such copy operations to fail when the device is lost.
The copy operation IDirect3DDevice8::CopyRects can return D3DERR_DEVICELOST when the source object is in volatile memory (D3DPOOL_DEFAULT) and the destination object is in nonvolatile memory (D3DPOOL_SYSTEMMEM or D3DPOOL_MANAGED). Another copy operation, IDirect3DDevice8::GetFrontBuffer, can fail due to retrieving data from the primary surface. Note that these cases are the only instance of D3DERR_DEVICELOST outside of the IDirect3DDevice8::Present, IDirect3DDevice8::TestCooperativeLevel, and IDirect3DDevice8::Reset methods.








![[http]](/wiki/imgs/http.png)
