일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 그리디 알고리즘
- 영속성
- 그리디알고리즘
- 백준
- 프로그래머스
- 파일시스템 구현
- 스케줄링
- 알고리즘
- 락
- 다이나믹프로그래밍
- 렌더링 파이프라인
- codility
- 컨디션 변수
- I/O장치
- 멀티프로세서
- 멀티쓰레드
- 운영체제
- 병행성
- 병행성 관련 오류
- 쓰레드
- DirectX 12
- 타입 객체
- OS
- DirectX12
- 자료구조
- directx
- 동적계획법
- 디자인패턴
- Direct12
- 다이나믹 프로그래밍
- Today
- Total
목록DirectX (24)
기록공간

서술자 힙 생성 스왑 체인까지 만들었다면, 응용 프로그램에 필요한 서술자/뷰들을 담을 서술자 힙을 만들어야한다. 서술자 힙은 ID3D12DescriptorHeap 인터페이스로 대표된다. 힙을 생성하는 메서드는 ID3D12Device::CreateDescriptorHeap이다. SwapChainBufferCount에 설정된 개수만큼의 렌더 대상 뷰(RTV)들과 하나의 깊이 스텐실 뷰(DSV)가 필요하다. RTV는 스왑 체인에서 렌더링의 대상이 되는 버퍼 자원을 서술하고, DSV는 깊이 판정을 위한 버퍼 자원을 서술한다. 서술자 힙은 서술자 종류마다 따로 만들어야 한다. 따라서, SwapChainBufferCount 개의 RTV들을 담을 힙 하나와 하나의 DSV를 담을 힙이 필요하다. 다음은 이 힙들을 생성..

본격적으로 Direct3D를 초기화하는 방법을 살펴보자. 꽤 길기 때문에 2파트로 나누어 작성하였다. 또한 앞서 살펴봤던 기본지식들을 모두 알고 있다는 가정하에 진행하려고 한다. 초기화 과정은 다음과 같은 단계들로 구성된다. D3D12CreateDevice 함수를 이용해서 ID3D12Device를 생성한다. ID3D12Fence 객체를 생성하고 서술자들의 크기를 얻는다. 4X MSAA(다중 표본화) 품질 수준 지원 여부를 점검한다. 명령 큐와 명령 리스트 할당자, 그리고 주 명령 리스트를 생성한다. 스왑 체인을 서술하고 생성한다. 응용 프로그램에 필요한 서술자 힙들을 생성한다. 후면 버퍼의 크기를 설정하고, 후면 버퍼에 대한 렌더 타깃 뷰(RTV)를 생성한다. 깊이 스텐실 버퍼를 생성하고, 그와 연관된 ..
Direct3D 12는 다중 스레드를 효율적으로 활용할 수 있도록 설계되었다. 명령 목록의 설계는 Direct3D가 다중 스레드 적용의 장점을 취하는 한 방법이다. 물체가 많은 큰 장면을 다룰 때, 장면 전체를 하나의 명령 목록으로 그리려 한다면 명령 목록을 구축하는 데 시간(CPU 시간)이 오래 걸린다. 이에 대한 해결책은 여러 개의 명령 목록을 병렬로 구축하는 것이다. 예를 들어 스레드 네 개를 띄워서 각자 하나의 명령 목록을 구축하게 하면, 전체적인 시간이 기존의 25%로 줄어든다. 다음은 명령 목록 구축에 다중 스레드를 적용할 때 주의해야 할 점 몇 가지이다. 명령 목록은 자유 스레드(Free-thread) 모형을 따르지 않는다. 즉, 보통의 경우 여러 스레드가 같은 명령 목록을 공유하지 않으며,..

흔히 쓰이는 렌더링 효과 중에는 한 단계에서 GPU가 자원 R에 자료를 기록하고, 이후의 한 단계에서 그 자원 R의 자료를 읽어서 사용하는 식으로 구현하는 것들이 많다. 그런데 GPU가 자원에 자료를 다 기록하지 않았거나 기록을 아예 시작하지도 않은 상태에서 자원의 자료를 읽으려 하면 문제가 생긴다. 이를 자원 위험 상황(Resource hazard)이라고 부른다. 이 문제를 해결하기 위해, Direct3D는 자원들에게 상태를 부여한다. 새로 생성된 자원은 기본 상태(default state)로 시작한다. 임의의 상태 전이를 Direct3D에게 '보고'하는 것은 전적으로 응용 프로그램의 몫이다. 이 덕분에, GPU는 상태를 전이하고 자원 위험 상황을 방지하는 데 필요한 일들을 자유로이 진행할 수 있다. ..

