원시 카운터와 사용률을 구분한다
Jan Mróz의 실험은 원시 카운터를 GPU active cycles로 나누고, 특정 유닛을 압박하는 벤치마크에 맞춰 배율을 조정한다. 여기서 만들어진 100%는 해당 장치와 부하의 보정 기준이지 다른 Mali 세대에도 통하는 물리적 최대 처리량 인증이 아니다.
보정값을 옮길 때는 카운터 이름·단위·GPU 모델·드라이버·도구 버전부터 확인한다. 활성 사이클이 작은 구간은 비율이 불안정할 수 있고, 단위 시간당 처리량과 활성 사이클당 처리량은 다른 질문에 답한다.
도구의 서로 다른 증거를 연결한다
Streamline: 시간 구간의 자원·사이클 관측
RenderDoc: 프레임의 호출·리소스·패스 구조
동일 장면·설정·구간: 가설을 하나씩 비교
프레임 캡처에서 draw와 pass 순서를 확인했다고 GPU 실행 시간이 곧바로 입증되지는 않는다. CPU 제출, 큐 대기, GPU 실행과 화면 표시의 시간을 구분하고, 각 도구가 실제로 제공한 측정 범위만 인용한다. 캡처 자체의 실행 영향도 별도로 본다.
Streamline에는 이미 분석 템플릿과 annotation 기능을 소개한 Arm 자료가 있다. 특정 Unity 환경에서 Vulkan marker를 표시하지 못했다는 경험을 모든 버전에서 라벨이나 그래프를 지원하지 않는다는 제품 설명으로 넓히지 않는다. 여기서는 특정 확장의 지원 여부를 새로 보증하지 않는다.
카운터 감소가 프레임 개선을 보장하지 않는다
깊이 prepass를 켜면 일부 fragment 작업을 줄이면서 draw·geometry·메모리 비용을 늘릴 수 있다. 하나의 카운터 감소만으로 전체 프레임의 이득을 결론내리지 않는다. 프레임 시간 분포, 자원별 병목과 추가된 패스 비용을 함께 비교한다.
| 고정할 조건 | 함께 기록할 값 |
|---|---|
| 장면·카메라·해상도·품질 | 실제 처리 프레임과 비교 구간 |
| 빌드·드라이버·도구 버전 | 캡처·계측 여부 |
| 전원·온도 시작 조건 | 클록 변화·열 제한·반복 편차 |
| 비교할 기능 하나 | 프레임 시간과 관련 자원 카운터 |
이 표는 독립적으로 구성한 실험 계획이다. 이 글에서 스마트폰 실측을 수행한 것은 아니며 원문의 특정 시간·사용률 쌍을 보편적 성능 개선으로 재사용하지 않는다.
기종과 GPU 세대의 경계를 남긴다
타일 기반 렌더링이라는 공통점만으로 Job Manager 계열과 CSF 계열의 작업 제출·동기화 설명을 섞지 않는다. 카운터 이름이 비슷하더라도 파이프라인 단계와 집계 범위를 확인한다. 결론은 관측한 장치와 설정에 한정하고 다른 장치로의 적용은 별도 검증으로 남긴다.