real-time rendering 을 구현할 때, drawcall 을 적게 유지하는 것은 굉장히 중요하다. 특히나 게임 같은 렌더링 외 다른 처리도 중요해지는 경우, CPU 부담이 최소한이 되어야 더 많은 것들을 할 여유 비용이 생겨 굉장히 중요하다. drawcall 을 줄이는 관점에서 Unity 를 사용할 때, 지원하는 기능들이 여러개 있어 혼동이 올 수도 있다. 최근에는 각자의 정의와 상관관계를 명확히 하지 않아서 이를 정리하는데에 약간의 시간을 투자했었다.

static/dynamic batching, gpu instancing 의 예상되는 동작과 상관관계를 알아본다,

유니티에서 제공하는 built-in shader 를 사용하면, Other/Rendering/ShaderLab (Unity 2018 기준) 의 메모리가 꽤 많이 늘어있는 것을 볼 수 있다. 여기에 GraphicsSettings 에서 strip 관련 세팅 조차 꺼놓았다면 엄청나게 크다. 이 글에선 이의 공간 복잡도를 줄일 방법을 이야기한다.

graphics community 에선 피부를 표현하기 위해 많은 연구와 개발이 시도되었었다. 그 중에서도 사람의 피부는 어느 정도의 니즈가 있기에 많은 연구자/엔지니어들의 관심을 끌 수 밖에 없다. 여태 연구된 것들 중, 유명한 것 같은 두가지 : Efficient Rendering of Human Skin, Pre-Integrated Skin Shading을 간단하게 정리한다.

당위

srp 의 첫 등장은 unity 2018 이였고, 현재 글 작성 시점에선 시간이 꽤 많이 흘렀다. 처음에는 수많은 버그가 예측되어 잘 사용하지 않지만, 지금은 시간이 꽤나 흘러 프로덕션에의 도입도 고려해볼 법 하다. 수많은 버그 픽스를 통해 어느 정도 안정되었을 것 같다? 라고 생각한다. 아직은 어떤 프로덕트에서 쓰였다는 소식은 듣지 못했지만, 추후 사용을 위해 간단하게 접근해본다.

이 글에서는 간단하게 물체를 렌더링 하는 것까지만 한다.

• Unity 2021.3.0f1, com.unity.render-pipelines.core@14.0 기준으로 작성됨

2019 부터 srp 가 정식 릴리즈 되었다. 현 회사 프로젝트는 pre-built srp 를 쓰기엔 이것저것 붙여놓은 상태라 애매해서 core rp 라이브러리 부터 확인할 필요가 있다. 어떤 차이가 있는지 확인하기 위해 관련 정보를 번역하고 저장한다. 2019 -> 2020 -> 2021 의 차이를 기록하고, 중복되는 내용이 있다면 제거한다. (예: 2019 릴리즈 <-> 2020 초기) 변경 사항은 버젼 오름차순으로 정리한다.

• 마지막 참조 : com.unity.render-pipelines.core@14.0

VR을 제외한 PC 및 콘솔 플랫폼에선 보통은 deferred shading 을 많이 사용한다. 거의 대부분은 MRT를 사용하여 각각의 프레임 버퍼로 픽셀 데이터를 저장하고, 마지막 패스에서 이를 다시 참조하여 계산한다. 이 방식은 필자가 아는 것 기준으로 10년이 넘어서도 주가되는 방식이다.

하지만 모바일 기기가 등장하고, 거의 대부분의 모바일 GPU 에서는 절대적으로 유닛 갯수가 부족하기 때문에 픽셀을 처리하는 ROP 유닛이 관여하는 부분을 타일로 나누어 locality 를 이용하여 처리한다. (정점 처리는 그대로 간다. 그래서 절대적으로 정점의 한계는 명확하다.) 이 때문에 OpenGL ES 3.x 버젼이 현역인 때의 절대적인 문제점은 deferred shading 을 성능상의 문제로 사용할 수 없다는 점이였다. deferred shading 을 구현하는 방법은 무식하게 프레임버퍼를 크게 할당하여 하나하나 인코딩하는 방법이였는데, 픽셀을 타일 단위로 처리하는 방법을 가진 모바일 GPU 에서는 이전의 방법으로는 만족할만한 성능을 내기 어려웠다.

그래서 2014/2015 년에 MALI 제품군과 몇몇 PowerVR 제품군에서 사용 가능한 pixel local storage 를 OGLES 에 multi-vendor extension 분류로 등록되었다. 사용 방법은 GLES 쉐이더 소스를 수정하면 쉽게 변경 가능하다. deferred shading 을 사용하기 위한 구체적인 예시를 아래에 가져와보았다. 역시 2 패스로 이루어진다.

※ docs.nvidia : OpenGL ES Programming Tips의 내용을 번역하는 포스팅입니다. 시간이 꽤 지난 내용으로 글의 내용은 현재 상황과 다를 수 있습니다. 또한 모든 내용이 번역되어 있지 않을 수도 있습니다.

C++ 에서 메모리 관리는 중요한 문제다. garbage collector 를 지원하는 현대의 많은 언어들과 달리 C++은 OS에서 제공하는 시스템콜을 사용하여 메모리를 직접 할당 받고 반환한다. 하지만 메모리 할당/해제 시스템콜은 가상 페이지 로드 및 병합 비용이 큰 편이고, 성능에 민감한 프로그래머들은 이를 줄이기 위해 고민의 벽에 부딫친다. 이를 개선시키기 위해 많은 사람들이 방법을 고민했다. 그 중에서 필자가 일반적으로 사용하는 방법은 영구/가변 메모리 영역 처럼 단계를 나누어 가상 메모리 페이지 크기 이상의 단위로 할당받아 각각의 뭉텅이에서 공간을 나눠쓰는 방법이다.

그렇지만 단순히 할당자를 구현하는 것만으로 끝날 문제는 아니다. 직접 컨테이너를 구현하면 입맛에 맞게 쓸 수 있겠지만 여러 비용이 허락해야 가능하고, 사용자 정의 할당자를 지원하는 표준 STL은 여러 제약사항이 존재하기에 쉽지 않다. 하지만 표준 STL과 비슷하게 게임 응용 프로그램을 위해 표준 STL을 개량한 EASTL이라는 대체제를 통해 원하는 메모리 할당자 기능을 쉽게 구현할 수 있었다. 이 글에서는 EASTL에서의 커스텀 메모리 할당자 및 이의 장단점을 서술한다. 해당 포스팅은 EASTL 3.17.06을 기준으로 작성되었다.

※ open-std : EASTL의 내용을 번역하는 포스팅입니다. 시간이 꽤 지난 내용으로 글의 내용은 현재 상황과 다를 수 있습니다. 또한 모든 내용이 번역되어 있지 않을 수도 있습니다.

HDR 에 대한 내용들을 찾다보면 color space 에 대한 개념을 기본적으로 알고 있어야 수학적인 내용을 배울 때 단계적으로 학습해야 하는 것처럼 대부분의 내용들을 쉽게 이해할 수 있다. 필자의 경우 이에 대한 학습이 전혀 없었고, 직접 자료를 찾아보기 전까지 무슨 소리인지 전혀 몰랐던 상태였다. 다행히 여러 분야에 걸쳐 꽤 많이 알려진 지식들이고 받아들이기에 어려운 개념은 아니라서 이에 대해 글을 쓰면서 정리해보려 한다.