안녕하세요 여러분, Spooker의 테크 리드(Tech Lead) Dan입니다. 저희는 현재 마법 같은 Steam Deck Verified 태그를 획득하기 위해 노력 중이며, 지난 며칠 동안 최적화(Optimization)에 대해 깊이 있게 파고들었습니다. 저희가 병목 현상(Bottlenecks)을 프로파일링(Profiling)하고 해결하기 위해 취한 정확한 과정과 단계들을 공유하고자 합니다. 이것이 여러분의 Native Linux 빌드를 최적화하는 데 도움이 되기를 바랍니다!

기준점 (최적화 전)
상황 설명을 위해 말씀드리자면, 저희는 첫날부터 성능(Performance)에 대해 상당히 엄격하게 관리해 왔습니다. 수동 메모리 로드/언로드(Load/Unload)를 위해 Addressables를 사용하고, 텍스처(Textures)에는 mipmap streaming을 적용하며, 코드를 철저하게 감사(Audit)합니다. 무거운 루프(Loops) 대신, 저희 코드베이스는 R3와 주입(Injection)을 위한 VContainer를 사용하며, UniTask와 같은 zero-alloc 라이브러리를 사용하여 메모리 점유율(Footprint)을 낮게 유지하는 반응형(Reactive) 구조입니다. 그럼에도 불구하고, 당시 저희의 Steam Deck (64GB LCD) 상태는 다음과 같았습니다:

FPS: 안정적인 60
GPU: 90% (1520mhz)
CPU: 40% (1949mhz)
VRAM: 2.9 GB
RAM: 6.9 GB

60fps는 훌륭하지만, GPU가 90%에 머물러 있다는 것은 여유 자원(Headroom)이 전혀 없다는 것을 의미했습니다. 새로운 기능으로 그래픽을 조금이라도 더 밀어붙였다면, 과부하가 걸려 즉시 프레임 드랍(Frame drop)이 발생했을 것입니다.

첫 번째 승리: CPU 감소
GPU를 다루기 전에 한 가지 빠른 변화를 주었습니다. Amplify Imposters를 제거하고 Unity 6.3의 새로운 자동 LOD 시스템으로 교체했습니다. Amplify는 훌륭한 패키지이지만, 저희의 사용 사례(Use case)에는 잘 맞지 않았습니다.
결과: CPU 사용량이 40%에서 15~20%로 즉시 감소했습니다. 시작부터 엄청난 성과였습니다.

본격적인 추적: 90% GPU 병목 현상 프로파일링
GPU를 정확히 무엇이 억제하고 있는지 알아내기 위해 격리된 빌드(Isolated builds)에서 다양한 테스트를 실행했습니다. 저희가 따랐던 정확한 작업 순서는 다음과 같습니다:

