D3D10 resource usage.
출처 : http://blog.naver.com/lifeisforu/80073203984
D3D10 에서는 더 이상 memory pool 에 대한 고민을 할 필요가 없어졌습니다.
출처 : DXSDK 도움말.
이제 더 이상 resource 를 video memory 에 생성할지 system memory 에 생성할지 고민할 필요가 없어졌다. 그리고 runtime 이 memory 를 관리할지 말지도 고민할 필요가 없다. 새로운 WDDM 의 구조에 감사하기 바란다. Application 은 이제 "application 이 resource data 를 무슨 의도로 생성했는지"에 대한 usage flag 를 지정하기만 하면 된다. 새로운 driver model 은 resource 에 의해 사용되는 memory 를 가상화한다; 그래서 operating system/driver/memory manager 가 주어진 usage 에 가장 적합한 memory 를 알아서 생성하게 된다. |
Usage 를 지정만 하면 된다고 하니 어떤 것이 있는지 구경을 해 보도록 하겠습니다.
출처 : DXSDK 도움말.
typedef enum D3D10_USAGE |
지난 번까지 보면서 궁금했던 staging resource 라는 녀석이 드디어 등장하는군요. 자 어떤 의미를 가지고있는지 간단히 살펴 보도록 하겠습니다.
D3D10_USAGE_DEFAULT
D3D10_USAGE_IMMUTABLE
D3D10_USGAE_DYNAMIC
D3D10_USAGE_STAGING
|
D3D9 시절만 해도 resource option 가지고 엄청 고생을 했습니다. 그리고 pool 이 뭐냐에 따라서 option 도 달라졌죠. 생각만 해도 끔찍합니다. 뭐니뭐니 해도 D3D10 에서 제일 잘 한건 resource 관리를 일원화한 것이라 생각합니다. 물론 그렇기 때문에 이런 저런 일을 할 수 있는 가능성이 높아지기도 했겠지만 말이죠.
어쨌든 본제로 돌아가서... resoruce 에 접근하기 위해서는 다음과 같은 API 들이 사용됩니다. CPU 접근을 위해서는 ID3D10Buffer::Map(), ID3D10Texture1D::Map(), ID3D10Texture2D::Map(), ID3D10Texture3D::Map() 등이 사용되고, GPU 접근을 위해서는 ID3D10Device::CopySubresourceRegion(), ID3D10Device::CopyResource(), ID3D10Device()::UpdateSubResource() 등이 사용됩니다.
아래 표는 "resource 가 어떤 processor 에 의해 접근 가능한지"를 보여줍니다.
그리고 아래 표는 "어떤 resource 가 어떤 stage 에 binding 될 수 있는지"를 보여줍니다.
이런 저런 제약이 좀 있는 것 같긴 한데 나중에 사용하다 보면 더 잘 알 수 있지 않을까 싶습니다. 뭐 세상에 쉬운 일이 어디 있겠습니까...
Resource 와 관련해서 성능상 고려해야 할 점이 SDK 도움말에 나와 있습니다. 이를 살펴 보면서 글 마무리 짓도록 하겠습니다.
출처 : DXSDK 도움말.
Performance Considerations
병렬적인 구조로 두 종류의 main processor 를 돌리는 machine 으로서 PC 를 생각하는 것은 매우 좋은 선택이다; 하나 이상의 CPU 들과 하나 이상의 GPU 들이 바로 그것이다. 모든 병렬 구조에서 최선의 성능은 각각의 processor 들이 idle 상태에 빠지지 않고 충분한 작업을 수행할 수 있도록 scheduling 할 때, 그리고 하나의 processor 가 다른 processor 의 작업이 끝날때까지 대기하지 않을때 성취할 수 있다.
최악의 scenario 는 GPU/CPU 병렬성이 서로에 대한 wait 때문에 깨지는 상황이다. Direct3D 10 은 ID3D10Device::CopyResource() 와 ID3D10Device()::CopySubresourceRegion() method 를 비동기적으로 만듦으로써 이 비용을 제거하려고 시도했다; 복사는 method 가 return 할 때 일어나는 것이 아니다. 이것의 이점은 application 이 실제로 data 를 복사하는데 필요한 성능 비용을 지불할 필요가 없다는 데 있다. Map() method 가 실제 data 가 복사된 이후에 호출된다면, 어떠한 성능 소실도 일어나지 않는다. 다시 말해 Map() method 가 복사가 완료되기 이전에 호출된다면 pipeline stall 이 일어날 것이다. |
이제 시대가 시대인만큼 병렬 programming 에 대해서 고민을 해야 할 필요가 있습니다. 특히나 최근같이 GPU 자원을 많이 사용하는 경우에는 renderer 자체를 thread 로 띄우려고 하는 시도들이 많이 보입니다.
자유도가 높아질 수록 programmer 가 해야 될 일들이 많아져서 머리가 아퍼지긴 하지만 그만큼 programmer 의 가치도 노력한 만큼 높아질 수 있겠죠.
Resource 에 대한 더 자세한 내용들이 DXSDK 도움말에 많이 나와 있습니다. 꼭 읽어보시길 바랍니다. 저의 귀차니즘때문에 모든 내용을 여기에서 설명하기는 힘드네요.
좋은 주말 보내시기 바랍니다.
[출처] D3D10 resource usage.|작성자 라이푸
'Study > Directx 9' 카테고리의 다른 글
DirectX SDK 9.0c 의 Pure Device 에 대한 보고 (0) | 2010.08.24 |
---|---|
비디오 메모리, 시스템 메모리 체크하는법 (0) | 2010.05.31 |
큐브맵의 밉맵생성 (0) | 2009.12.08 |
cbuffer (0) | 2009.11.15 |
D3DXMatrixLookAtLH (0) | 2009.10.26 |