GPU 하드웨어 아키텍처 및 작동 메커니즘에 대한 심층적인 이해
🌐 원문 링크: 深入GPU硬件架构及运行机制 (cnblogs.com/timlly)
📅 원문 발행일: 2019-09-06 | ✍️ 저자: Timlly (00 / )💡 시리즈 분류:
Hardware & Architecture| 국내 업계 표준 용어 감수 및 수식/도해 복원 적용 완료
대부분의 그래픽 렌더링 개발자에게 GPU는 익숙하면서도 생소한 구성 요소입니다. 익숙한 것은 그들이 매일 그것을 처리해야 한다는 것입니다. 낯설은 점은 GPU가 블랙박스와 같다는 점이다. 그들은 작동 메커니즘은 물론이고 내부 하드웨어 아키텍처도 모릅니다.
이 기사에서는 NVIDIA를 주요 라인으로 삼아 GPU의 하드웨어 아키텍처와 작동 메커니즘을 포괄적이고 심층적으로 분석하려고 합니다. 주로 PC 데스크톱 수준 GPU가 포함되며 모바일, 전문 컴퓨팅 및 그래픽 워크스테이션 수준 GPU는 포함되지 않습니다.
이 기사를 읽으려면 독자는 그래픽에 대한 특정 기초를 갖추고 GPU 렌더링 파이프라인을 이해해야 합니다. HLSL 및 GLSL과 같은 셰이더 코드를 작성하는 것이 가장 좋습니다.
1.1 왜 GPU를 이해해야 할까요?
저자는 GPU 하드웨어 아키텍처와 작동 메커니즘을 이해하면 많은 이점이 있다고 믿습니다. 다음은 요약되어 있습니다:
GPU의 물리적 구조와 작동 메커니즘을 이해하고, GPU가 블랙박스에서 화이트박스로 변화하는 과정을 이해합니다.
렌더링 병목 현상을 찾고 효율적인 셰이더 코드를 작성하는 것이 더 쉽습니다.
시대의 흐름에 발맞춰 최첨단 렌더링 기술을 이해해보세요!
스킬은 많지만 부담감은 크지 않아요!
1.2 콘텐츠 포인트
이 글의 주요 내용을 요약하면 다음과 같습니다.
GPU 소개, 역사, 기능.
GPU 하드웨어 아키텍처.
-GPU와 CPU의 조정된 스케줄링 메커니즘.
GPU 캐시 구조.
GPU 렌더링 파이프라인.
GPU 작동 메커니즘.
GPU 최적화 팁.
1.3 질문과 함께 읽기
적절한 질문이 포함된 기술 기사를 읽으면 일반적으로 이해와 기억이 깊어질 수 있습니다. 다음 질문으로 이 기사를 읽을 수 있습니다.
GPU는 CPU와 어떻게 협력합니까?
GPU에도 캐싱 메커니즘이 있나요? 몇 층이 있나요? 속도는 얼마나 다른가요?
GPU 렌더링 프로세스의 단계는 무엇입니까? 그들의 기능은 무엇입니까?
Early-Z 기술이란 무엇입니까? 어느 단계에서 발생하나요? 이 단계에서는 또 어떤 일이 발생합니까? 어떤 문제가 발생할 수 있나요? 어떻게 해결하나요?
SIMD와 SIMT란 무엇인가요? 그들의 이점은 무엇입니까? 공동 발행은 어떻습니까?
GPU는 병렬로 처리되나요? 그렇다면 하드웨어 계층은 어떻게 설계되고 구현됩니까?
GPC, TPC, SM은 무엇인가요? 워프란 무엇입니까? Core와 Thread는 어떤 관계인가요?
버텍스 셰이더(VS)와 픽셀 셰이더(PS)가 동일한 처리 단위가 될 수 있나요? 왜?
픽셀쉐이더(PS)의 최소 처리단위는 1픽셀인가요? 왜? 어떤 영향을 미칠까요?
Shader의 if, for 및 기타 문이 렌더링 효율성을 저하시키나요? 왜?
아래 그림과 같이 같은 면적의 도형을 렌더링할 때 삼각형의 개수가 적은 도형(왼쪽)과 삼각형의 개수가 많은 도형(오른쪽)을 렌더링하는 것이 더 빠른가요? 왜?

GPU 컨텍스트란 무엇입니까? 그것은 무엇을 합니까?
렌더링 병목 현상을 일으키는 문제는 무엇입니까? 이를 피하거나 최적화하는 방법은 무엇입니까?
이 기사를 읽은 후 위의 모든 질문에 매우 명확하게 답할 수 있다면 이 기사의 본질을 파악한 것을 축하합니다!
2. GPU 개요
2.1 GPU란 무엇입니까?
GPU의 전체 이름은 그래픽 처리 장치, 그래픽 처리 장치입니다. 그 기능은 원래 이미지 그리기 및 메타데이터 처리 전용 칩인 이름과 일치했습니다. 나중에 다른 많은 기능이 점차 추가되었습니다.

NVIDIA GPU 칩의 실제 사진.
GPU와 그래픽 카드에 대해 매일 논의할 때 종종 혼란스러워집니다. 엄밀히 말하면 그들은 다릅니다. GPU는 그래픽카드(비디오카드, 디스플레이카드, 그래픽카드)의 핵심 부품이지만 그래픽카드에는 GPU 외에도 팬히터, 통신부품, 마더보드와 모니터에 연결되는 각종 슬롯 등이 있다.
PC 데스크탑의 경우 GPU를 생산하는 두 개의 주요 제조업체가 있습니다.
- NVIDIA: NVIDIA는 오늘날 최고의 그래픽 렌더링 기술 리더이자 선도적인 GPU 제조업체입니다. 엔비디아의 제품은 흔히 N카드로 알려져 있으며 대표적인 제품으로는 지포스 시리즈, GTX 시리즈, RTX 시리즈 등이 있습니다.

- AMD: CPU 제조업체이자 GPU 제조업체입니다. 그래픽 카드는 일반적으로 A 카드로 알려져 있습니다. 대표적인 제품으로는 Radeon 시리즈가 있습니다.

물론 NVIDIA와 AMD도 모바일 및 그래픽 워크스테이션 유형의 GPU를 생산합니다. 또한 모바일 그래픽 카드를 생산하는 제조업체에는 ARM, Imagination Technology, Qualcomm 및 기타 회사가 포함됩니다.
2.2 GPU 기록
1990년대 GPU가 등장한 이후 20년 이상의 개발 끝에 단순한 그래픽 렌더링을 넘어 수학적 계산, 물리적 시뮬레이션, AI 연산 등의 기능까지 포함하는 발전을 이루었습니다.
2.2.1 NV GPU 개발 이력
다음은 GPU 개발 노드 테이블입니다.
- 1995 – NV1

NV1 렌더링 및 기능.
1997 – 리바 128(NV3), DX3
1998 – 리바 TNT(NV4), DX5
32비트 컬러, 24비트 Z 버퍼, 8비트 스텐실 버퍼
듀얼 텍스처, 이중선형 필터링
클록당 2픽셀(2ppc)
1999 - 지포스 256(NV10)
고정 파이프라인, DirectX 7.0 지원
하드웨어 T&L(변환 및 조명, 좌표 변환 및 조명)
큐브맵
DOT3 – 범프 매핑
2x 이방성 필터링
삼선형 필터링
DXT 텍스처 압축
4ppc
"GPU" 용어 소개

NV10 렌더링 및 기능.
- 2001-지포스 3
다이렉트X 8.0
셰이더 모델 1.0
프로그래밍 가능한 렌더링 파이프라인
버텍스 셰이더
픽셀 셰이더
3D 텍스처
하드웨어 섀도우 맵
8x 이방성 필터링
멀티 샘플링 앤티앨리어싱(MSAA)
4ppc

NV20 렌더링 및 기능.
- 2003 - GeForce FX 시리즈(NV3x)
다이렉트X 9.0
- 셰이더 모델 2.0
256개의 버텍스 연산 명령어
32개의 텍스처 + 64개의 산술 픽셀 연산 명령
셰이더 모델 2.0a
256개의 버텍스 연산 명령어
512픽셀 작동 지침
음영 언어
HLSL
-CGSL
-GLSL

NV30 렌더링 및 기능.
- 2004 - GeForce 6 시리즈(NV4x)
다이렉트X 9.0c
셰이더 모델 3.0
동적 흐름 제어
분기, 루프, 명령문 등
버텍스 텍스처 읽기
높은 동적 범위(HDR)
64비트 렌더 텍스처(렌더 대상)
- FP16*4 텍스처 필터링 및 블렌딩

NV40 렌더링 및 기능.
- 2006 - GeForce 8 시리즈(G8x)
다이렉트X 10.0
- 셰이더 모델 4.0
기하학 셰이더
캡 비트 없음
통합 셰이더
Vista 시스템용 새 드라이버
GPU 컴퓨팅 기반 CUDA 등장
GPU 컴퓨팅 성능은 GFLOPS로 측정됩니다.

NV G80 렌더링 및 특징.
- 2010 - 지포스 405(GF119)
다이렉트X 11.0
테셀레이션
헐 셰이더
테셀레이터
도메인 셰이더
컴퓨팅 셰이더
스트림 출력 지원

DirectX 11 렌더링 파이프라인.
멀티스레딩 지원
향상된 텍스처 압축
셰이더 모델 5.0
추가 명령어, 메모리 위치, 레지스터
객체지향 쉐이딩 언어
테셀레이션
컴퓨팅 셰이더
2014 - GeForceGT 710(GK208)
다이렉트X 12.0
경량 드라이버 레이어
하드웨어 수준의 멀티스레드 렌더링 지원
더 나은 하드웨어 리소스 관리
2016 - GeForceGTX 1060 6GB
최초로 RTX 및 DXR 기술 지원, 즉 레이 트레이싱 지원
- RT Core(레이 트레이싱 코어) 도입

