일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 보안
- naver
- 프론트엔드
- GPU
- 알고리즘
- FE
- webGPU
- typescript
- 항해
- 항해99
- 항해플러스
- wil
- 자바스크립트
- React
- React Query
- 백준
- 테스트 코드
- 회고
- 분기 회고
- 리뷰
- rust
- 성능최적화
- 개발자
- javascript
- 개발 공부
- 성장일지
- 항해 플러스 프론트엔드
- 개발공부
- 항해 플러스
- frontend
- Today
- Total
느릿늘있
[WebGPU]에 대해서 Araboza...(2) 본문
본 게시글은 W3C에 게시된 WebGPU Explainer 글을 학습을 위해 번역한 글입니다.
2. 추가 배경 지식
2.1. 웹 브라우저에 Sandboxed(격리, 은닉, 캡슐화 정도의 의미인 듯) GPU 프로세스
GPU-process 아키텍쳐에서 WebGPU는 반드시 구현가능하고 효율적이어야 합니다. GPU 드라이버는 웹 컨텐츠에 대한 접근보다 추가적인 커널 시스템 콜에 대한 접근을 더 필요로 합니다. 이로 인해 많은 GPU 드라이버들이 멈추거나 충돌하기 쉽습니다. 안정성(Stability)과 격리(sandboxing)를 향상시키기 위해서 브라우저는 다른 브라우저와 비동기 IPC(Inter Process Communication)로 통신하는 특별한 프로세스를 사용합니다. GPU 프로세스는 Chromium, Gecko, Webkit에서 사용됩니다.
GPU 프로세스는 컨텐츠 프로세스보다 덜 격리되어 있습니다. 그리고 GPU 프로세스들은 일반적으로 origin을 공유합니다.
따라서, 모든 메세지의 유효성을 검사해야 합니다. 예를 들어, 손상된 컨텐츠 프로세스가 다른 컨텐츠 프로세스에서 사용하는 GPU 메모리를 볼 수 없게 합니다. 대부분의 WebGPU 유효성 검사 규칙은 WebGPU가 사용하기에 안전한지 보장하는데 필수적입니다. 따라서, 모든 유효성 검사는 GPU 프로세스 내에서 발생해야 합니다.
마찬가지로, 큰 메모리 할당이나 파이프라인 같은 복잡한 객체를 포함해서 모든 GPU 드라이버 객체는 GPU 프로세스 내부에만 존재해야 합니다. 컨텐츠 프로세스 안에서, WebGPU의 타입(GPUBuffer, GPUTexture, GPURenderPipeline, ...)은 대부분 GPU 프로세스 내에 있는 객체들을 식별하는 "핸들"일 뿐입니다. 이는 WebGPU에서 사용하는 CPU 및 GPU 메모리에 대한 정보를 컨텐츠 프로세스 내에서 반드시 알 필요가 없다는 것을 의미합니다. GPUBuffer 객체는 아마도 CPU 메모리의 150 바이트 정도를 사용하는데에도 1GB의 GPU 메모리를 할당 받습니다.
2.2 GPU 및 GPU Process의 메모리 가시성
GPU의 두 가지 주요 타입은 "integrated(통합) GPUs"와 "discrete(개별) GPUs"라고 불립니다. 개별 GPUs는 CPU와 분리되어 있습니다. 개별 GPUs는 일반적으로 컴퓨터의 마더보드에 연결하는 PCI-e 카드 형태로 제공됩니다. 통합 GPU는 CPU와 동일한 다이에 있으며 자체 메모리 칩이 없습니다. 대신에 CPU와 동일한 RAM을 사용합니다.
※ 메모리 가시성 : 멀티 코어(CPU)에서 특정 메모리에 대한 값을 동시에 읽어야하는 상황들을 의미한다. 여기서는 GPU도 특정 메모리에 대해 접근하는데 그 메모리 공간을 CPU와 어떻게 공유하고 활용하는 지에 대해 설명하고 있다. 정확하게는 이를 메모리 가시성이라고 부르고 반대로 어떻게 분리할 것인지에 대한 것은 메모리 장벽(Memory Barrier)이라고 부른다.
개별 GPU를 사용할 때, 대부분의 GPU 메모리 할당이 CPU에 표시되지 않는다는 것을 쉽게 알 수 있습니다. 왜냐하면, GPU의 RAM(비디오 RAM의 경우 VRAM) 내부에 할당되기 때문입니다. 통합 GPU는 대부분의 메모리 할당이 물리적으로 동일한 위치에서 발생합니다. 하지만 여러 가지 이유로 GPU에 표시되지 않습니다. 예를 들자면, CPU와 GPU가 동일한 메모리에 대해 별도의 캐시를 가질 수 있어서 일관성 있는 접근이 보장되지 않는 경우가 있습니다. 대신에 CPU가 GPU 버퍼의 내용을 보려면 데이터가 mapping이 되어 애플리케이션의 가상 메모리 공간에서 사용할 수 있어야 합니다.(nmap을 생각해보세요.) 매핑 가능하려면 GPUBuffer를 특별한 방법으로 할당해야 합니다. - 이는 GPU에서 엑세스하는 것이 덜 효율적이게 만들 수 있습니다.(ex. VRAM 대신 RAM에 할당해야 하는 경우)
지금까지의 논의는 native GPU API를 중심으로 진행되었습니다. 하지만 브라우저에서는 GPU 드라이버가 GPU 프로세스에 로드되므로 native GPU 버퍼는 GPU 프로세스의 가상 메모리에만 매핑될 수 있습니다. 일반적으로 컨텐츠 프로세스 내에서 직접 버퍼를 매핑하는 것은 불가능합니다.(일부 시스템에서는 선택적 최적화를 제공하여 이를 수행할 수 있음) 이 아키텍쳐로 작업하려면 GPU 프로세스와 컨텐츠 프로세스 사이의 공유 메모리에 추가 "staging" 할당이 필요합니다.
아래 표에 어떤 타입의 메모리를 어디서 볼 수 있는지 요약되어 있습니다.
일반 ArrayBuffer | 공유 메모리 | Mappable GPU Buffer | Non-Mappable GPU (Buffer or texture) |
|
CPU(컨텐츠 프로세스) | Visible | Visible | Not visible | Not visible |
CPU(GPU 프로세스) | Not visible | Visible | Visible | Not visible |
GPU | Not visible | Not visible | Visible | Visible |
※ System 쪽 지식과 WebGPU 사용 경험이 쌓이면 이해가 더 잘 될 것 같다. 우선은 " WebGPU 학습에 있어서 CPU와 GPU 간 메모리 관리에 대한 부분들을 알아둘 필요가 있다. " 정도만 기억하고 세부 내용은 일단 넘어가자.
'개발공부' 카테고리의 다른 글
[GIT] commit message prefix (0) | 2023.06.28 |
---|---|
[TIL] 하이럼의 법칙 (0) | 2023.06.21 |
[WebGPU]에 대해서 Araboza...(1) (0) | 2023.06.13 |
[ReactNative] Expo 쓰는 이유 (0) | 2023.05.27 |
[TIL] Naver FE News 2022-02 (0) | 2023.05.20 |