PC 및 콘솔 게임의 GPU 사용 관리

Unity는 화면에 GameObject를 그리기 위해 그래픽 API(예: OpenGL, Vulkan 또는 Direct3D)에 드로우 호출을 발행합니다. 각 드로우 호출은 리소스를 많이 소모합니다.

재료 전환과 같은 드로우 호출 간의 상태 변경은 CPU 측에서 성능 오버헤드를 유발할 수 있습니다. PC 및 콘솔 하드웨어는 많은 드로우 호출을 처리할 수 있지만, 각 호출의 오버헤드가 여전히 높기 때문에 이를 줄이려고 노력해야 합니다. 모바일 장치에서는 드로우 호출 최적화가 필수적입니다. 이를 드로우 호출 배칭으로 달성할 수 있습니다.

드로우 호출 배칭은 이러한 상태 변경을 최소화하고 객체 렌더링의 CPU 비용을 줄입니다. Unity는 고해상도 렌더 파이프라인(HDRP) 또는 유니버설 렌더 파이프라인(URP)를 사용하여 여러 객체를 더 적은 배치로 결합할 수 있습니다:

• SRP 배칭: SRP 배처를 파이프라인 자산의 고급에서 활성화하십시오. 호환 가능한 셰이더를 사용할 때 SRP 배처는 드로우 호출 간의 GPU 설정을 줄이고 GPU 메모리에서 재료 데이터를 지속적으로 유지합니다. 이것은 CPU 렌더링 시간을 크게 단축할 수 있습니다. 최소한의 키워드로 셰이더 변형을 줄여 SRP 배칭을 개선하십시오. 프로젝트가 이 렌더링 워크플로를 어떻게 활용할 수 있는지 보려면 SRP 문서를 참조하십시오.
• GPU 인스턴싱: 동일한 메시와 재료를 가진 많은 수의 동일한 객체가 있는 경우, 그래픽 하드웨어를 통해 GPU 인스턴싱을 사용하여 배치하십시오. GPU 인스턴싱을 활성화하려면 Project 창에서 재질을 선택한 다음 Inspector에서 Enable instancing을 체크하십시오.
• Static batching: 움직이지 않는 기하학의 경우, Unity는 동일한 재질을 공유하는 메시의 드로우 콜을 줄일 수 있습니다. 이것은 동적 배칭보다 더 효율적이지만 더 많은 메모리를 사용합니다. 절대 움직이지 않는 모든 메시를 Inspector에서 Batching Static으로 표시하십시오. Unity는 빌드 시간에 모든 정적 메시를 하나의 큰 메시로 결합합니다. StaticBatchingUtility 클래스는 런타임에 이 정적 배치를 생성할 수 있게 해줍니다 (예: 움직이지 않는 부분의 절차적 레벨을 생성한 후).
• Dynamic batching: 작은 메시의 경우, Unity는 CPU에서 정점을 그룹화하고 변환한 다음 한 번에 모두 그릴 수 있습니다. 그러나 300개 이하의 정점과 총 900개의 정점 속성을 가진 충분한 저폴리 메시가 없는 한 이를 사용하지 않아야 합니다. 그렇지 않으면, 이를 활성화하면 작은 메시를 배치하기 위해 CPU 시간을 낭비하게 됩니다.

몇 가지 간단한 방법으로 배칭을 극대화할 수 있습니다:

• 장면에서 가능한 한 적은 텍스처를 사용하십시오. 적은 텍스처는 고유한 재질을 적게 요구하므로 배치하기가 더 쉽습니다. 또한 가능한 경우 Texture Atlases를 사용하십시오.
• 항상 가능한 최대 아틀라스 크기로 라이트맵을 베이킹하십시오. 적은 라이트맵은 재질 상태 변경을 적게 요구하지만 메모리 사용량에 주의하십시오.
• 재질을 의도치 않게 인스턴스화하지 않도록 주의하십시오. 스크립트에서 Renderer.material에 접근하면 재질이 복제되고 새 복사본에 대한 참조가 반환됩니다. 이것은 이미 재질을 포함하고 있는 기존 배치를 깨뜨립니다. 배치된 객체의 재질에 접근하려면 Renderer.sharedMaterial 대신 사용하십시오.
• 최적화 중에 Profiler 또는 렌더링 통계를 사용하여 정적 및 동적 배치 수와 총 드로우 콜 수를 주의 깊게 살펴보십시오.