RTX 레이 트레이싱을 지원하는 그래픽 카드 목록입니다.
- 2018 - 타이탄 RTX(TU102)
다이렉트X 12.1, OpenGL 4.5
6GPC, 36TPC, 72SM, 72RT 코어,...
8K,1770MHz,24G,384대역폭(Bandwidth)

위에서 볼 수 있듯이 GPU 하드웨어는 그래픽 API 표준 및 게임과 함께 발전하며, 서로 보완하고 촉진하는 선한 관계를 형성합니다.
2.2.2 NV GPU 아키텍처 개발 내역
우리 모두 알고 있듯이 CPU의 발전은 무어의 법칙(18개월마다 속도가 두 배로 빨라진다)과 일치합니다.

프로세싱 칩의 트랜지스터 수는 무어의 법칙을 따릅니다. 오른쪽은 인텔의 창립자인 무어 자신입니다.
NVIDIA 창립자 Jensen Huang은 수년 전에 GPU의 속도와 기능이 무어의 법칙을 능가하고 6개월마다 두 배로 향상될 것이라고 맹세했습니다. NV의 GPU 개발 역사는 그가 해냈다는 것을 증명합니다! GPU의 속도 향상 속도는 CPU의 속도를 훨씬 능가합니다.

NVIDIA GPU 아키텍처는 원래 Tesla에서 최신 Turing 아키텍처에 이르기까지 많은 변화를 겪었습니다. 개발 내역은 다음과 같은 시점으로 나눌 수 있습니다.
- 2008년-테슬라
Tesla는 원래 컴퓨팅 처리 장치에 사용되었으며 초기 CUDA 시리즈 그래픽 칩에 사용되었습니다. 이것은 정말 일반적인 그래픽 처리 칩이 아닙니다.
- 2010-페르미
Fermi는 최초의 완전한 GPU 컴퓨팅 아키텍처입니다. 공유 스토리지와 결합된 순수 캐시 수준을 지원하는 최초의 GPU 아키텍처와 ECC를 지원하는 GPU 아키텍처입니다.
- 2012-케플러
Kepler는 Fermi보다 빠르고 효율적이며 성능도 더 좋습니다.
- 2014-맥스웰
새로운 VXGI(복셀 글로벌 일루미네이션) 기술을 통해 게이밍 GPU는 최초로 실시간 동적 글로벌 일루미네이션 효과를 제공할 수 있습니다. Maxwell 아키텍처를 기반으로 하는 GTX 980 및 970 GPU는 MFAA(Multi-Frame Sample Anti-Aliasing), DSR(Dynamic Super Resolution), VR Direct 및 초전력 효율 설계를 포함한 다양한 신기술을 갖추고 있습니다.
- 2016-파스칼
Pascal 아키텍처는 프로세서와 데이터를 동일한 패키지에 통합하여 계산 효율성을 높입니다. 1080 시리즈와 1060 시리즈는 Pascal 아키텍처를 기반으로 합니다.
- 2017-볼타
640개의 Tensor 코어를 탑재한 Volta는 100테라플롭 이상의 초당 딥러닝 성능(TFLOPS)을 제공할 수 있으며 이는 이전 세대 Pascal 아키텍처보다 5배 이상 빠릅니다.
- 2018-튜링
Turing 아키텍처는 3D 환경을 통해 초당 최대 10기가 광선의 속도로 빛과 소리의 전파 계산을 가속화하는 RT Core라는 전용 레이 트레이싱 프로세서를 갖추고 있습니다. Turing 아키텍처는 이전 세대 NVIDIA Pascal™ 아키텍처보다 최대 25배까지 실시간 레이 트레이싱 작업을 가속화하고 CPU보다 30배 이상 빠르게 영화 최종 프레임을 렌더링할 수 있습니다. 2060 시리즈와 2080 시리즈 그래픽 카드도 Volta를 건너뛰고 Turing 아키텍처를 직접 선택했습니다.
다음 그림은 일부 GPU 아키텍처의 개발 내역을 보여줍니다.

2.3 GPU 기능
그래픽을 그리는 것 외에도 최신 GPU는 많은 추가 기능을 수행합니다. 종합하면 다음과 같습니다.
- 그래픽 드로잉.
이는 GPU의 가장 전통적인 특장점이자 가장 기본적이고 핵심적인 기능이기도 합니다. 대부분의 PC 데스크톱, 모바일 장치 및 그래픽 워크스테이션에 그래픽 처리 및 그리기 기능을 제공합니다.
- 물리 시뮬레이션.
GPU 하드웨어와 통합된 물리 엔진(PhysX, Havok)은 게임, 영화, 교육, 과학 시뮬레이션 및 기타 분야에 대해 수백 또는 수천 배 성능의 물리적 시뮬레이션을 제공하여 이전에 장기적인 계산이 필요했던 물리적 시뮬레이션을 실시간으로 제시할 수 있습니다.
- 대규모 컴퓨팅.
컴퓨팅 셰이더와 스트림 출력의 출현으로 병렬 컴퓨팅에 대한 다양한 대규모 요구 사항이 실현되었습니다. CUDA가 가장 좋은 예입니다.
- AI 계산.
최근 몇 년 동안 인공 지능의 부상으로 AI 코어 컴퓨팅 장치의 GPU 통합이 촉진되었으며, 이는 AI 컴퓨팅 기능의 향상을 피드백하고 각계각층의 컴퓨팅 기능 향상을 가져왔습니다.
- 기타 계산.
오디오 및 비디오 인코딩 및 디코딩, 암호화 및 암호 해독, 과학적 컴퓨팅, 오프라인 렌더링 등은 모두 최신 GPU의 병렬 컴퓨팅 기능 및 대규모 처리량 기능과 분리될 수 없습니다.
3. GPU 물리적 아키텍처
3.1 GPU 거시물리적 구조
나노 기술의 도입으로 GPU는 수억 개의 트랜지스터와 전자 장치를 작은 칩에 통합할 수 있습니다. 거시적 물리적 구조 관점에서 볼 때 대부분의 최신 데스크탑 GPU는 동전 몇 개와 크기가 동일하며 일부는 동전보다 더 작습니다(아래 그림).

Qualcomm Snapdragon 853 디스플레이 칩은 동전보다 작습니다
GPU가 냉각 팬, PCI 슬롯, HDMI 인터페이스 및 기타 구성 요소와 결합되면 그래픽 카드를 형성합니다(아래 그림).

그래픽 카드는 독립적으로 작동할 수 없으며 마더보드에 탑재되고 CPU, 메모리, 비디오 메모리, 모니터 등의 하드웨어 장치와 결합되어 완전한 PC를 구성해야 합니다.

그래픽 카드가 장착된 마더보드.
3.2 GPU 미세물리적 구조
GPU의 미세 구조는 제조업체와 아키텍처에 따라 다르지만 핵심 구성 요소, 개념 및 작동 메커니즘은 유사합니다. 다음은 일부 아키텍처의 GPU의 미세 물리적 구조를 보여줍니다.
3.2.1 NVidia Tesla 아키텍처

Tesla의 마이크로아키텍처 개요는 위에 나와 있습니다. 그 기능과 개념은 아래에 설명되어 있습니다.
7개의 TPC 그룹(텍스처/프로세서 클러스터, 텍스처 처리 클러스터)이 있습니다.
각 TPC에는 두 세트의 SM(스트림 다중 프로세서, 스트림 다중 프로세서)이 있습니다.
각 SM에는 다음이 포함됩니다.
SP 6개(스트리밍 프로세서, 스트림 프로세서)
2 SFU (Special Function Unit, 특수 기능 유닛)
L1 캐시, MT Issue(멀티스레드 명령어 획득), C-Cache(상시 캐시), 공유 메모리
TPC 코어 유닛 외에도 비디오 메모리, CPU, 시스템 메모리와 상호 작용하는 다양한 구성 요소가 있습니다.
3.2.2 NVidia 페르미 아키텍처

페르미 아키텍처는 위와 같으며, 그 특징은 다음과 같다.
16개의 SMS가 있습니다.
SM당:
워프 2개(실 묶음)
총 32개 코어 2세트
16개 그룹의 부하 저장 장치(LD/ST)
4개의 특수 기능 유닛(SFU)
각 워프:
16개 코어
워프 스케줄러
파견부대
각 코어:
1 FPU(부동 소수점 단위)
- ALU(논리연산장치) 1개
3.2.3 NVidia Maxwell 아키텍처

이는 4개의 GPC가 있고 각 GPC에는 4개의 SM이 있는 Maxwell의 GM204를 사용합니다. Tesla 아키텍처와 비교하여 처리 장치가 크게 개선되었습니다.
3.2.4 NVidia Kepler 아키텍처

하드웨어를 개선하고 더 많은 처리 장치를 보유하는 것 외에도 Kepler는 SM을 SMX로 업그레이드했습니다. SMX는 지연 시간을 줄이기 위해 렌더링 스레드(아래 그림)의 동적 생성을 지원하는 향상된 아키텍처입니다.

3.2.5 NVidia Turing 아키텍처

