비타Cpp

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

한 시스템에서 두 개의 처리 장치가 병렬로 실행되다 보니 여러 가지 동기화 문제가 발생한다. 이런 문제의 해결책 하나는 GPU가 명령 대기열의 명령들 중 특정 지점까지의 모든 명령을 다 처리할 때까지 CPU를 기다리게 하는 것이다. 대기열의 모든 명령을 처리하는 것을 가리켜 Flush(방출)이라고 한다. 이때 필요한 것이 Fence(울타리)라고 부르는 객체이다. Fence는 ID3D12Fence 인터페이스로 대표되며, GPU와 CPU의 동기화를 위한 수단으로 쓰인다. 다음은 Fence 객체를 생성하는 메서드이다. HRESULT CreateFence( UINT64 InitialValue, D3D11_FENCE_FLAG Flags, REFIID ReturnedInterface, void **ppFence )..

그래픽 프로그래밍에서는 두 가지 처리장치가 작동한다. 하나는 GPU이고 또 하나는 CPU이다. 이들은 병렬로 작동 하지만, 종종 동기화가 필요하다. 하지만 최적의 성능을 위해서는 동기화를 최소화하여야 한다. 동기화는 한 처리 장치가 작업을 마칠 때까지 다른 한 장치가 놀고 있어야 함을 의미하며, 성능에 바람직하지 않다. CPU에는 명령 대기열(Command Queue)가 하나 있다. CPU는 그리기 명령들이 담긴 명령 목록(Command List)을 Direct3D API를 통해서 그 대기열에 제출한다. 여기서 중요한 점은, 일단 Command List의 명령들을 제출했다고 해도, 그 명령들이 GPU에서 즉시 실행하는 것은 아니라는 점이다. GPU가 처리할 준비가 되어있어야 비로소 실행되기 시작한다. 즉..

복잡한 게임은 텍스처, 3차원 메시 등 많은 자원들을 사용한다. 그런데 그 자원들 중 항상 GPU에 상주해 있어야 하는것들은 많지 않다. 즉, 필요한 자원은 GPU의 메모리에 '입주' 시켜야 하고, 반대로 한동안 필요 없는 자원은 GPU의 메모리에서 '퇴거' 시킴으로써 자원의 상주성(Residency)를 관리할 필요가 있다. 예를들어, 게임에서 숲과 숲 속에 있는 큰 동굴이 있을때, 숲에서 동굴안을 표현하는 자원은 필요 없으며, 동굴 안에서도 숲의 자원이 필요 없을때 상주성 관리가 필요하다. 상주성 관리의 핵심은 응용 프로그램이 사용하는 GPU 메모리의 양을 최소화 하는데에 있다. 게임에서 사용되는 모든 자원이 메모리에 들어갈수 없을수도 있고, 다른 응용프로그램도 메모리를 사용 해야 할 수도 있기 때문에..