자세한 정보는 Draw call batching 문서를 참조하십시오.

프레임 디버거를 사용하여 단일 프레임에서 재생을 멈추고 Unity가 장면을 구성하는 과정을 단계별로 살펴볼 수 있습니다. 이렇게 하면 최적화 기회를 식별할 수 있습니다. 불필요하게 렌더링되는 GameObject를 찾아 비활성화하여 프레임당 드로우 콜 수를 줄이십시오.

프레임 디버거의 주요 장점 중 하나는 드로우 콜을 장면의 특정 GameObject와 연관시킬 수 있다는 것입니다. 이로 인해 외부 프레임 디버거에서는 불가능할 수 있는 특정 문제를 조사하기가 더 쉬워집니다.

참고: 프레임 디버거는 개별 드로우 콜이나 상태 변화를 표시하지 않습니다. 자세한 드로우 콜 및 타이밍 정보를 제공할 수 있는 것은 네이티브 GPU Profilers뿐이지만, 프레임 디버거는 여전히 파이프라인 문제나 배치 문제를 디버깅하는 데 매우 유용할 수 있습니다.

자세한 내용은 Frame Debugger documentation을 읽으십시오.

필레이트는 GPU가 매초 화면에 렌더링할 수 있는 픽셀 수를 나타냅니다. 게임이 필레이트에 의해 제한되는 경우, 이는 GPU가 처리할 수 있는 것보다 프레임당 더 많은 픽셀을 그리려고 한다는 것을 의미합니다.

같은 픽셀 위에 여러 번 그리는 것을 오버드로우라고 합니다. 오버드로우는 필레이트를 감소시키고 추가 메모리 대역폭을 소모합니다. 오버드로우의 가장 일반적인 원인은 다음과 같습니다:

• 겹치는 불투명 또는 투명 기하학
• 복잡한 셰이더, 종종 여러 렌더 패스를 포함하여
• 비최적화된 입자
• 겹치는 UI 요소

영향을 최소화해야 하지만, 오버드로우를 해결하는 데는 만능 해결책이 없습니다. 영향을 줄이기 위해 다음 기술을 실험해 보세요.

다른 플랫폼과 마찬가지로, 콘솔에서의 최적화는 종종 드로우 콜 배치를 줄이는 것을 의미합니다. 다음은 도움이 될 수 있는 몇 가지 기술입니다:

• 전경 객체 뒤에 숨겨진 객체를 제거하고 오버드로우를 줄이기 위해 오클루전 컬링을 사용하세요. 이 작업은 추가 CPU 처리를 요구하므로, GPU에서 CPU로 작업을 이동하는 것이 실제로 유익한지 확인하기 위해 프로파일러를 사용하세요.
• GPU 인스턴싱은 동일한 메시와 재질을 공유하는 많은 객체가 있을 경우 배치를 줄일 수 있습니다. 장면의 모델 수를 제한하면 성능이 향상될 수 있습니다. 예술적으로 수행된다면, 반복적으로 보이지 않게 복잡한 장면을 구축할 수 있습니다.
• SRP 배처는 드로우 콜 간의 GPU 설정을 줄이기 위해 바인드 및 드로우 GPU 명령을 배치할 수 있습니다. 이 SRP 배칭의 이점을 얻으려면 필요한 만큼 많은 재질을 사용하되, 호환 가능한 셰이더의 소수로 제한하세요 (예: URP 및 HDRP의 Lit 및 Unlit 셰이더).

컬링은 각 카메라에 대해 발생하며, 특히 여러 카메라가 동시에 활성화될 때 성능에 큰 영향을 미칠 수 있습니다. Unity는 두 가지 유형의 컬링을 사용합니다:

• 프러스텀 컬링은 모든 카메라에서 자동으로 수행됩니다. 이는 성능을 절약하기 위해 뷰 프러스텀 외부의 게임 오브젝트가 렌더링되지 않도록 보장합니다.
• 레이어별 컬링 거리를 Camera.layerCullDistances를 통해 수동으로 설정할 수 있습니다. 이렇게 하면 기본 farClipPlane 속성보다 짧은 거리에서 작은 게임 오브젝트를 컬링할 수 있습니다. 이 작업을 수행하려면 GameObject를 Layers로 구성하십시오. 각 32개 레이어에 farClipPlane보다 작은 값을 할당하려면 .layerCullDistances 배열을 사용하십시오(또는 기본값으로 0을 사용하십시오).
• Unity는 먼저 레이어별로 제거합니다. 카메라가 사용하는 레이어의 GameObject만 유지합니다. 그 후, Frustum culling은 Camera Frustum 외부의 모든 GameObject를 제거합니다.
• Frustum culling은 사용 가능한 작업자 스레드를 활용하는 일련의 작업으로 수행됩니다. 각 레이어 제거 테스트는 빠릅니다(본질적으로 비트 마스크 작업일 뿐입니다). 그러나 이 비용은 많은 수의 GameObject가 있을 경우 여전히 누적될 수 있습니다. 이것이 프로젝트에 문제가 된다면, 세계를 "섹터"로 나누고 카메라 프러스텀 외부의 섹터를 비활성화하는 시스템을 구현해야 할 수도 있습니다.
• Occlusion culling은 카메라가 볼 수 없는 경우 Game 뷰에서 모든 GameObject를 제거합니다. 다른 객체 뒤에 숨겨진 객체는 여전히 렌더링될 수 있으며 자원을 소모할 수 있습니다. 이들을 제거하려면 Occlusion culling을 사용하십시오.
• 예를 들어, 문이 닫혀 있고 카메라가 방 안을 볼 수 없는 경우 방을 렌더링하는 것은 불필요합니다. Occlusion culling을 활성화하면 성능이 크게 향상될 수 있지만 디스크 공간, CPU 시간 및 RAM을 더 많이 사용할 수 있습니다. Unity는 빌드 중에 Occlusion 데이터를 베이킹하고, 장면을 로드하는 동안 디스크에서 RAM으로 로드해야 합니다.
• 카메라 뷰 외부의 Frustum culling은 자동이지만, Occlusion culling은 베이킹된 프로세스입니다. 단순히 객체를 Static, Occluders, 또는 Occludees로 표시한 다음 Window > Rendering > Occlusion culling 대화 상자를 통해 베이킹하십시오.

자세한 내용은 Working with Occlusion culling tutorial을 참조하십시오.

Allow Dynamic Resolution 카메라 설정을 사용하면 개별 렌더 타겟을 동적으로 스케일링하여 GPU의 작업량을 줄일 수 있습니다. 응용 프로그램의 프레임 속도가 감소하는 경우, 일관된 프레임 속도를 유지하기 위해 해상도를 점진적으로 낮출 수 있습니다.

Unity는 성능 데이터가 프레임 속도가 GPU에 의해 제한될 것으로 제안할 경우 이 스케일링을 트리거합니다. 스크립트를 사용하여 이 스케일링을 사전 예방적으로 수동으로 트리거할 수도 있습니다. 이는 애플리케이션의 GPU 집약적인 섹션에 접근할 때 유용합니다. 점진적으로 스케일링하면 동적 해상도가 거의 눈에 띄지 않을 수 있습니다.

지원하는 플랫폼 목록은 동적 해상도 매뉴얼 페이지를 참조하십시오.

때때로 게임 중에 여러 관점에서 렌더링해야 할 필요가 있습니다. 예를 들어, 1인칭 슈팅 게임(FPS)에서는 플레이어의 무기와 환경을 서로 다른 시야(FOV)로 별도로 그리는 것이 일반적입니다. 이는 전경 객체가 배경의 광각 FOV를 통해 왜곡되어 보이는 것을 방지합니다.

URP에서 카메라 스태킹을 사용하여 여러 카메라 뷰를 렌더링할 수 있습니다. 그러나 각 카메라에 대해 여전히 상당한 컬링 및 렌더링이 수행됩니다. 각 카메라는 의미 있는 작업을 하든 아니든 일부 오버헤드를 발생시킵니다.

렌더링에 필요한 카메라 구성 요소만 사용하십시오. 모바일 플랫폼에서는 활성 카메라마다 렌더링하지 않더라도 최대 1ms의 CPU 시간을 사용할 수 있습니다.

객체가 멀어지면 세부 수준 (LOD)이 이를 조정하거나 낮은 해상도의 메시와 더 간단한 재료 및 셰이더를 사용하도록 전환할 수 있습니다. 이는 GPU 성능을 강화합니다.

자세한 내용은 Unity Learn의 LOD 작업하기 과정을 참조하십시오.