위 그림은 Turing 아키텍처를 사용하는 TU102 GPU를 보여줍니다. 그 특징은 다음과 같습니다:
6 GPC(그래픽 처리 클러스터)
36 TPC(텍스처 처리 클러스터)
72 SM(스트리밍 멀티프로세서)
각 GPC에는 6개의 TPC가 있고 각 TPC에는 2개의 SM이 있습니다.
4,608 CUDA 코어
RT 코어 72개
576 텐서 코어
288 텍스처 유닛
12x32비트 GDDR6 메모리 컨트롤러(총 384비트)
단일 SM의 구조 다이어그램은 다음과 같습니다.

각 SM에는 다음이 포함됩니다.
64개의 CUDA 코어
8개의 Tensor 코어
256KB 레지스터 파일
TU102 GPU 칩 물리적 그림:

3.3 GPU 아키텍처의 공통 기능
이전 섹션의 모든 GPU 아키텍처를 살펴보면 서로 다르지만 동일한 개념과 구성 요소가 많이 있음을 알 수 있습니다.
- GPC
-TPC
실
SM, SMX, SMM
워프
SP
코어
ALU
-FPU
- SFU
-ROP
-로드/저장 장치
L1 캐시
L2 캐시
기억
파일 등록
위의 각 구성 요소의 목적은 다음 장에서 자세히 설명됩니다.
GPU에는 왜 그렇게 많은 레이어와 유사한 부품이 있습니까? 그 대답은 GPU 작업이 자연스럽게 병렬화되고 최신 GPU 아키텍처가 높은 수준의 병렬성으로 설계된다는 것입니다.
4. GPU 작동 메커니즘
4.1 GPU 렌더링 개요
이전 장에서 볼 수 있듯이 현대 GPU는 유사한 구조를 가지고 있고 동일한 구성 요소가 많으며 작동 메커니즘 측면에서 공통점이 많습니다. 다음은 Fermi 아키텍처의 작동 메커니즘에 대한 개요입니다.

Fermi에서 시작하여 NVIDIA는 Giga Thread Engine을 사용하여 진행 중인 모든 작업을 관리하는 유사한 원칙 아키텍처를 사용합니다. GPU는 여러 개의 GPC(그래픽 처리 클러스터)로 구분됩니다. 각 GPC에는 여러 개의 SM(SMX, SMM)과 래스터 엔진(Raster Engine)이 있습니다. 그중에는 많은 연결이 있는데, 가장 주목할만한 것은 GPC와 기타 기능 모듈(예: ROP 또는 기타 하위 시스템)을 연결할 수 있는 Crossbar입니다.
프로그래머가 작성한 쉐이더는 SM에서 완성됩니다. 각 SM에는 스레드에 대한 수학 연산을 수행하는 다수의 코어가 포함되어 있습니다. 예를 들어 스레드는 버텍스 또는 픽셀 셰이더 호출일 수 있습니다. 이러한 코어 및 기타 장치는 32개 스레드 세트를 워프(스레드 워프)로 관리하고 실행할 명령을 디스패치 유닛에 전달하는 워프 스케줄러에 의해 구동됩니다.
이러한 장치 중 실제로 GPU에 있는 수(GPC당 SM 수, GPC 수...)는 칩 구성 자체에 따라 다릅니다. 예를 들어 GM204에는 4개의 GPC가 있고 각 GPC에는 4개의 SM이 있지만 Tegra X1에는 1개의 GPC와 2개의 SM이 있으며 둘 다 Maxwell 설계입니다. SM 설계 자체(코어 수, 명령 장치, 스케줄러...)도 시간이 지남에 따라 변경되었으며 칩을 매우 효율적으로 만들어 고급 데스크톱에서 랩톱 및 모바일로 확장할 수 있습니다.

위에 표시된 것처럼 일부 GPU(예: 일부 Fermi 모델)의 경우 단일 SM에는 다음이 포함됩니다.
컴퓨팅 코어 32개(코어, 스트림 프로세서라고도 함)
데이터 로드 및 저장을 위한 16개의 LD/ST(로드/저장) 모듈
4 SFU(특수 기능 장치)는 특수 수학 연산(sin, cos, log 등)을 수행합니다.
128KB 레지스터(등록 파일)
64KB L1 캐시
전역 메모리 캐시(Uniform Cache)
텍스처 판독 유닛
텍스처 캐시
PolyMorph 엔진: 다각형 엔진은 속성 조립(속성 설정), 버텍스 가져오기(VertexFetch), 표면 세분화 및 래스터라이제이션(이 모듈은 버텍스 관련 항목의 특수 처리를 이해할 수 있음)를 담당합니다.
2 워프 스케줄러: 이 모듈은 워프 스케줄링을 담당합니다. 워프는 32개의 스레드로 구성됩니다. 워프 스케줄러의 명령은 디스패치 유닛을 통해 실행을 위해 코어로 전송됩니다.
명령어 캐시
상호 연결 네트워크
4.2 GPU 로직 파이프라인
이전 섹션의 구성 요소와 개념을 이해한 후에는 GPU 렌더링 프로세스와 단계를 자세히 설명할 수 있습니다. 다음은 로직 파이프라인에 대한 자세한 설명을 제공하기 위해 Fermi 계열의 SM을 예로 들어 보겠습니다.

프로그램은 그래픽 API(DX, GL, WEBGL)를 통해 드로우콜 명령을 발행합니다. 명령이 드라이버에 푸시됩니다. 드라이버는 명령의 유효성을 확인한 다음 GPU가 읽을 수 있는 푸시버퍼에 명령을 넣습니다.
일정 시간이 지난 후 또는 플러시 명령을 명시적으로 호출한 후 드라이버는 푸시버퍼의 내용을 GPU로 보냅니다. GPU는 호스트 인터페이스(Host Interface)를 통해 이러한 명령을 받아들이고 프런트 엔드(Front End)를 통해 이러한 명령을 처리합니다.
Primitive Distributor에서 작업 배포를 시작하고, 인덱스 버퍼의 정점을 처리하여 삼각형을 생성하고, 이를 배치로 나눈 다음 여러 GPC로 보냅니다. 이 단계의 이해는 n개의 삼각형을 제출하고 동시 처리를 위해 이러한 PGC에 할당하는 것입니다.

GPC에서 각 SM의 Poly Morph 엔진은 그림의 Vertex Fetch 모듈인 삼각형 인덱스를 통해 삼각형 데이터(버텍스 데이터)를 가져오는 역할을 담당합니다.
데이터를 획득한 후 버텍스 데이터 처리를 시작하기 위해 SM에서 32개의 스레드 그룹이 예약됩니다. Warp는 단일 명령 다중 스레딩(SIMT, SIMD 단일 명령 다중 데이터의 업그레이드)의 일반적인 구현입니다. 즉, 32개의 스레드가 동시에 실행하는 명령은 정확히 동일하지만 스레드 데이터는 다릅니다. 이것의 장점은 워프가 명령어를 디코딩하고 실행하는 데 로직 세트만 필요하다는 것입니다. 칩을 더 작고 빠르게 만들 수 있습니다. 이는 GPU가 처리해야 하는 작업이 자연스럽게 병렬이기 때문에 가능합니다.
SM의 워프 스케줄러는 워프 전체에 순서대로 명령을 배포합니다. 단일 워프의 스레드는 잠금 단계에서 해당 명령을 실행합니다. 스레드가 실행이 활성화되지 않는 상황에 직면하면 스레드도 마스크 처리됩니다. 가려지는 이유는 다양합니다. 예를 들어, 현재 명령어는 if(true)의 분기인데 현재 스레드의 데이터 조건이 false이거나, 루프 수가 다르거나(예를 들어 for 루프 n의 수가 상수가 아니거나, break에 의해 일찍 종료되었지만 다른 일이 여전히 진행 중임) sh에서 ader의 분기는 시간 소모를 크게 증가시킵니다. 워프의 32개 스레드가 모두 if 또는 else로 이동하지 않는 한 이는 모든 분기를 통과하는 것과 같습니다. 스레드는 명령을 독립적으로 실행할 수 없지만 워프 단위로 실행할 수 있으며 이러한 워프는 독립적입니다.
워프의 지시 사항은 한 번만 완료할 수도 있고 여러 번 완료할 수도 있습니다. 예를 들어, 일반적으로 SM의 LD/ST(로드 액세스) 단위 수는 기본 수학 연산 단위보다 훨씬 적습니다.
일부 명령은 다른 명령, 특히 메모리 로드보다 완료하는 데 시간이 더 오래 걸리기 때문에 워프 스케줄러는 메모리 대기가 없는 다른 워프로 간단히 전환할 수 있습니다. 이는 GPU가 단순히 활성 스레드 그룹을 전환하여 메모리 읽기 대기 시간을 극복하는 방법의 핵심입니다. 이 전환을 매우 빠르게 수행하기 위해 스케줄러가 관리하는 모든 워프는 레지스터 파일에 자체 레지스터를 갖습니다. 여기에는 모순이 있을 것입니다. 셰이더에 필요한 레지스터가 많을수록 워프를 위해 남겨지는 공간이 줄어들고 생성되는 워프도 줄어듭니다. 이때 메모리 지연이 발생하면 기다리기만 하고 전환할 워프가 실행되지 않습니다.

- 워프가 버텍스 셰이더의 모든 명령을 완료하면 작업 결과는 뷰포트 변환 모듈에 의해 처리되고 삼각형은 잘려 래스터라이제이션를 위해 준비되며 GPU는 버텍스 셰이더와 픽셀 셰이더 간의 데이터 통신을 위해 L1 및 L2 캐시를 사용합니다.

