자체 게임엔진 DevLog - 버퍼 클래스 구조 수정

이번에 진행한 작업은 버퍼 클래스 구조를 바꿨다.

이 작업도 렌더 스레드 문제와 관련이 있는데 렌더 타겟에서 특정 픽셀의 값을 읽어올때 Readback 버퍼가 필요한데

새로운 버퍼 클래스를 만드려고 하다가 보니까 현재의 버퍼 클래스의 구조가 마음에 들지 않았다.

 

현재의 버퍼 클래스 구현이 너무 복잡하다고 생각이 되서 바꿨다.

이게 엔진의 원래 버퍼 구조

이렇게 공통 클래스가 있고 

각 API가 VB, IB, CB를 각각 구현체를 만들어서 D3D11VB, D3D11IB, D3D11CB 이런식으로 개별로 구현하고 있다.

이제 Readback 버퍼가 필요하다? 그러면 또 D3D11ReabackBuffer, D3D12 ReadbackBuffer.. 또 다 구현해줘야 되는데 코드를 보다보니까 너무 겹치는 부분이 많아서 그냥 하나로 묶는게 낫겠다는 생각이 들었다.

왜 처음엔 이렇게 만들었나? -> Cherno의 엔진 영상의 영향을 받다보니까 별 생각없이 만들어서 이렇게되더라.

왜 바꿀 생각이 들었나? -> 각 구현체를 보다 보니까 똑같은 부분이 너무 많아서 보일러플레이트를 충분히 줄일 수 있을거 같다고 생각하게되었다.

 

그래서 변경한 구조는

이렇게 공통된 버퍼 클래스를 두고 BufferDesc로 용도를 결정하는 것이다. 

그리고 이 GPUBuffer 클래스에 대해서만 API별로 세부 구현을 해주면 된다.

 

생각해보면 그래픽스 API들이 전부 이런식으로 버퍼를 만드는데 따라하면 될 일이었다.

역시 머리가 나쁘면 몸이 고생한다.

이제 기존의 이 클래스들은 GPUBuffer클래스를 기반으로 가진다.

나눠둔 이유는 각 클래스들이 필요한 기능이나 매개변수를 전달하기 위해서

RenderDevice에서도 CreateGPUBuffer 함수 하나만 가지고 나머지 함수들은 다 날려버렸다.

 

이전 방식

DX12, Vulkan의 경우 정적인 버퍼에 데이터를 넣을때 uploadBuffer를 따로 만들어서 Copy해주는 방법을 사용해야 했었고,

이 때 uploadBuffer를 함수 내에서 대충 만들어서 처리했었는데 구조를 바꾸면서 UploadBuffer 타입을 따로 만들어줬다.

 

이제 VertexBuffer같은거 만드려고 API별로 가상함수 구현하는 일 없이 추상 클래스의 함수만으로 작업을 처리할 수 있다.

같은 방법으로 IndexBuffer, ConstantBuffer도 생성하도록 변경했다.

 

DX12와 Vulkan을 위한 TransitionBufferState, TransitionTextureState함수를 추가했다.

가상함수를 구현할때는 각 API별로 함수내부에서 Barrier 필요한 API는 하고 이런게 됐는데

이렇게 공통 추상화 단계에서 처리하려니 마땅한 방법이 떠오르지 않아서 이렇게 했다.

 

DX11이랑 OpenGL은 필요없는 기능이긴한데 통일성을 위해서 더미로 놔뒀다.

CaptureBuffer는 복사할 버퍼의 수명을 보장해주는 역할을 한다.

다 만들고 뿌듯해서 실행했는데 수명 문제가 터져서 급하게 추가하게 되었다.

 

uploadBuffer는 생성 함수 스코프 내에서 수명이 보장된다.

EnqueueCommand에 람다 캡쳐로 전달하면서 람다함수가 실행될 때까지로 수명을 연장하지만

실제 백엔드의 CommandList에 명령을 기록하고 람다함수가 끝나면 uploadBuffer의 참조 카운트가 더이상 없게 되므로 

소멸하게 된다

실제로 CopyBuffer가 실행될 때는 이미 소멸되어 버린 객체를 사용하려고 하는 문제가 발생함.

 

그래서 임시배열에 push_back 해서 참조카운트를 늘리는 것으로 CopyBuffer가 끝날때까지 수명을 보장받게 했다.

 

내부 구조를 수정한 것이고 외부에서 사용하는 방법에는 따로 변경점이 없었기 때문에

API 별로 잘 실행되는지만 확인해주었음.