포스트 프로세싱 효과의 비용을 GPU에서 확인하세요. 블룸 및 심도와 같은 전체 화면 효과는 비용이 많이 들 수 있으므로, 시각적 품질과 성능 간의 원하는 균형을 찾을 때까지 실험해 볼 가치가 있습니다.

포스트 프로세싱은 런타임 중에 크게 변동하지 않습니다. 볼륨 오버라이드를 결정한 후, 포스트 프로세싱 효과에 총 프레임 예산의 정적 부분을 할당하세요.

테셀레이션은 형태를 더 작은 버전으로 세분화하여 기하학을 증가시켜 세부 사항을 향상시킬 수 있습니다. 테셀레이션이 가장 의미 있는 예가 있지만, Unity 데모 죽은 자의 책의 나무 껍질과 같은 경우를 제외하고는, 콘솔에서 테셀레이션을 피하는 것이 좋습니다. GPU에서 비용이 많이 들기 때문입니다.

죽은 자의 책 데모에 대해 여기에서 더 읽어보세요.

테셀레이션 셰이더와 마찬가지로, 기하학 및 정점 셰이더는 GPU에서 프레임당 두 번 실행될 수 있습니다 - 한 번은 깊이 프리패스 중에, 또 한 번은 그림자 패스 중에 실행됩니다.

GPU에서 정점 데이터를 생성하거나 수정하려면, 컴퓨트 셰이더가 종종 더 나은 선택입니다. 특히 기하학 셰이더와 비교할 때 그렇습니다. 컴퓨트 셰이더에서 작업을 수행하면 실제로 기하학을 렌더링하는 정점 셰이더가 훨씬 더 빠르게 작동할 수 있습니다.

셰이더 핵심 개념에 대해 더 알아보세요.

GPU에 드로우 콜을 보내면, 그 작업은 Unity가 GPU 내의 사용 가능한 SIMD에 분배하는 많은 파도 전선으로 나뉩니다. 각 SIMD는 동시에 실행될 수 있는 최대 파도 전선 수가 있습니다.

파도 전선 점유율은 현재 사용 중인 파도 전선 수를 최대 수에 대한 비율로 나타냅니다. GPU의 잠재력을 얼마나 잘 활용하고 있는지를 측정합니다. 콘솔 개발을 위한 프로파일링 도구는 파도 전선 점유율을 매우 자세히 보여줍니다.

Unity의 죽은 자의 책에서 위의 예에서, 정점 셰이더 파도 전선은 녹색으로 나타나고 픽셀 셰이더 파도 전선은 파란색으로 나타납니다. 하단 그래프에서 많은 정점 셰이더 파도 전선이 픽셀 셰이더 활동 없이 나타납니다. 이는 GPU의 활용도가 낮음을 보여줍니다.

픽셀로 이어지지 않는 많은 정점 셰이더 작업을 수행하고 있다면, 이는 비효율성을 나타낼 수 있습니다. 낮은 웨이브프론트 점유율이 반드시 나쁜 것은 아니지만, 이는 셰이더를 최적화하고 다른 병목 현상을 확인하는 데 사용할 수 있는 지표입니다. 예를 들어, 메모리 또는 계산 작업으로 인해 정체가 발생하는 경우, 점유율을 높이면 성능이 향상될 수 있습니다. 반면에, 너무 많은 비행 중 웨이브프론트는 캐시 스래싱을 유발하고 성능을 저하시킬 수 있습니다.

GPU를 충분히 활용하지 못하는 간격이 있다면, 비동기 계산을 활용하여 계산 셰이더 작업을 그래픽 큐와 병렬로 이동할 수 있습니다. 예를 들어, 그림자 맵 생성 중에 GPU는 깊이 전용 렌더링을 수행합니다. 이 시점에서는 픽셀 셰이더 작업이 거의 발생하지 않으며 많은 웨이브프론트가 비어 있습니다.

계산 셰이더 작업을 깊이 전용 렌더링과 동기화할 수 있다면, 이는 GPU의 전반적인 사용을 개선하는 데 도움이 됩니다. 사용되지 않는 웨이브프론트는 스크린 스페이스 앰비언트 오클루전 (SSAO) 또는 현재 작업을 보완하는 모든 작업에 도움이 될 수 있습니다.

Unite에서 고급 콘솔을 위한 성능 최적화에 대한 이 세션을 시청하세요.