- 다음으로, 이 삼각형은 분할되어 여러 GPC에 할당됩니다. 삼각형의 범위에 따라 할당될 래스터 엔진이 결정됩니다. 각 래스터 엔진은 화면의 여러 타일을 처리하며 이는 삼각형 렌더링을 여러 타일에 할당하는 것과 같습니다. 즉, 픽셀 단계는 삼각형으로 나누는 것에서 표시되는 픽셀로 나누는 것으로 변경됩니다.

SM의 속성 설정은 보간 후 픽셀 셰이드로 버텍스 셰이더의 데이터를 읽을 수 있도록 보장합니다.
GPC의 래스터 엔진은 수신된 삼각형에서 작동하며 이러한 삼각형의 픽셀 정보를 생성하는 역할을 합니다(클리핑, 뒷면 컬링 및 Early-Z 컬링도 처리).
32개의 픽셀 스레드는 그룹 또는 8개의 2x2 픽셀 블록으로 나뉩니다. 이것은 픽셀 셰이더의 가장 작은 작업 단위입니다. 이 픽셀 스레드 내에서 삼각형으로 덮이지 않으면 가려집니다. SM의 워프 스케줄러는 픽셀 셰이더의 작업을 관리합니다.
다음 단계는 버텍스 셰이더의 논리적 단계와 정확히 동일하지만 픽셀 셰이더 스레드에서 실행됩니다. 성능을 소모하지 않고 픽셀 내의 값을 얻을 수 있기 때문에 잠금 단계 실행이 매우 편리하며 모든 스레드는 모든 명령이 동일한 지점에 있을 수 있음을 보장할 수 있습니다.

- 마지막 단계로, 이제 픽셀 셰이더가 색상 및 깊이 값 계산을 완료했습니다. 이 시점에서 데이터를 ROP(렌더링 출력 단위, 렌더링 입력 단위)로 전달하기 전에 삼각형의 원래 API 순서를 고려해야 합니다. ROP 내부에는 많은 ROP 장치가 있습니다. 프레임 버퍼를 사용한 깊이 테스트 및 믹싱은 ROP 장치에서 처리됩니다. 깊이와 색상 설정은 원자적 작업이어야 합니다. 그렇지 않으면 동일한 픽셀에 있는 두 개의 서로 다른 삼각형 사이에 충돌과 오류가 발생합니다.
4.3 GPU 기술의 핵심 포인트
이전 섹션에서는 주로 GPU의 내부 워크플로우와 메커니즘을 설명했기 때문에 단순화를 위해 많은 지식과 프로세스를 생략했습니다. 이 섹션에서는 이에 대해 자세히 설명합니다.
4.3.1 SIMD 및 SIMT
SIMD(Single Instruction Multiple Data)는 단일 명령어 다중 데이터입니다. GPU의 ALU 유닛에서는 하나의 명령어로 다차원 벡터(보통 4D) 데이터를 처리할 수 있습니다. 예를 들어 다음과 같은 셰이더 지침이 있습니다.
float4 c = a + b; // a, b는 float4타입/유형SIMD가 없는 처리 장치의 경우 4개의 부동 소수점 값을 추가하려면 4개의 명령어가 필요합니다. 어셈블리 의사 코드는 다음과 같습니다.
ADD c.x, a.x, b.x
ADD c.y, a.y, b.y
ADD c.z, a.z, b.z
ADD c.w, a.w, b.w그러나 SIMD 기술을 사용하면 단 하나의 명령으로 처리할 수 있습니다.
SIMD_ADD c, a, b
SIMT(Single Instruction Multiple Threads)는 SIMD의 업그레이드 버전입니다. GPU의 단일 SM에 있는 여러 코어에 대해 동일한 명령을 동시에 처리할 수 있으며, 각 코어에서 액세스하는 데이터는 다를 수 있습니다.
SIMT_ADD c, a, b위의 명령은 단일 SM으로 그룹화된 모든 Core에 동시에 전송되고 작업은 동시에 수행되지만 a, b, c의 값은 다를 수 있습니다.

4.3.2 공동 발행
공동이슈는 SIMD 컴퓨팅 유닛을 충분히 활용하지 못하는 문제를 해결하기 위한 것입니다. 예를 들어 아래 그림에서는 부동 소수점 수의 차이로 인해 ALU 사용률이 100%에서 75%, 50%, 25%로 감소합니다.

셰이더에 의한 저차원 벡터 활용도가 낮은 문제를 해결하기 위해 1D와 3D 또는 2D와 2D 명령을 병합할 수 있습니다. 예를 들어 아래 그림에서 DP3 명령어는 3D 데이터를 사용하고 ADD 명령어는 1D 데이터만 사용합니다. 공동 발행은 자동으로 이를 병합하고 단 하나의 명령 주기로 동일한 ALU에서 실행될 수 있습니다.

그러나 Vector ALU의 경우 변수 중 하나가 피연산자이자 저장 번호인 경우 공동 발행 기술을 활성화할 수 없습니다.

그래서 모든 벡터를 효과적으로 결합하고 공동 발행 기술을 활성화하며 SIMD의 장점을 최대한 활용할 수 있는 Scalar Instruction Shader(Scalar Instruction Shader)가 탄생했습니다.
4.3.3 if - else 문

위 그림과 같이 SM에는 8개의 ALU(Core)가 있습니다. SIMD의 특성상 각 ALU의 데이터가 다르기 때문에 if-else 문이 일부 ALU에서는 true 분기(노란색)를 실행하고 일부 ALU에서는 false 분기(회색 파란색)를 실행합니다. 이로 인해 많은 ALU의 실행 주기가 낭비(마스크 아웃)되어 전체 실행 주기가 길어집니다. 최악의 경우, 동일한 SM의 활용률은 1/8에 불과합니다(8은 동일한 SM의 스레드 수이며, 서로 다른 아키텍처의 GPU가 다름).
마찬가지로 for 루프는 다음 셰이더 코드와 같은 유사한 상황으로 이어집니다.
void func(int count, int breakNum)
{
for(int i=0; i<count; ++i)
{
if (i == breakNum)
break;
else
// do something
}
}각 ALU의 개수가 다르고 브레이크 분기가 있기 때문에 가장 빠르게 셰이더 실행을 완료하는 ALU는 가장 느린 ALU의 1/N 시간이 걸릴 수 있습니다. 그러나 SIMD의 특성으로 인해 가장 빠른 ALU는 다음 명령 세트를 인계받기 전에 가장 느린 ALU의 실행이 완료될 때까지 기다려야 합니다. 많은 시간이 낭비됩니다.
4.3.4 초기-Z
초기 GPU의 렌더링 파이프라인의 깊이 테스트는 픽셀 셰이더 이후에 수행되었습니다(아래 그림). 이로 인해 보이지 않는 많은 픽셀이 성능을 소모하는 픽셀 셰이더 계산을 수행하게 됩니다.

이후에는 픽셀 셰이더의 추가 소모를 줄이기 위해 깊이 테스트를 픽셀 셰이더 앞으로 옮겼습니다(아래 그림). 이것이 Early-Z 기술의 유래입니다.

