Tiny Dispatch에서 PM4가 얼마나 늘어나는지 직관적으로 보기

2026-04-18

작은 커널을 매우 자주 dispatch할 때, “PM4가 도대체 얼마나 많이 생기나?“를 직관적으로 보는 노트.

한 줄 핵심

dispatch 1회 = PM4 1개가 아니라, 보통 여러 패킷 묶음이다. 그래서 tiny dispatch를 많이 하면 계산보다 “명령 포장/제출” 비용이 먼저 커질 수 있다.

직관 애니메이션

Step 0 / 7

시작 PM4 제출 흐름 시뮬레이터
"다음 단계" 버튼으로 vkQueueSubmit → PM4 → Ring Buffer → GPU 실행까지 따라가 보세요.

① Application Layer

API call

대기 중

→

Submit Info

② Driver Layer — PM4 Packet 생성

Packet 1

Packet 2

IT_SET_SH_REG — 셰이더 레지스터 설정

[31:30]Type= 3 (Type-3 packet)

[29:16]Count= N (payload 워드 수)

[15: 8]Opcode= 0x76 (SET_SH_REG)

payload: descriptor set 주소, push constant 값 등 커널 인자 → GPU 레지스터로

IT_DISPATCH_DIRECT — Compute Shader 실행

[31:30]Type= 3 (Type-3 packet)

[29:16]Count= 3

[15: 8]Opcode= 0x15 (DISPATCH_DIRECT)

payload[0]DIM_X= group count X

payload[1]DIM_Y= group count Y

payload[2]DIM_Z= group count Z

③ Ring Buffer — GPU 커맨드 스트림

WPTR = 드라이버가 쓰는 위치 | RPTR = GPU가 읽는 위치

④ GPU — Command Processor & Shader Engine

Command Processor

idle

→

Shader Engine

idle

빠른 감각표 (아주 거친 추정)

아래 수치는 구현/드라이버/상태변경량에 따라 크게 달라질 수 있다. 목표는 “정확한 카운트"가 아니라 “증가 방향"을 잡는 것.

패턴	dispatch 수	dispatch당 PM4 감각	총 PM4 감각
큰 커널 드물게	10	수~수십	수십~수백
중간 커널 반복	1,000	수~수십	수천~수만
tiny kernel 과다	10,000	수~수십(상태변경 크면 증가)	수만~수십만

왜 dispatch 1번에 여러 패킷이 생기나

보통 한 번의 dispatch에도 아래가 따라온다.

실행 상태 설정(파이프라인/리소스)
필요한 동기화/캐시 관련 제어
실제 dispatch 트리거 패킷

즉, dispatch는 “하나의 호출"이지만, 하부 커맨드 스트림에서는 “여러 패킷 시퀀스"로 전개된다.

실전에서 제일 먼저 보는 지표

dispatch 횟수(프레임/초당)
command buffer 재사용 여부
매 dispatch마다 바뀌는 상태량(바인딩 churn)

감각 식

총 PM4 트래픽 ~ dispatch 횟수 × (기본 패킷 묶음 + 상태변경 추가 패킷)

tiny dispatch 병목을 줄이는 기본 3개

배치화: 가능한 dispatch를 묶어서 submit 횟수 줄이기
재사용: command buffer/pipeline/layout 재생성 최소화
상태 churn 축소: 불필요한 descriptor/pipeline 변경 줄이기

체크리스트

내 워크로드는 dispatch를 몇 번/프레임 호출하는가?
dispatch당 상태변경이 큰가(바인딩/동기화 과다)?
재사용 가능한 명령 기록을 매번 새로 만들고 있지 않은가?
“커널 계산 시간"보다 “제출 오버헤드"가 더 큰 구간이 있는가?

jayinlab