한 시스템에 CPU와 GPU가 병렬로 실행되다 보니 동기화 문제가 발생한다. 예를 들어 그리고자 하는 어떤 기하구조의 위치를 R이라는 자원에 담는다고 하자. 그 기하구조를 위치 p1에 그리려는 목적으로 CPU는 위치 p1을 R에 추가하고, R을 참조하는 그리기 명령 C를 명령 대기열에 추가한다. 명령 대기열에 명령을 추가하는 연산은 CPU의 실행을 차단하지 않으므로, CPU는 계속해서 다음 단계로 넘어간다. 만약 GPU가 그리기 명령 C를 실행하기 전에 CPU가 새 위치 p2를 R에 추가해서 R에 있던 기존 p1을 덮어쓰면, 기하구조는 의도했던 위치에 그려지지 않게 된다. 이런 문제의 해결책은 GPU가 명령 대기열의 명령들 중 특정 지점까지의 모든 명령을 다 처리할 때까지 CPU를 기다리게 하는 것이다...

GPU에는 명령 대기열(Command queue)이 하나 있다. CPU는 그리기 명령들이 담긴 명령 목록(Command list)을 Direct3D API를 통해서 그 대기열에 제출한다. 여기서 중요한 점은, 일단의 명령들을 명령 대기열에 제출했다고 해도, 그 명령들을 GPU가 즉시 실행하는 것은 아니라는 점이다. 명령들은 GPU가 처리할 준비가 되어야 비로소 실행되기 시작한다. 즉, GPU가 이전에 제출된 명령들을 처리하느라 바쁘게 돌아가는 동안 명령들은 그냥 대기열에 남아 있다. 명령 대기열이 비면 GPU는 할 일이 없으므로 그냥 놀게 된다. 반대로, 대기열이 꽉 차면 GPU가 명령들을 처리해서 대기열에 자리가 생길 때까지 CPU가 놀게 된다. 상황 모두 바람직하지 않다.최적의 성능을 얻으려면 최대한..
복잡한 게임은 텍스처, 3차원 메시 등 수많은 자원을 사용한다. 그런데 그 자원들 중 항상 GPU에 필요한 것은 많지 않다. 예를 들어 야외의 숲과 숲 속에 있는 큰 동굴을 배경으로 한 게임을 생각해 보자. 동굴을 표현하는 데 쓰이는 자원은 플레이어가 동굴에 들어가기 전까지는 필요하지 않으며, 또한 동굴에 들어가면 숲의 자원은 필요하지 않다. Direct3D 12에서 응용 프로그램은 자원을 GPU 메모리로 부터 내림('퇴거')으로써, 그리고 필요한 경우 다시 GPU에 올림('입주')으로써 자원의 상주성을 관리한다. (상주성이란, 자원이 GPU 메모리에 들어 있는지에 대한 여부이다.) 상주성 관리의 핵심은 응용 프로그램이 사용하는 GPU 메모리의 양을 최소화하는 것이다. 전체 게임에 필요한 자원들을 모두 ..

DXGI(DirectX Graphics Infrastructure)는 Direct3D와 함께 쓰이는 API로 DirectX 그래픽 런타임에 독립적인 저수준(Low-Level)의 작업을 관리한다. 또한 DirectX 그래픽을 위한 기본적이고 공통적인 프레임워크를 제공한다. DXGI는 유연성을 위해 새로운 그래픽 라이브러리가 나오더라도 변하지 않을 수 있도록 구성되어 있다. 예를 들어 2차원 랜더링 API에도 3차원 렌더링 API처럼 스왑 체인과 페이지 전환이 필요하다. 이 때문에, 스왑 체인을 대표하는 인터페이스인 IDXGISwapChain은 실제로 DXGI API의 일부이다. DXGI는 그 밖에도 여러가지 공통적인 그래픽 기능성을 처리한다. 이를테면 화면 모드 전환, 디스플레이 어탭터나 모니터, 지원되는..