포스트 프로세싱(Post-processing) 끄기: 변화 없음.
렌더 스케일(Render Scale)을 0.5로 설정: 엄청난 감소. 이를 통해 저희가 Fill Rate 또는 Pixel Shader 바운드(Bound)일 가능성이 높다는 것을 즉시 알 수 있었습니다. 프레임 레이트(Frame rate)를 60에서 30fps로 제한하여 이를 확인했으며, GPU 부하가 유사하게 감소하는 것을 확인했습니다. (STP/FSR에 대한 참고 사항: 단순히 여기에 업스케일링(Upscaling)을 적용할 수도 있었지만, 그것은 임시방편(Band-aid)일 뿐입니다.

근본 원인을 해결한다면, STP/FSR은 완전히 불필요해지거나 단순히 덤(icing on the cake)이 될 것입니다). Forward+ vs. Forward: Steam Deck이 연산(Compute operations) 과정에서 과부하가 걸리는지 확인하기 위해 Forward 렌더링(Forward rendering)으로 전환해 보았습니다. 변화는 없었습니다. "White Material" 테스트: 게임 내의 모든 재질(Material)을 기본적인 흰색 재질로 교체했습니다. 이를 통해 우리가 구체적으로 필 레이트 바운드(Fill Rate Bound) 상태임을 확인했습니다. 즉, 메모리 대역폭(Memory bandwidth), 오버드로(Overdraw), 또는 텍스처(Textures) 문제로 인해 병목 현상이 발생하고 있었다는 의미입니다. Frame Debugger - 문제의 카메라: Frame Debugger를 실행하자마자 즉각적인 원인을 찾아냈습니다. 렌더 텍스처 카메라(Render texture camera)가 잘못된 시점에 활성화되어 계속 켜져 있었습니다. 우리의 설정상 영향은 미미했지만, 공짜로 얻은 이득은 언제나 환영입니다. 수정 완료. Frame Debugger - 주요 원인: 디버거를 통해 SSAO와 데칼(Decals) 사이에 정확히 위치한 59개의 드로우 콜(Draw calls)을 포착했습니다. 어차피 데칼은 모바일 하드웨어에서 성능이 뛰어나지 않으며, URP 에셋의 SSAO 설정 또한 완전히 최대치로 설정되어 있었습니다. 해결 방법: 데칼을 완전히 비활성화했습니다(실제로 필요하지 않으며, 나중에 쿼드/스피어 셰이더(Quad/sphere shaders)로 교체할 예정입니다). 그다음, 우리의 비주얼 스타일에 실제로 필요한 수준까지 SSAO 설정을 공격적으로 최적화했습니다. 결과: 이것이 GPU 수치에 변화를 준 첫 번째 사례였습니다. 끈질기게 유지되던 90%의 점유율이 70% 초반대로 떨어졌습니다. 마지막 압착(The Final Squeeze): 흐름을 탄 김에, 가능한 모든 곳에서 불필요한 요소들을 깎아냈습니다: Bloom: 고품질 필터링(High Quality Filtering)을 껐습니다. 우리의 비주얼에는 필요하지 않았습니다. 불투명 텍스처(Opaque Textures): 불투명(Opaque) 텍스처를 4x box로 다운샘플링(Downsampled)했습니다. 이는 시각적 영향은 최소화하면서 얻을 수 있는 환상적인 절충안이었습니다(계산 결과 약 256k 픽셀에서 64k 픽셀로 줄어들었습니다). 지형 구멍(Terrain Holes): 껐습니다. 우리는 Unity 지형(Terrain)을 사용하지도 않지만, 툴팁에서는 빌드 속도를 높여준다고 주장합니다. 약간 의구심이 들긴 하지만, 뭐 어때요, 안 할 이유가 없죠? 조명/반사(Lighting/Reflections): MainLightShadows, Reflection Probes, 그리고 Reflection Probe Atlases를 모두 껐습니다.

우리의 장면(scenes)에는 그것들이 필요하지 않았고, 이미 개별 조명(individual lights)에서 그림자(shadows)를 비활성화한 상태였습니다.

최종 결과 (최적화 후)
현재 Steam Deck의 상태는 다음과 같습니다:
FPS: 여전히 흔들림 없는 60 FPS
GPU: 55% – 70% (훨씬 낮은 830mhz에서 작동)
CPU: 15% – 20%
VRAM: 2.4 GB (0.5 GB 감소)
RAM: 6.4 GB (0.5 GB 감소)

가장 놀라운 점: 100% 충전 상태에서의 Steam Deck 배터리 지속 시간이 약 2시간에서 4.5시간으로 급증했습니다.

전반적으로 우리는 이 결과에 매우 만족하고 있습니다. 단순히 문제에 FSR을 던져 넣는 대신, 병목 현상(bottleneck)을 실제로 격리(isolate)하는 데 시간을 투자한 것이 엄청난 발열 제어 및 배터리 이득을 가져다주었습니다. 다시 한번 말씀드리자면, 저희는 이를 위해 Proton을 사용하지 않았으며, 네이티브 Linux 빌드(native Linux build)를 선택했습니다. 이 진단 체크리스트가 여러분의 프로젝트에서도 배터리 수명을 몇 시간 더 확보하는 데 도움이 되기를 바랍니다!

제출자: /u/DantheDev_ [link] [comments]