Early-Z 기술은 많은 유효하지 않은 픽셀을 미리 제거하여 시간이 많이 걸리는 픽셀 셰이더에 들어가는 것을 방지할 수 있습니다. Early-Z 제거의 최소 단위는 1픽셀이 아니라 픽셀 블록(픽셀 쿼드, 2x2 픽셀, 자세한 내용은 [4.3.6](#4.3.6 픽셀 쿼드) 참조)입니다.
그러나 다음 상황에서는 Early-Z가 실패할 수 있습니다.
알파 테스트 켜기: 알파 테스트는 픽셀 셰이더 이후 알파 테스트 단계에서 비교해야 하기 때문에 픽셀 셰이더 이전에는 픽셀 제거 여부를 결정할 수 없습니다.
Tex Kill 켜기: 셰이더 코드에 픽셀 폐기 지침이 있습니다(DX의 폐기, OpenGL의 클립).
심도 테스트를 끕니다. Early-Z는 깊이 테스트가 켜져 있는 조건을 기반으로 합니다. 심도 테스트가 꺼진 경우 Early-Z 기술을 활성화할 수 없습니다.
멀티 샘플링 켜기: 멀티 샘플링은 주변 픽셀에 영향을 미치며 Early-Z 단계에서는 주변 픽셀이 잘렸는지 알 수 없으므로 미리 제거할 수 없습니다.
후속 색상을 혼합해야 하는 기타 작업.
또한 Early-Z 기술은 깊이 데이터 위험(깊이 데이터 위험)이라는 문제를 일으킬 수 있습니다.

예제는 위의 그림을 기반으로 합니다. 수치적인 깊이 값 5는 Early-Z를 통과하여 프레임 버퍼에 곧 기록될 예정이며, 깊이 값 10은 Early-Z 단계에 있다고 가정합니다. 현재 캐시된 깊이 값 15를 읽고 비교합니다. 결과는 10이 Early-Z 테스트를 통과했으며 자신보다 작은 깊이 값 5를 덮어쓰게 된다는 것입니다. 결국, 프레임 버퍼의 깊이 값이 잘못된 결과입니다.
깊이 데이터 충돌을 피하는 한 가지 방법은 깊이 값을 쓰기 전에 프레임 버퍼의 값과 다시 비교하는 것입니다.

4.3.5 통합 셰이더 아키텍처
초기 GPU에서 버텍스 셰이더와 픽셀 셰이더의 하드웨어 구조는 독립적이었고 각각 자체 레지스터, 산술 단위 및 기타 구성 요소를 가졌습니다. 이로 인해 버텍스 셰이더와 픽셀 셰이더 간의 작업 불균형이 발생하는 경우가 많습니다. 버텍스 수가 많은 작업의 경우 픽셀 셰이더에는 유휴 상태가 많습니다. 픽셀이 많은 작업의 경우 버텍스 셰이더에는 유휴 상태가 많습니다(아래 그림).

따라서 VS와 PS 간의 불균형을 해결하기 위해 Unified Shader Architecture가 도입되었습니다. 이 아키텍처를 사용하는 GPU의 경우 VS와 PS는 동일한 코어를 사용합니다. 즉, 동일한 Core가 VS와 PS가 될 수 있습니다.

이는 다양한 유형의 셰이더 간의 불균형 문제를 해결하고 GPU의 하드웨어 단위를 줄이고 물리적 크기와 전력 소비를 압축할 수도 있습니다. 또한 VS 및 PS는 다른 셰이더(기하학, 표면, 계산)와 통합될 수 있습니다.

4.3.6 픽셀 쿼드
이전 섹션에서 언급된 13단계:
32개의 픽셀 스레드는 그룹 또는 8개의 2x2 픽셀 블록으로 나누어집니다. 이는 픽셀 셰이더에서 가장 작은 작업 단위입니다. 이 픽셀 스레드 내에서 삼각형으로 덮이지 않으면 가려집니다. SM의 워프 스케줄러는 픽셀 셰이더의 작업을 관리합니다.
즉, 픽셀 셰이더에서 4개의 인접한 픽셀은 분리할 수 없는 그룹으로 처리되어 동일한 SM에 있는 4개의 다른 코어로 전송됩니다.
픽셀 셰이더에서 처리되는 가장 작은 단위가 2x2 픽셀 블록인 이유는 무엇입니까?
저자는 다음과 같은 이유를 추측하고 있습니다.
픽셀 할당 작업을 단순화하고 가속화합니다.
SM 아키텍처를 간소화하고 하드웨어 장치의 수와 크기를 줄입니다.
전력 소비를 줄이고 성능 비율을 향상시킵니다.
유효하지 않은 픽셀의 결과는 저장되지 않지만 유효 픽셀의 도출 기능을 보조할 수 있습니다. 자세한 내용은 4.6 확장 예제 사용을 참조하세요.
이 설계에는 장점이 있지만 동시에 오버드로우 상황을 심화시키고 추가적인 성능을 소모하게 됩니다. 예를 들어 아래 그림에서 흰색 삼각형은 3픽셀(녹색)만 차지합니다. 우리의 일반적인 생각에 따르면 3번 그리는 데 코어는 3개만 필요합니다.

하지만 위의 3개 픽셀은 서로 다른 픽셀 블록(주황색 분리)을 차지하므로 실제로 12번 그리는 데에는 12개의 코어가 필요합니다(아래 그림).

이로 인해 하드웨어 성능이 추가로 300% 소모되어 더 심각한 오버드로잉이 발생합니다.
자세한 내용은 Unreal의 공식 비디오 튜토리얼인 실시간 렌더링 심층 탐구를 시청하세요.
4.4 GPU 리소스 메커니즘
이 섹션에서는 GPU의 메모리 액세스, 리소스 관리 및 기타 메커니즘에 대해 설명합니다.
4.4.1 메모리 아키텍처
GPU의 일부 아키텍처는 CPU와 유사하며 레지스터, L1 캐시, L2 캐시, GPU 메모리 및 시스템 메모리와 같은 다중 레벨 캐시 구조를 갖습니다.

액세스 속도는 레지스터에서 시스템 메모리까지 순차적으로 느려집니다.
저장 유형 등록하다 공유 메모리 L1 캐시 L2 캐시 텍스처, 상수 캐시 글로벌 메모리
액세스 주기 1 1~32 1~32 32~64 400~600 400~600
셰이더가 레지스터, L1 및 L2 캐시에 직접 액세스하는 것은 상대적으로 빠르지만 텍스처, 상수 캐시 및 전역 메모리에 액세스하는 것은 매우 느리고 많은 지연이 발생한다는 것을 알 수 있습니다.
위의 다중 레벨 캐시 구조는 "CPU 스타일"이라고 할 수 있으며 GPU 스타일 메모리 아키텍처도 있습니다.

이 아키텍처는 많은 ALU, 많은 GPU 컨텍스트(Context), 높은 처리량을 특징으로 하며 높은 대역폭을 사용하여 시스템 메모리와 데이터를 교환합니다.
4.4.2 GPU 컨텍스트 및 지연
SIMT 기술의 도입으로 인해 동일한 SM에 있는 많은 코어가 독립적이지 않습니다. 그 중 일부가 텍스처, 상수 캐시 및 전역 메모리에 액세스해야 하는 경우 매우 큰 지연이 발생합니다.
예를 들어, 아래 그림에는 동일한 컴퓨팅 유닛 ALU 그룹을 공유하는 4개의 컨텍스트 그룹(Context)이 있습니다.

첫 번째 컨텍스트 세트가 캐시나 메모리에 액세스해야 하며 이로 인해 2~3주기의 지연이 발생한다고 가정합니다. 이때 스케줄러는 ALU를 활용하기 위해 두 번째 컨텍스트 세트를 활성화합니다.

두 번째 컨텍스트 그룹이 캐시에 액세스하거나 메모리가 다시 정체되면 첫 번째 컨텍스트 그룹이 작업을 재개하거나 모두 활성화될 때까지 세 번째 및 네 번째 컨텍스트 그룹이 순차적으로 활성화됩니다.

지연으로 인해 각 컨텍스트 그룹의 전체 실행 시간이 길어집니다.

그러나 사용 가능한 컨텍스트가 많을수록 컴퓨팅 장치의 처리량이 더 많이 향상될 수 있습니다. 예를 들어 아래 그림의 18개 컨텍스트 그룹 아키텍처는 처리량을 최대화할 수 있습니다.

4.4.3 CPU-GPU 이기종 시스템
CPU와 GPU가 메모리를 공유하는지 여부에 따라 두 가지 유형의 CPU-GPU 아키텍처가 있습니다.

위 그림의 왼쪽은 분리된 아키텍처를 보여줍니다. CPU와 GPU는 각각 독립적인 캐시와 메모리를 갖고 있으며 PCI-e 등의 버스를 통해 통신한다. 이 구조의 단점은 PCI-e가 둘 다에 비해 대역폭이 낮고 지연 시간이 길어 데이터 전송이 성능 병목 현상이 된다는 점이다. 현재 PC, 스마트폰 등 널리 사용되고 있습니다.
위 그림의 오른쪽은 CPU와 GPU가 메모리와 캐시를 공유하는 결합 아키텍처입니다. AMD의 APU는 이런 구조를 사용하며 현재 PS4 등 게임 콘솔에 주로 사용되고 있다.
스토리지 관리 측면에서 보면, 분리된 구조에서 CPU와 GPU가 각각 독립된 메모리를 갖고 있습니다. 두 개는 일련의 가상 주소 공간을 공유하며 필요할 때 메모리 복사가 수행됩니다. 결합 구조의 경우 GPU는 독립적인 메모리를 갖지 않으며 MMU가 관리하는 GPU와 시스템 메모리를 공유합니다.
4.4.4 GPU 리소스 관리 모델
다음 그림은 분리된 아키텍처의 리소스 관리 모델입니다.

- MMIO(메모리 매핑 IO)
CPU와 GPU 간의 통신은 MMIO를 통해 수행됩니다. CPU는 MMIO를 통해 GPU의 레지스터 상태에 액세스합니다.
대용량 데이터의 DMA 전송은 MMIO를 통한 명령으로 제어됩니다.
I/O 포트를 사용하여 Nouveau와 같은 오픈 소스 소프트웨어에서는 절대 접근할 수 없는 MMIO 영역에 간접적으로 접근할 수 있습니다.
GPU 컨텍스트
GPU 컨텍스트는 GPU 컴퓨팅 상태를 나타냅니다.
GPU에 자체 가상 주소가 있습니다.
GPU에는 여러 활성 컨텍스트가 공존할 수 있습니다.
GPU 채널
모든 명령은 CPU에서 발행됩니다.
명령 스트림은 GPU 채널인 하드웨어 장치에 제출됩니다.
각 GPU 채널은 컨텍스트와 연관되어 있으며 GPU 컨텍스트는 여러 GPU 채널을 가질 수 있습니다.
각 GPU 컨텍스트에는 관련 채널의 GPU 채널 설명자가 포함되어 있습니다. 각 설명자는 GPU 메모리의 개체입니다.
각 GPU 채널 설명자는 페이지 테이블을 포함한 채널 설정을 저장합니다.
각 GPU 채널에는 GPU 메모리에 고유한 명령 캐시가 할당되며, 이는 MMIO를 통해 CPU에 표시됩니다.
GPU 컨텍스트 전환 및 명령 실행은 GPU 하드웨어 내부적으로 예약됩니다.
GPU 페이지 테이블
GPU 컨텍스트는 가상 기본 공간의 페이지 테이블에 의해 다른 컨텍스트와 격리됩니다.
GPU 페이지 테이블은 CPU 페이지 테이블과 분리되어 있으며 GPU 메모리에 위치합니다.
GPU 페이지 테이블의 물리적 주소는 GPU 채널 설명자에 있습니다.
GPU 페이지 테이블은 GPU 가상 주소를 GPU 메모리의 물리적 주소로 변환할 뿐만 아니라, 이를 CPU의 물리적 주소로도 변환합니다. 따라서 GPU 페이지 테이블은 GPU 가상 주소와 CPU 메모리 주소를 GPU 통합 가상 주소 공간으로 통합할 수 있습니다.
PCI-e 바
GPU 장치는 PCI-e 버스를 통해 호스트에 연결됩니다. BAR(기본 주소 레지스터)은 MMIO 창이며 GPU가 시작될 때 구성됩니다.
GPU 제어 레지스터와 메모리는 BAR에 매핑됩니다.
GPU 장치 메모리는 GPU를 구성하고 매핑된 MMIO 창을 통해 GPU 메모리에 액세스합니다.
PFIFO 엔진
PFIFO는 GPU 명령이 제출되는 특수 구성 요소입니다.
PFIFO는 일부 독립적인 명령 대기열, 즉 채널을 유지 관리합니다.
이 명령 대기열은 PUT 및 GET에 대한 포인터가 있는 링 버퍼입니다.
채널 제어 영역에 액세스하는 모든 실행 명령은 PFIFO에 의해 차단됩니다.
GPU 드라이버는 채널 설명자를 사용하여 관련 채널 설정을 저장합니다.
PFIFO는 읽기 명령을 PGRAPH 엔진으로 전송합니다.
보
메모리 블록인 BO(버퍼 개체)는 텍스처, 렌더 대상, 셰이더 코드 등을 저장하는 데 사용할 수 있습니다.
- Nouveau와 Gdev는 종종 BO를 사용합니다.
Nouveau는 NVidia 그래픽 카드용으로 작성된 무료 오픈 소스 그래픽 카드 드라이버입니다.
Gdev는 장치 드라이버를 포함하여 NVIDIA의 GPGPU 기술을 위한 풍부한 오픈 소스 소프트웨어 세트입니다.
자세한 내용은 GPU 컴퓨팅을 위한 데이터 전송 문제 문서를 참조하세요.
4.4.5 CPU-GPU 데이터 흐름
다음 그림은 분리된 아키텍처 CPU-GPU의 데이터 흐름도입니다.

메인 메모리의 처리 데이터를 비디오 메모리로 복사합니다.
CPU 명령어는 GPU를 구동합니다.
GPU의 각 컴퓨팅 장치는 병렬로 처리됩니다. 이 단계에서는 비디오 메모리의 데이터에 액세스합니다.
GPU는 비디오 메모리 결과를 다시 메인 메모리로 전송합니다.
4.4.6 이미징 메커니즘
- 수평 및 수직 동기화 신호
초기 CRT 모니터에서는 전자총이 위에서 아래로 한 줄씩 스캔했습니다. 스캔이 완료된 후 모니터에 프레임이 표시되었습니다. 그런 다음 전자총은 다음 스캔을 위해 초기 위치로 돌아갑니다. 모니터의 디스플레이 프로세스를 시스템의 비디오 컨트롤러와 동기화하기 위해 모니터는 하드웨어 시계를 사용하여 일련의 타이밍 신호를 생성합니다.

전자총이 스캔할 라인을 변경하면 디스플레이는 HSync라고 하는 수평 동기화 신호(수평 동기화)를 보냅니다.
그림의 한 프레임이 그려지면 전자총은 원래 위치로 돌아가고, 다음 프레임을 그릴 준비를 하기 전에 모니터는 VSync라고 하는 수직 동기화 신호(수직 동기화)를 보냅니다.
모니터는 일반적으로 고정된 주파수로 새로 고침되며, 이 새로 고침 빈도는 VSync 신호가 생성되는 빈도입니다. 오늘날의 모니터는 기본적으로 LCD 화면이지만 원리는 기본적으로 동일합니다.
CPU는 계산된 디스플레이 콘텐츠를 GPU에 제출합니다. GPU 렌더링이 완료된 후 렌더링 결과는 프레임 버퍼에 저장됩니다. 비디오 컨트롤러는 VSync 신호에 따라 프레임 버퍼의 데이터를 프레임 단위로 읽습니다. 데이터 변환이 완료되면 최종적으로 모니터에 표시됩니다.

- 이중 버퍼링
단일 버퍼링에서는 프레임 버퍼를 읽고 새로 고치는 데 상대적으로 큰 효율성 문제가 있으며 서로를 기다리는 경우가 많아 프레임 속도가 저하됩니다.
효율성 문제를 해결하기 위해 GPU는 일반적으로 이중 버퍼링 메커니즘이라는 두 개의 버퍼를 도입합니다. 이 경우 GPU는 비디오 컨트롤러가 읽을 수 있도록 프레임을 버퍼에 미리 렌더링합니다. 다음 프레임이 렌더링되면 GPU는 비디오 컨트롤러 포인터를 두 번째 버퍼로 직접 가리킵니다.

- 수직동기화
이중 버퍼링은 효율성 문제를 해결할 수 있지만 새로운 문제를 야기합니다. 비디오 컨트롤러가 읽기를 완료하지 않은 경우, 즉 화면 콘텐츠의 절반이 방금 표시되었을 때 GPU는 콘텐츠의 새 프레임을 프레임 버퍼에 제출하고 두 버퍼를 교환합니다. 비디오 컨트롤러는 화면에 새 데이터 프레임의 후반부를 표시하여 화면 찢어짐을 유발합니다.

이 문제를 해결하기 위해 GPU에는 일반적으로 수직 동기화(약어로 V-Sync라고도 함)라는 메커니즘이 있습니다. 수직 동기화가 켜져 있으면 GPU는 새 프레임을 렌더링하고 버퍼를 업데이트하기 전에 디스플레이의 VSync 신호가 전송될 때까지 기다립니다. 이렇게 하면 화면 잘림 문제를 해결하고 화면의 부드러움을 높일 수 있지만 더 많은 컴퓨팅 리소스가 필요하고 약간의 지연도 발생합니다.
4.5 셰이더 작동 메커니즘
셰이더 코드는 기존 C++ 및 기타 언어와도 유사합니다. 인간 중심의 고급 언어(GLSL, HLSL, CGSL)는 컴파일러를 통해 기계 중심의 바이너리 명령어로 변환되어야 합니다. 기술 담당자가 검토하고 디버깅할 수 있도록 바이너리 지침을 어셈블리 코드로 변환할 수 있습니다.

고급 언어를 어셈블리 명령으로 컴파일하는 프로세스는 일반적으로 런타임 소비를 줄이기 위해 오프라인 단계에서 수행됩니다.
실행 단계에서 CPU는 PCI-e를 통해 셰이더 바이너리 명령을 GPU에 푸시합니다. GPU가 코드를 실행할 때 Context를 사용하여 명령을 여러 채널로 나누고 이를 각 Core의 저장 공간에 푸시합니다.
최신 GPU의 경우 버텍스 셰이더, 테셀레이션 제어 셰이더, 지오메트리 셰이더, 픽셀/조각 셰이더, 컴퓨팅 셰이더 등을 포함하되 이에 국한되지 않는 프로그래밍 가능한 단계가 점점 더 많아지고 있습니다.

이러한 셰이더는 파이프라인 병렬 렌더링 파이프라인을 형성합니다. 다음은 구체적인 예를 들어 설명하겠습니다.
다음 단락은 디퓨즈를 계산하는 고전적인 코드입니다.
sampler mySamp;
Texture2D<float3> myTex;
float3 lightDir;
float4 diffuseShader(float3 norm, float2 uv)
{
float3 kd;
kd = myTex.Sample(mySamp, uv);
kd *= clamp( dot(lightDir, norm), 0.0, 1.0);
return float4(kd, 1.0);
}컴파일 후에는 어셈블리 코드가 됩니다.
<diffuseShader>:
sample r0, v4, t0, s0
mul r3, v0, cb0[0]
madd r3, v1, cb0[1], r3
madd r3, v2, cb0[2], r3
clmp r3, r3, l(0.0), l(1.0)
mul o0, r0, r3
mul o1, r1, r3
mul o2, r2, r3
mov o3, l(1.0)실행 단계에서 위의 어셈블리 코드는 GPU에 의해 실행 컨텍스트(Execution Context)로 푸시되고, ALU는 어셈블리 명령어를 하나씩 가져오고(Detch) 디코딩(Decode)한 후 실행합니다.

위의 예제 다이어그램은 단일 ALU의 실행일 뿐입니다. 실제로 GPU에는 셰이더 명령을 동시에 실행하는 수십 또는 수백 개의 실행 유닛이 있습니다.

SIMT 아키텍처 GPU의 경우 어셈블리 지침이 다르며 SIMT 관련 지침 코드가 됩니다.
<VEC8_diffuseShader>:
VEC8_sample vec_r0, vec_v4, t0, vec_s0
VEC8_mul vec_r3, vec_v0, cb0[0]
VEC8_madd vec_r3, vec_v1, cb0[1], vec_r3
VEC8_madd vec_r3, vec_v2, cb0[2], vec_r3
VEC8_clmp vec_r3, vec_r3, l(0.0), l(1.0)
VEC8_mul vec_o0, vec_r0, vec_r3
VEC8_mul vec_o1, vec_r1, vec_r3
VEC8_mul vec_o2, vec_r2, vec_r3
VEC8_mov o3, l(1.0)그리고 Context는 Core 단위로 공유 구조를 형성하며, 동일한 Core의 여러 ALU는 Context 세트를 공유합니다.

코어가 여러 개인 경우 더 많은 ALU가 동시에 셰이더 계산에 참여하게 됩니다. 각 코어에서 실행되는 데이터는 서로 다르며 버텍스, 기본 요소, 픽셀 등과 같은 데이터일 수 있습니다.

4.6 확장된 예제 사용
NV 셰이더 스레드 그룹은 GPU 스레드, 코어, SM, 워프 등과 같은 하드웨어 관련 속성을 쿼리할 수 있는 OpenGL 확장을 제공합니다. 이 확장을 활성화하려면 다음 조건을 충족해야 합니다.
OpenGL 4.3+;
GLSL 4.3+;
OpenGL 4.3+를 지원하는 NV 그래픽 카드;
그리고 이 확장은 NV 부분 5세대 셰이더에서만 작동합니다.
이 확장은 NV_gpu_program5와 상호 작용합니다.
이 확장은 NV_compute_program5와 상호 작용합니다.
이 확장은 NV_tessellation_program5와 상호 작용합니다.
구체적인 필드와 의미는 다음과 같습니다.
// 활성화(Enable)확장
#extension GL_NV_shader_thread_group : require (or enable)
WARP_SIZE_NV // 개 스레드(Thread)의 스레드(Thread)개수
WARPS_PER_SM_NV // 개 SM의 스레드(Thread)개수
SM_COUNT_NV // SM개수
uniform uint gl_WarpSizeNV; // 개 스레드(Thread)의 스레드(Thread)개수
uniform uint gl_WarpsPerSMNV; // 개 SM의 스레드(Thread)개수
uniform uint gl_SMCountNV; // SM개수
in uint gl_WarpIDNV; // 현재(Current)스레드(Thread)id
in uint gl_SMIDNV; // 현재(Current)스레드(Thread)의 SM id,[0, gl_SMCountNV-1]
in uint gl_ThreadInWarpNV; // 현재(Current)스레드(Thread)id,[0, gl_WarpSizeNV-1]
in uint gl_ThreadEqMaskNV; // 는 현재(Current)스레드(Thread)id의 。
in uint gl_ThreadGeMaskNV; // 는 현재(Current)스레드(Thread)id의 。
in uint gl_ThreadGtMaskNV; // 는 현재(Current)스레드(Thread)id의 。
in uint gl_ThreadLeMaskNV; // 는 현재(Current)스레드(Thread)id의 。
in uint gl_ThreadLtMaskNV; // 는 현재(Current)스레드(Thread)id의 。
in bool gl_HelperThreadNV; // 현재(Current)스레드(Thread)는 스레드(Thread)。위에서 언급한 보조 스레드 gl_HelperThreadNV는 2x2 픽셀 블록을 처리할 때 기본 요소에 포함되지 않는 픽셀 셰이더 스레드가 gl_HelperThreadNV = true로 표시된다는 것을 의미합니다. 해당 결과는 무시되고 저장되지 않지만 파생 상품 dFdx 및 dFdy와 같은 일부 계산에 도움이 될 수 있습니다. 오해를 방지하기 위해 원문을 게시합니다.
gl_HelperThreadNV 변수는 현재 스레드가 도우미 스레드인지 여부를 지정합니다. 이 확장을 지원하는 구현에서는 조각 셰이더 호출이 "쿼드"라고 하는 2x2 조각의 SIMD 스레드 그룹으로 정렬될 수 있습니다. 프래그먼트 셰이더 명령어가 쿼드에서 실행될 때 쿼드 내의 일부 프래그먼트가 프리미티브에 포함되지 않더라도 명령어를 실행할 가능성이 있습니다. 이러한 스레드를 도우미 스레드라고 합니다. 해당 출력은 삭제되고 전역 저장 기능을 실행하지 않지만 계산된 중간 값은 스레드 그룹 공유 기능이나 dFdx 및 dFdy와 같은 조각 파생 함수에서 계속 사용할 수 있습니다.
위 필드를 사용하면 특수 셰이더 코드를 작성하여 이를 색상 정보로 변환하여 GPU의 작동 메커니즘과 프로세스를 시각적으로 엿볼 수 있습니다.

NV 확장 필드를 사용하면 버텍스 셰이더와 픽셀 셰이더의 SM 및 Warp ID가 시각화되어 GPU의 작동 메커니즘과 프로세스를 탐색할 수 있는 방법을 제공합니다.
검증 단계에 공식적으로 진입하며 Geforce RTX 2060이 검증 대상으로 사용됩니다. 구체적인 정보는 다음과 같습니다.
운영 체제: Windows 10 Pro, 64비트
DirectX 버전: 12.0
GPU 프로세서: 지포스 RTX 2060
드라이버 버전: 417.71
드라이버 유형: 표준
Direct3D API 버전: 12
Direct3D 기능 수준: 12_1
CUDA 코어: 1920
코어 클럭: 1710MHz
메모리 데이터 속도: 14.00Gbps
메모리 인터페이스: 192비트
메모리 대역폭: 336.05GB/초
사용 가능한 총 그래픽 메모리: 22494MB
전용 비디오 메모리: 6144MB GDDR6
시스템 비디오 메모리: 0MB
공유 시스템 메모리: 16350MB
비디오 BIOS 버전: 90.06.3F.00.73
IRQ: 사용되지 않음
버스: PCI Express x16 Gen3
먼저 애플리케이션에서 두 개의 삼각형을 포함하는 꼭짓점 데이터를 만듭니다.
// set up vertex data (and buffer(s)) and configure vertex attributes
const float HalfSize = 1.0f;
float vertices[] = {
-HalfSize, -HalfSize, 0.0f, // left bottom
HalfSize, -HalfSize, 0.0f, // right bottom
-HalfSize, HalfSize, 0.0f, // top left
-HalfSize, HalfSize, 0.0f, // top left
HalfSize, -HalfSize, 0.0f, // right bottom
HalfSize, HalfSize, 0.0f, // top right
};렌더링에 사용되는 버텍스 셰이더는 매우 간단합니다.
#version 430 core
layout (location = 0) in vec3 aPos;
void main()
{
gl_Position = vec4(aPos, 1.0f);
}프래그먼트 셰이더도 단 몇 줄로 구성됩니다.
#version 430 core
out vec4 FragColor;
void main()
{
FragColor = vec4(1.0f, 0.5f, 0.2f, 1.0f);
}그려진 원본 그림은 다음과 같습니다.

다음으로 프래그먼트 셰이더를 수정하고, 확장에 필요한 코드를 추가하고, 색상 계산을 수정합니다.
#version 430 core
#extension GL_NV_shader_thread_group : require
uniform uint gl_WarpSizeNV; // 개 스레드(Thread)의 스레드(Thread)개수
uniform uint gl_WarpsPerSMNV; // 개 SM의 스레드(Thread)개수
uniform uint gl_SMCountNV; // SM개수
in uint gl_WarpIDNV; // 현재(Current)스레드(Thread)id
in uint gl_SMIDNV; // 현재(Current)스레드(Thread)의 SM id,[0, gl_SMCountNV-1]
in uint gl_ThreadInWarpNV; // 현재(Current)스레드(Thread)id,[0, gl_WarpSizeNV-1]
out vec4 FragColor;
void main()
{
// SM id
float lightness = gl_SMIDNV / gl_SMCountNV;
FragColor = vec4(lightness);
}위 코드로 렌더링된 이미지는 다음과 같습니다.

위에서 일부 정보를 분석할 수 있습니다.
화면에는 총 32개의 밝기 레벨이 있습니다. 이는 Geforce RTX 2060에 32개의 SM이 있음을 의미합니다.
단일 SM은 매번 16x16 픽셀 블록을 렌더링합니다. 즉, 각 SM에는 256개의 코어가 있습니다.
픽셀 블록은 SM 간에 순차적으로 할당되지 않고 순서대로 할당됩니다.
서로 다른 삼각형의 이음새에 오류가 나타나며, 이는 동일한 픽셀 블록이 서로 다른 삼각형에 속하는 경우 처리를 위해 서로 다른 SM에 할당된다는 것을 나타냅니다. 같은 면적의 면적에 삼각형이 많을수록 SM에 더 많이 할당되어 더 많은 렌더링 성능을 소모하게 된다는 것을 유추할 수 있습니다**.
그런 다음 조각 셰이더의 색상 계산 코드를 수정하여 Warp ID를 표시합니다.
// warp id
float lightness = gl_WarpIDNV / gl_WarpsPerSMNV;
FragColor = vec4(lightness);다음 화면을 얻으십시오 :

다음으로부터 몇 가지 정보나 추론을 이끌어낼 수 있습니다.
그림에는 총 32개의 밝기 레벨이 있습니다. 즉, 각 SM에는 32개의 워프가 있고 각 워프에는 8개의 코어가 있습니다.
각 색상 블록의 픽셀은 4x8입니다. 각 워프에는 8개의 코어가 있으므로 각 코어는 한 번에 2x2의 최소 단위 픽셀 블록을 처리해야 하는 것으로 추론됩니다.
픽셀 블록도 순서 없이 할당됩니다.
SM의 추론과 일치하는 삼각형 관절에 결함이 나타납니다.
그런 다음 스레드 ID를 표시하도록 조각 셰이더의 색상 계산 코드를 수정합니다.
// thread id
float lightness = gl_ThreadInWarpNV / gl_WarpSizeNV;
FragColor = vec4(lightness);다음 화면을 얻으십시오 :

분석을 용이하게 하기 위해 Photoshop을 사용하여 중간 부분을 10배 확대하면 다음 그림이 나옵니다.

위의 두 그림을 결합하면 다음과 같은 결론을 내릴 수도 있습니다.
SM 및 실경사에 비해 실 분포도가 비교적 규칙적입니다. 이는 동일한 Warp의 실 분포가 규칙적임을 나타냅니다.
삼각 솔기에 무질서가 있어, 날실에 따라 실이 달라지는 것을 알 수 있습니다.
그림에는 32개의 색상 레벨이 있으며, 이는 단일 워프에 32개의 스레드가 있음을 나타냅니다.
각 픽셀은 주변의 인접 픽셀과 다른 독점적인 밝기 수준을 차지합니다. 이는 각 스레드가 하나의 픽셀만 처리함을 나타냅니다.
다시 한번 말씀드리지만, 위의 그림과 결론은 Geforce RTX 2060을 기반으로 합니다. GPU 모델에 따라 다를 수 있으며, 얻은 결과와 추론도 다를 수 있습니다.
더 많은 NV 확장을 보려면 OpenGL 공식 웹사이트인 NV 확장을 참조하세요.
5. 요약
5.1 CPU 대 GPU
CPU와 GPU의 차이점은 다음 표에 설명되어 있습니다.
CPUGPU
지연 허용 범위 낮음 높은
병렬 대상 작업 데이터
핵심 아키텍처 멀티스레드 코어 SIMT 코어
스레드 번호 수준 10 10000
처리량 낮음 높은
캐싱 요구 사항 높은 낮음
스레드 독립성 낮음 높은
이들 간의 차이점(캐시, 코어 수, 메모리, 스레드 수 등)은 다음 그림에 표시됩니다.

5.2 렌더링 최적화 제안
이전 장의 분석을 기반으로 렌더링 최적화 제안을 쉽게 제공할 수 있습니다.
- CPU와 GPU 간의 데이터 교환 감소:
배치
꼭지점과 삼각형의 수를 줄입니다.
프러스텀 클리핑 보기
BV
-포탈
-BSP
-OSP
- 매 프레임마다 버퍼 데이터를 제출하지 마세요.
CPU 버전의 파티클과 애니메이션은 매 프레임마다 수정 및 제출되며 GPU 측으로 이동할 수 있습니다.
- 렌더링 상태 설정 및 쿼리 감소
예: glGetUniformLocation은 GPU 메모리에서 상태를 쿼리하므로 시간이 많이 걸립니다.
매 프레임마다 렌더링 상태를 설정하고 쿼리하는 것을 피하고 초기화 중에 상태를 캐시합니다.
GPU 인스턴스 활성화
LOD를 켜세요
비디오 메모리에서 데이터를 읽지 마십시오.
오버드로 감소:
Tex Kill 작업을 피하세요
- 알파 테스트를 피하세요
-알파 블렌드를 피하세요
- 깊이 테스트 활성화
초기-Z
계층적 Z 버퍼링(HZB)
자르기 켜기:
백 컷
폐색 자르기
뷰포트 자르기
가위 직사각형
개체 수를 제어합니다.
입자의 개수는 많고 면적은 작습니다. 픽셀 블록 메커니즘으로 인해 오버드로잉이 악화됩니다.
식물, 모래, 머리카락 등도 마찬가지입니다.
셰이더 최적화:
if 및 switch 분기 문을 피하세요.
루프 문, 특히 루프 개수가 가변적인 문은 피하세요.
텍스처 샘플링 시간 단축
클립 비활성화 또는 작업 삭제
복잡한 수학 함수 호출을 줄입니다.
더 많은 최적화 팁을 보려면 다음을 읽어보세요.
모바일 게임 성능 최적화를 위한 일반적인 기술.
GPU 프로그래밍 가이드.
실시간 렌더링 리소스.
5.3 GPU의 미래
[2.2 GPU 역사](#2.2 GPU 역사)에서 몇 가지 결론을 도출할 수 있으며, GPU 개발 추세도 추측할 수 있습니다.
하드웨어 업그레이드. 더 많은 컴퓨팅 장치, 더 많은 저장 공간, 더 높은 동시성, 더 높은 대역폭 및 더 낮은 대기 시간. . .
타일 기반 렌더링 통합. 타일 기반 렌더링은 대역폭을 줄이고 조명 계산 효율성을 어느 정도 향상시킬 수 있습니다. 현재 일부 모바일 및 데스크톱 GPU에 이 기술이 도입되었으며, 향후에는 표준이 될 것으로 예상됩니다.

- 3D 메모리 기술. 현재 대부분의 전통적인 메모리는 2D이지만 3D 메모리는 다릅니다. 입방체 구조와 유사한 물리적 구조가 3D이며 칩에 통합됩니다. 액세스 속도와 성능 비율은 몇 배 더 높아질 수 있습니다.

- GPU의 프로그래밍 가능성이 더욱 높아지고 있습니다. GPU는 본질적으로 병렬이며 상대적으로 고정되어 있습니다. 앞으로는 프로그래밍을 위해 점점 더 많은 셰이더가 공개될 것이며, 반대로 CPU는 병렬로 개발될 것입니다. 즉, 미래의 GPU는 점점 더 CPU와 비슷해지고, CPU도 점점 GPU와 비슷해질 것입니다. 뭉치면 갈라지고, 갈라지면 뭉친다는 옛말이 이루어졌을까?

- 실시간 조명 추적의 인기. Turing 아키텍처 기반 GPU에는 수많은 RT Core, HVB, AI 노이즈 감소 및 기타 기술이 추가되었습니다. 하이브리드 렌더링 파이프라인은 이 아키텍처의 레이 트레이싱 렌더링 파이프라인으로, 래스터라이저, RT Core 및 Compute Core를 동시에 결합하여 하이브리드 렌더링을 수행할 수 있습니다.

하이브리드 렌더링 파이프라인은 레이 트레이싱 렌더링 파이프라인과 래스터라이제이션 렌더링 파이프라인의 조합과 동일합니다.

- 데이터 동시성 향상, 심층신경망, GPU 컴퓨팅 유닛 등이 대중화되고 개선됩니다.

- AI 노이즈 감소 및 AI 안티앨리어싱. AI 노이즈 감소는 RTX 시리즈의 일부 레이 트레이싱 버전에 적용되었으며 AI 안티앨리어싱(Super Res)을 초고해상도 비디오 이미지 안티앨리어싱에 사용할 수 있습니다.

- 작업 및 메시 셰이더 기반 렌더링 파이프라인. 작업 및 메시 셰이더(작업 및 메시 셰이더가 포함된 그래픽 파이프라인)를 기반으로 하는 렌더링 파이프라인은 기존의 래스터라이제이션된 렌더링 조명과 매우 다릅니다. 이는 스레드 그룹(Thread Group), 작업 셰이더(Task Shader) 및 메시 셰이더(Mesh Shader)를 기반으로 새로운 렌더링 파이프라인을 형성합니다.

이 기술에 대한 자세한 내용은 NVIDIA Turing 아키텍처 백서에서 확인할 수 있습니다.
- 가변 속도 음영. 가변 속도 셰이딩 기술은 사진 영역의 중요도를 결정(또는 애플리케이션에서 지정)한 다음 사진 영역의 중요도에 따라 다양한 셰이딩 해상도 정확도를 채택하여 전력 소비를 크게 줄이고 셰이딩 효율성을 향상시킬 수 있습니다.

5.4 결론
이 문서에서는 GPU의 역사, 개발 및 워크플로우를 체계적으로 설명하고 일부 프로세스와 사용된 다양한 기술에 대한 자세한 설명을 제공합니다. 이를 통해 GPU 아키텍처의 동기, 메커니즘, 병목 현상 및 향후 개발을 확인할 수 있습니다.
이 기사를 읽은 후 서문에서 제기된 질문에 답할 수 있기를 바랍니다. 1.3 질문과 함께 읽기. 모두 대답할 수 없어도 상관없습니다. 언제든지 관련 장을 다시 살펴보면 답을 찾을 수 있습니다.
GPU의 설계 세부 사항과 구현 세부 사항에 대해 더 깊이 이해하려면 GPU 제조업체에서 정기적으로 발행하는 백서와 주요 대학 및 기관에서 발행하는 논문을 읽어보세요. GPU 설명 비디오인 A trip through the Graphics Pipeline 2011: Index를 추천합니다. 수년 전의 영상이지만 GPU의 메커니즘과 기술을 비교적 체계적이고 포괄적으로 설명하고 있습니다.
특별 지침
모든 참고 문헌의 저자에게 감사드립니다!
원본글이며, 무단전재를 금합니다!
📚 참고 자료 및 공식 링크 (References)
- Real-Time Rendering Resources
- Life of a triangle - NVIDIA's logical pipeline
- NVIDIA Pascal Architecture Whitepaper
- NVIDIA Turing Architecture Whitepaper
- Pomegranate: A Fully Scalable Graphics Architecture
- Performance Optimization Guidelines and the GPU Architecture behind them
- A trip through the Graphics Pipeline 2011
- Graphic Architecture introduction and analysis
- Exploring the GPU Architecture
- Introduction to GPU Architecture
- An Introduction to Modern GPU Architecture
- GPU TECHNOLOGY: PAST, PRESENT, FUTURE
- GPU Computing & Architectures
- NVIDIA VOLTA
- NVIDIA TURING
- Graphics processing unit
- GPU아키텍처렌더링
- 렌더링-GPU
- GPU Architecture and Models
- Introduction to and History of GPU Algorithms
- GPU Architecture Overview
- (8)——렌더링원리 및 메커니즘
- GPU Programming Guide GeForce 8 and 9 Series
- GPU 원리 및 메커니즘
- NVIDIA
- DirectX
- 셰이더(Shader)
- 📖 레이 트레이싱 기술과 UE4 구현 살펴보기
- 📖 모바일 게임 성능 최적화를 위한 일반적인 기법
- NV shader thread group
- 실시간 렌더링(Real-Time Rendering)
- NVIDIA GPU 소개
- Data Transfer Matters for GPU Computing
- Slang – A Shader Compilation System
- Graphics Shaders - Theory and Practice 2nd Edition