제1부 GPU 아키텍처
1.4 SM 내부 I — 처리블록·레지스터 파일
버전·사양 주의: 이 장의 구체 수치(코어 수, 레지스터 파일 크기, 워프 스케줄러 개수, 공유 메모리 용량)는 GPU 세대마다 다르며 "시점 의존, 확인 필요"다. 정확한 값은 대상 GPU의 Compute Capability와 세대 백서·
deviceQuery로 확인하라. 본문은 동작 원리와 "왜 그렇게 설계됐는가"에 집중한다.
1.4.1 이 장에서 배우는 것 / 선수 지식
1.3에서 칩 상위 구조(GPC→TPC→SM 계층)를 봤다. 이 장은 그 최하단 실행 단위인 SM(Streaming Multiprocessor) 내부를 해부한다 — 특히 SM의 물리 구조와, 동시 상주 워프 수를 좌우하는 레지스터 파일. 워프 스케줄링의 동작은 1.5, 점유율 수계산은 1.6로 이어진다.
배우는 것:
- SM이 처리 블록(processing block, 서브파티션) 으로 나뉘는 구조와 각 블록의 구성요소.
- 레지스터 파일이 점유율을 좌우하는 원리: 스레드당 레지스터 수 → 동시 상주 워프 수(레지스터 압박).
- 워프 문맥 전환이 0사이클인 물리적 이유.
- CUDA 코어(FP32/INT 데이터패스)의 세대별 차이.
선수 지식: 1.2(SIMT·워프·지연 은닉), 1.3(SM 계층·코어 수의 의미). 메모리 계층의 상세(레지스터·공유·L1의 물리 구조, 뱅크·병합)는 1.7~1.8, HBM·대역폭은 1.9에서 다룬다 — 이 장은 SM 관점 개요만.
1.4.2 SM은 왜 이렇게 생겼나 — 처리량 기계의 내부
1.1~1.2의 큰 그림: GPU는 지연을 줄이는 대신 처리량을 키우는 기계다. CPU는 한 스레드의 메모리 지연을 거대 캐시·OoO로 숨기지만, GPU는 수많은 워프를 동시에 상주시켜 두고, 한 워프가 메모리를 기다리는 동안 다른 워프를 실행해 지연을 은닉한다. SM은 이 "지연 은닉 기계"의 단위다.
이 전략이 SM 내부 구조를 결정한다:
- 많은 워프를 상주시키려면 → 거대한 레지스터 파일(워프마다 자기 레지스터 전체를 가지고 있어야 문맥 전환이 0사이클이다).
- 매 사이클 일을 시키려면 → 다수의 워프 스케줄러가 각자 준비된 워프를 골라 발행(1.5).
- 산술 처리량을 키우려면 → 많은 연산 유닛(FP32/INT CUDA 코어, 텐서코어, SFU).
- 협력과 재사용을 위해 → 온칩 공유 메모리/L1(1.7).
여기서 핵심 긴장이 나온다. 지연 은닉용 워프가 많으려면 동시 상주 워프가 많아야 한다. 그런데 상주 워프 수는 SM의 자원(레지스터·공유 메모리)을 워프들이 나눠 갖는 방식으로 정해진다. 한 워프가 자원을 많이 쓰면 동시에 둘 워프가 적어진다. 이 트레이드오프가 점유율이며, 그 정량 계산은 1.6다. 이 장은 그 물리적 토대(레지스터 파일)를 세운다.
1.4.3 SM 내부 해부
현대 엔비디아 SM은 보통 4개의 처리 블록(processing block = 서브파티션) 으로 나뉜다. 각 블록은 자기 워프 스케줄러·디스패치 유닛·레지스터 파일·연산 유닛 일부를 가진다. 공유 메모리/L1·텐서코어 배치 등 일부는 SM 전체가 공유하거나 블록별로 둔다(세대마다 다름).
각 구성요소의 역할:
| 구성요소 | 역할 | 비고(상세) |
|---|---|---|
| Warp Scheduler | 매 사이클 상주 워프 중 "준비된" 워프를 골라 명령 발행. 처리 블록당 1개. | 1.5 |
| Dispatch Unit | 스케줄러가 고른 명령을 연산 유닛으로 내보냄. 블록당 1~2개(dual-issue). | 1.5 |
| Register File | 상주 워프들의 레지스터를 모두 담는 SRAM. 0사이클 문맥 전환의 이유. | 1.4.4 |
| FP32 / INT32 cores | 32-bit 부동소수·정수 산술. 세대에 따라 분리/겸용 데이터패스. | 1.4.5 |
| Tensor Core | 행렬 곱-누산(MMA) 가속. 딥러닝 처리량의 본체. | 상세 1.11 |
| SFU | 초월함수(sin·cos·exp·rsqrt) 근사. 처리량이 FP32보다 낮음. | 1.5 |
| LD/ST Units | 메모리 로드·스토어 주소 계산·발행. | 1.5 |
| Shared Memory / L1 | 온칩 저지연 메모리. 블록 내 협력·재사용. | 상세 1.7 |
정직성: 위 "처리 블록 4개", "블록당 워프 스케줄러 1개"는 최근 여러 세대(Volta 이후)의 일반형이다. 블록당 FP32/INT/텐서코어 개수, FP64 비율, 디스패치 유닛 수, 레지스터 파일 정확한 크기, 공유 메모리 용량은 세대마다 다르다. 정확한 수는 1.3(상위 구조)·4.2/4.4(세대 심화)·공식 백서를 따른다.
1.4.4 레지스터 파일과 점유율의 연결 고리
여기가 이 장의 핵심이다. SM이 동시에 상주시킬 수 있는 워프 수는 레지스터 파일을 워프들이 나눠 갖는 방식으로 정해진다.
레지스터 파일은 SM(또는 처리 블록)당 고정된 크기의 SRAM이다. 흔히 SM당 65,536개의 32-bit 레지스터(= 처리 블록 4개 × 16,384개)로 표현된다 — 정확한 수는 Compute Capability별로 다르니 확인하라. 커널의 각 스레드는 컴파일 시점에 정해진 수의 레지스터를 쓴다(nvcc가 결정, --ptxas-options=-v로 확인). 워프는 32 스레드이므로 워프당 레지스터 = 스레드당 레지스터 × 32(보통 할당 단위로 반올림).
레지스터 파일이 워프 수를 줄이는 원리 (SM당 65,536 레지스터 가정):
| 스레드당 레지스터 | 워프당 레지스터 (× 32) | 동시 상주 워프 한도 (65,536 ÷ 워프당) |
|---|---|---|
| 32 | 1,024 | 64 워프 |
| 64 | 2,048 | 32 워프 (절반) |
| 128 | 4,096 | 16 워프 |
스레드당 레지스터가 늘수록 동시 워프가 반비례로 준다. 이것이 레지스터 압박(register pressure) 이다. 복잡한 커널(언롤·인라인·많은 임시 변수)일수록 레지스터를 많이 먹고, 그만큼 점유율이 낮아진다(정량 계산은 1.6).
물리적으로, 워프 문맥 전환이 0사이클인 이유가 여기 있다: 모든 상주 워프의 레지스터가 이미 레지스터 파일에 전량 들어가 있어 저장·복원이 필요 없다. CPU의 스레드 전환(레지스터 스필·복원)과 근본적으로 다르다. 대가는 "레지스터 파일에 다 안 들어가면 그 워프는 애초에 상주시킬 수 없다"는 것 — 즉 점유율 상한이 된다.
1.4.5 CUDA 코어 — FP32 / INT 데이터패스
처리 블록의 산술 일꾼이 CUDA 코어다. 한 워프(32 스레드)의 FP32 명령은 블록의 FP32 레인들로 SIMT 발행된다. 블록의 FP32 레인 수가 32보다 적으면 한 워프 명령이 여러 사이클에 걸쳐 발행된다(throughput 관점). 세대별 주요 차이:
- FP32 vs INT 데이터패스 분리 여부: 일부 세대(Volta·Turing 계열)는 INT32를 별도 데이터패스로 두어 FP32 산술과 정수 주소 계산을 동시 진행. 이후 세대에서 일부 INT 경로가 FP32 데이터패스와 통합되어 FP32 처리량이 늘기도 했다(세대마다 다름, 백서 확인).
- FP64 비율: 데이터센터 GPU(과학계산용)는 FP64 처리량이 높고, 게이밍·추론용은 FP64가 매우 제한적(FP32의 1/32 등). FP64 의존 커널은 대상 GPU의 FP64:FP32 비율을 반드시 확인.
상세한 정밀도 포맷(TF32·FP16·BF16·FP8·INT8·FP4)과 혼합정밀도는 1.13, 행렬 가속의 텐서코어는 1.11에서 다룬다. 이 절은 "스칼라 산술 일꾼"으로서의 CUDA 코어만 짚는다.
1.4.6 중간 점검 (체크포인트)
여기까지 이해했다면 다음을 할 수 있어야 한다.
- [ ] SM 내부를 그림으로 그린다 — 처리 블록 4개, 각 블록의 워프 스케줄러·디스패치·레지스터 파일·CUDA 코어·텐서코어·SFU·LD/ST, SM 공통의 공유 메모리/L1.
- [ ] 스레드당 레지스터 수가 동시 상주 워프 수를 어떻게 줄이는지 산수로 보인다(예: 32→64 reg에서 상주 워프 반감).
- [ ] 워프 문맥 전환이 0사이클인 물리적 이유(모든 워프 레지스터가 레지스터 파일에 상주)를 설명한다.
- [ ] FP32/INT 데이터패스 분리·FP64 비율이 세대마다 다름을 안다.
점검: 어떤 커널이 복잡해져 스레드당 레지스터가 64로 늘었다 — 동시 상주 워프는 어떻게 되나? (방향: 반비례로 줄어 점유율이 낮아진다. 정량은 1.6.)
1.4.7 흔한 함정
- 레지스터를 "무비용"으로 여김. 임시 변수·공격적 언롤은 레지스터를 늘려 점유율을 낮춘다.
--ptxas-options=-v로 스레드당 레지스터를 확인하라(1.6). - 레지스터 파일 크기를 세대 불문 상수로 가정. SM당 레지스터 수·최대 워프 수는 CC별로 다르다. 대상 GPU로 확인.
- 0사이클 문맥 전환을 "무한 워프 가능"으로 오해. 레지스터 파일·공유 메모리·워프 슬롯 한도 안에서만 상주한다. 그 한도가 점유율 상한(1.6).
- FP64 처리량을 FP32와 같다고 가정. 추론·게이밍 GPU는 FP64가 매우 제한적. 과학계산은 FP64:FP32 비율 확인.
1.4.8 연습문제
연습 1 (레지스터 압박). SM당 65,536 레지스터, 블록당 256 스레드인 커널이 스레드당 40 reg를 쓴다. 레지스터만 고려할 때 동시 상주 가능한 블록 수와 워프 수는?
정답
블록당 레지스터 = 40 × 256 = 10,240. 상주 블록 = 65,536 / 10,240 = 6(내림). 블록당 워프 = 256/32 = 8. 상주 워프 = 6 × 8 = 48(레지스터 한도만 고려). 다른 한도(공유 메모리·워프 슬롯)와의 최솟값이 실제 점유율 — 1.6.
연습 2 (0사이클 전환). "GPU 워프 전환이 CPU 스레드 전환보다 저비용인 이유"를 레지스터 파일 관점에서 한 문장으로.
정답
모든 상주 워프의 레지스터가 거대한 레지스터 파일에 전량 상주해 있어 저장·복원이 필요 없다(고르기만 함). CPU는 레지스터를 스필·복원해야 해 비용이 크다.
연습 3 (구조 재현). 백지에 SM 내부를 그려라 — 처리 블록 4개와 각 구성요소, SM 공통 자원. 무엇이 블록별이고 무엇이 SM 공통인지 표시하라.
해설
블록별: 워프 스케줄러·디스패치·레지스터 파일·CUDA 코어·SFU·LD/ST(·텐서코어, 세대별). SM 공통: L1 명령 캐시·공유 메모리/L1 데이터 캐시(·일부 텍스처). 1.4.3 그림과 대조.
1.4.9 요약 · 다음 장
- SM은 보통 4개 처리 블록으로 나뉘고, 각 블록은 워프 스케줄러·디스패치·레지스터 파일·CUDA 코어(FP32/INT)·텐서코어·SFU·LD/ST를 가지며, 공유 메모리/L1은 SM이 공유한다.
- 동시 상주 워프 수는 레지스터 파일을 나눠 갖는 방식이 정한다. 스레드당 레지스터가 늘면 상주 워프가 반비례로 준다(레지스터 압박).
- 워프 문맥 전환이 0사이클인 이유는 모든 워프 레지스터가 레지스터 파일에 상주하기 때문 — 대가는 점유율 상한.
다음 장: 1.5 SM 내부 II — 워프 스케줄링·지연은닉·dual-issue. 처리 블록의 스케줄러가 매 사이클 어떻게 준비된 워프를 골라 발행하는지, stall 사유와 dual-issue, LD/ST·SFU 파이프를 본다.