아직 Deferred device context 사용 안해봤는데 이게 내가 이해하기로는 얘를 사용해서 드로우콜들 모아다가 ExecuteCommandList 호출해서 쌓여있는 드로우콜들 한번에 빡 그리는걸로 알고 있음
또 여러개의 Deferred device context를 이용해서 멀티스레드로 렌더 요청을 박아넣을 수도 있는...
이게 맞나?
여튼 첫번째로 궁금한것
대략 예시를 들어보자면
지연된 컨텍스트 1, 2가 있음
1번 컨텍스트에는 불투명 오브젝트 렌더콜들을 요청하고, 2번 컨텍스트에서는 깊이버퍼를 사용하지 않는 반투명 오브젝트 렌더콜들을 요청함
모든 렌더콜들이 컨텍스트에 저장된 후에
1번 2번 순서로 ExecuteCommandList 를 호출하지 않으면 반투명 오브젝트들이 불투명 오브젝트에 가려질까?
두번째로 궁금한것
모든 쉐이더에서 사용되는 cbuffer가 있는데 지연된 컨텍스트에 렌더콜을 던질때마다 cbuffer의 내용을 다르게 하여 렌더콜을 던져도 다 적용이 될까?
정확히는 매 드로우콜마다 쉐이더에 적용하는 리소스들이 다르니 이것들이 다 적용된 채로 컨텍스트에 저장될까?
마지막
어떤 지연된 컨텍스트 하나를 사용한다고 할때
1. a 라는 텍스쳐를 렌더 타겟으로 설정
2. 드로우콜 발사
3. b 라는 텍스쳐를 렌더 타겟으로 변경
4. a 텍스쳐를 쉐이더 리소스로 사용해서 새로운 드로우콜 발사
5. ExecuteCommandList
이런 상황일때 3번에서 요청한 드로우콜에 사용되는 a 텍스쳐는 2번에서 요청한 드로우콜에 의해서 작업된 텍스쳐일까?
질문이 너무 많고 설명도 븅신같아서 미안함
1. 굳이 지연 deferred context를 사용하지 않더라도, immediate context를 사용했을때 어떻게 되는지와 똑같음. 즉 컨텍스트 2, 1 순서대로 excutecommandlist 해주었을때 어떻게 되는지는, 컨텍스트 2, 1에서 하는 읽을 그대로 immediate context에서 실행했을때 어떻게 되는지 물어보는것과 같아 2. DX11 Deferred Context에서의 Map-Unmap 메서드 자체가 Map-Unmap을 하면 임시 리소스를 만든다음에 Immediate context 에서 excute 될 때 원래 리소스에 업데이트 되는 식으로 작동할 거임.
3. 이것도 굳이 지연된 컨텍스트가 아닌 직접 컨텍스트로도 동일함
다만 3번의 상황에서 a라는 텍스쳐를 렌더 타켓으로 파이프라인에 바인딩한 상태에서 그 텍스쳐를 동시에 셰이더 리소스 뷰로 바인딩하거나 그런건 안됨
너무 ㄳ... 걍 immediate context 쓰듯이 쓰면 되는듯 하네, 지금 함 건드려보고 있는데 전부다 immeditate context로 때려박아서 쉽진 않네 바꿔봐야겠음
간혹 글싸러 오겠음 렌갤흥해라
그리고 Deferred Context도 Single thread 에서만 쓰도록 주의해.. thread-safe 하지 않으니까..
음 그러면 Deferred context 하나만 만들어서 여기에 드로우콜 다 때려박아 쓰는게 좋을까?
아니 스레드 수 만큼 Deferred context 만들어서 스레드 당 하나의 Deferred context를 사용하게 하란 말이였는데
능지 죄송합니다...
아니야.. 내가 설명을 제대로 못해줘서 그렇지 뭐 ㅋㅋ..
ㄳㄳ! 덕분에 적용했어, 우선 그림자 그리기를 위한 깊이 쓰는 작업에 시험적으로 적용해봤음. 내가 사방팔방에 immediate context로 떡칠해놔서 좀 헤멧는데 되긴 되네
근데 찾아보니까 Map Unmap의 경우에는 니말대로 임시리소스에 기록되는데 이게 많이 기록되는 상황이 좀 걱정되긴 하네
굳! 우려하는 부분은 뭐.. staging buffer 만들었다가 올린다고 생각하면 괜찮은거 같긴한데.. 아마 드라이버 단에서 최적화가 많이 되있지 않을까 싶다