소개에 따르면 WebGPU는 Mozilla, Apple, Intel 및 Microsoft와 같은 주요 회사의 기여를 포함하여 W3C "Web GPU" 커뮤니티 그룹의 공동 노력의 결과입니다. 2017년 초기 설계 이후 6년 간의 개발 끝에 WebGPU의 첫 번째 구현이 마침내 Chrome에 상륙하여 Firefox와 Safari를 모두 지원합니다.
6년 간의 개발 끝에 현지 시간으로 4월 6일 Google 크롬 팀은 네트워크에서 고성능 3D 그래픽 및 데이터 병렬 컴퓨팅을 위한 WebGPU를 공식 출시했습니다. WebGPU는 이제 베타 테스트에서 Chrome 113에서 기본적으로 활성화됩니다.
WebGPU는 새로운 형태의 웹 그래픽 API로 동일한 그래픽 스케일에서 자바스크립트의 작업량을 획기적으로 줄이고 머신러닝 모델의 추론 효율성을 3배 이상 높일 수 있는 장점이 있다. 이러한 도약은 유연한 GPU 프로그래밍과 WebGL이 할 수 없는 고급 기능에 대한 액세스 덕분에 가능합니다.
WebGPU의 첫 번째 버전은 ChromeOS, macOS 및 Windows에서 공개되었으며 다른 플랫폼에 대한 지원은 올해 후반에 출시될 예정입니다.
01 "웹 그래픽의 새로운 여명"
WebGPU는 최신 하드웨어 기능을 노출하고 Direct3D 12, Metal 및 Vulkan과 유사하게 GPU에서 렌더링 및 컴퓨팅 작업을 수행할 수 있는 새로운 유형의 웹 API입니다. WebGL API 제품군과 달리 WebGPU는 고급 GPU 기능에 대한 액세스를 제공하고 GPU에서 일반 컴퓨팅을 위한 최고 수준의 지원을 제공합니다. API는 웹 플랫폼에 완전히 적응하도록 설계되어 관용적인 JavaScript API, 약속 통합, 비디오 가져오기 지원 및 완전한 오류 메시지를 통해 포괄적인 개발자 경험을 제공합니다.
이 첫 번째 WebGPU 릴리스는 향후 업데이트 및 개선을 위한 기본 빌딩 블록이 될 것입니다. API는 향후 더 고급 그래픽 기능을 제공할 것이며 개발자는 다른 기능을 신청할 것을 권장합니다. Chrome 팀은 WGSL(WebGPU Shading Language)에서 더 많은 기계 학습 최적화 및 추가 인체 공학적 조정을 위해 셰이더 코어에 대한 심층 액세스를 제공할 계획입니다.
소개에 따르면 WebGPU는 Mozilla, Apple, Intel 및 Microsoft와 같은 주요 회사의 기여를 포함하여 W3C "Web GPU" 커뮤니티 그룹의 공동 노력의 결과입니다. 2017년 초기 설계 이후 6년간의 개발(기고자 90명, 커밋 2000개, 이슈 3000개) 후에 WebGPU의 첫 번째 구현이 마침내 공식적으로 Chrome에 상륙하여 Firefox와 Safari를 모두 지원합니다.
Chromium 및 Dawn 라이브러리와 Firefox의 wgpu 라이브러리는 모두 독립 실행형 패키지로 제공되어 운영 체제 GPU API를 추상화하는 뛰어난 이식성 및 인체 공학 계층을 제공합니다. 또한 개발자는 네이티브 애플리케이션에서 이러한 라이브러리를 사용할 때 Emscripten 및 Rust web-sys를 통해 WASM으로 쉽게 마이그레이션할 수 있습니다.
WebGPU의 첫 번째 릴리스는 Vulkan을 지원하는 ChromeOS 기기, Direct3D 12를 지원하는 Windows 기기, macOS의 Chrome 113에서 사용할 수 있습니다. Linux, Android 및 기타 기존 플랫폼에 대한 확장 지원도 연중 제공될 예정입니다. Chrome 외에도 WebGPU는 처음에 Firefox 및 Safari 브라우저에 상륙했습니다.
널리 사용되는 많은 WebGL 라이브러리는 WebGPU를 지원하거나 지원할 수 있으므로 사용자는 WebGPU를 사용하기 위해 한 줄만 변경하면 됩니다.
- 1
Babylon.js는 이미 WebGPU를 완전히 지원합니다.
- 2
PlayCanvas는 WebGPU에 대한 초기 지원을 발표했습니다.
- 삼
TensorFlow.js는 대부분의 연산자에 대해 WebGPU 최적화 버전을 지원합니다.
- 4
Three.js는 WebGPU 지원을 구현하기 위해 노력하고 있습니다.
02 설렘과 걱정이 공존한다
WebGPU의 탄생은 사실 메이저 제조사들의 고군분투의 결과라고 합니다. 2016년 Google은 WebGL에 몇 가지 문제가 있음을 발견하고 또 다른 정확한 그래픽 API를 만든다고 주장하는 WebGL Next라는 새로운 제안을 내놓았습니다. 그런 다음 다른 제조업체가 그 뒤를 따랐고 Mozilla, Apple 및 Opera는 모두 자체 개념을 제안했습니다.
이때 Apple 네이밍 부서 직원이 W3C에 WebGPU라는 제안서를 제출했고, W3C는 이 이름을 향후 새로운 표준의 네이밍으로 채택하기로 결정하고 WebGPU 작업을 위한 워킹 그룹을 구성했습니다.
이 이름은 Apple에서 부여한 것이기 때문에 결국 Apple의 제안서만 "gpuweb-proposals" 코드 웨어하우스에 입력되었지만 동일한 이름으로 인한 오해와 충돌을 피하기 위해 Apple의 원래 제안서 이름은 WebMetal로 변경되었습니다.
W3C가 Apple의 제안을 수락한 것을 보고 Mozilla는 화해하지 않고 대신 Khornos Group 다음으로 WebGL이라는 Vulkan 기반 제안을 제출했지만 이것이 WebGL의 마지막 노력입니다. 결국 브라우저 벤더들은 그들의 발로 투표했고 WebGPU 편에 섰습니다.
이제 수년간의 기다림 끝에 Google 팀이 공식적으로 WebGPU를 출시했으며 많은 개발자들이 흥분하고 있습니다.
"그거 정말 신난다!"
"이것은 거대한 이정표이자 더 큰 여정의 일부입니다. 고급 2D 렌더러인 Vello에 대한 작업에서 저는 WebGPU가 게임 체인저라는 것을 믿게 되었습니다. 우리는 웹, Windows, Mac과 같은 상당히 현대적인 인프라를 갖게 될 것입니다. , Linux, ChromeOS, iOS 및 Android"라고 개발자 raphlinus는 말합니다.
누군가 "당신이 ML 실무자라고 가정합니다. CUDA에 더 많은 시간을 보내는 대신 WebGPU를 배우는 것을 여전히 추천하시겠습니까?"라고 물으면, raphlinus는 "모든 것은 당신의 목표에 달려 있습니다. 당신이 실제 기계 학습 알고리즘에 대해 작업하고 있다면 그런 다음 TensorFlow 또는 Torch와 같은 프레임워크를 사용하여 모든 텐서 작업을 제공하고 하드웨어를 추상화합니다.오늘날 하드웨어에서 최대 성능을 원한다면 Nvidia를 고수하고 CUDA를 선택하십시오.다양한 하드웨어에 배포하는 데 관심이 있다면 또는 wonnx와 같은 구현 알고리즘을 직접 구현하고 싶다면 WebGPU가 적합합니다."
개발자 "FL33TW00D"는 "이것은 매우 흥미진진합니다! (114로 미끄러질 것이라고 예상했습니다) WebGPU 구현은 아직 미숙하지만 확실히 사용하기에 충분합니다." FL33TW00D는 "과거에는 몇 개월 동안 Rust + WebGPU ML 런타임을 구현하고 WGSL 작성을 즐겼습니다. 최근에 많은 최적화 없이 브라우저에서 실행할 수 있는 250M 매개변수 LLM을 얻었고 성능이 좋았습니다! 즉, matmuls는 여전히 있습니다. 브라우저의 큰 버그(특히 브라우저에서 실행되는 경계 검사를 고려함) 내 벤치마크에서 나는 이론적 FLOPS의 50%에 도달하기 위해 고군분투했으며 경계 검사가 시작되면 30%로 감소할 것입니다. 액세스를 기대합니다. 게시물에 언급된 셰이더 코어."
Burn(Rust 딥 러닝 프레임워크) 프로젝트의 기여자들도 WebGPU 백엔드를 추가할 것이라고 말했습니다.
WebGPU, 너무 늦었나요?
물론 WebGPU가 이제서야 출시되는 것인지에 대해 의구심을 표한 개발자들도 있습니다. 전 Unity 게임 엔진 엔지니어인 Aras Pranckevičius는 "WebGL은 구식입니다. WebGPU도 약간 늦은 것 같습니다(PSO가 좋은 생각이 아닐 수도 있는 지금의 Vulkan과 같습니다. lol)."
그는 WebGPU가 8년 전과 마찬가지로 "최신 그래픽 API 설계"라고 덧붙였습니다. 안 하는 것보다는 늦겠지만... "현대"의 개념은 요즘 방향으로 가고 있는 것 같습니다. 모든 것("언바운드"가 의미하는 세 번째 반복과 같은), 그리드 셰이더, 레이트레이싱, 유연한 파이프라인 상태. 그러나 이들 모두 WebGPU에는 없습니다.
이에 대한 응답으로 Google 그래픽 파이프라인 엔지니어인 Corentin Wallez는 네이티브 API가 발전했으며 PSO는 당시에 유지할 수 있다고 생각하는 특정 방향으로 게임 개발자를 밀어붙였습니다(모든 것을 사전 컴파일했지만 그렇지 않은 것으로 판명됨). . 그는 WebGPU가 언바운드 또는 메시 셰이더를 지원하지 않는 장치를 포함하여 현재 사용 중인 모든 하드웨어를 지원해야 한다고 말했습니다. "그러나 첫 번째 버전 이후에는 계속해서 개선되고 몇 가지 중요한 새 기능을 따라잡을 것입니다."
또한 개발자 "flohofwoe"는 Aras에 동의하지만 "Elephant in the room"은 여전히 나쁜 모바일 GPU라고 생각합니다. 이러한 참신함의 대부분은 모바일 GPU에서 사용할 수 없으며 가까운 미래에도 여전히 가능하지 않을 것입니다. (Vulkan에는 실제로 두 개의 API가 있어야 합니다. 하나는 데스크톱 GPU용이고 다른 하나는 모바일 GPU용입니다. 이 새로운 확장 기능은 Vulkan을 두 개 정도의 별도 API로 분할하고 있습니다. )
"WebGPU는 이러한 분할을 감당할 수 없습니다. 동일한 코드 기반에서 데스크탑과 모바일에서 동등하게 잘 작동해야 합니다(모바일은 실제로 데스크탑보다 훨씬 더 중요합니다)"라고 flohofwoe는 말합니다.
03 WebGPU 대 WebGL
그래서 WebGL의 후계자로서 일부 개발자는 WebGPU와 WebGL의 차이점을 제안했습니다. Keike Fangfang의 수석 엔지니어인 Hao Jiali는 GMTC Global Big Front-End Technology Conference에서 둘 사이의 성능 비교를 공유한 적이 있습니다.
복잡한 장면에 대한 렌더링 성능을 비교한 것입니다. 이 장면에는 1000개의 나무가 있고 인스턴스별로 그려지지는 않지만 각 나무에는 드로우 콜이 있으므로 한 장면에서 1000개 이상의 드로우 콜이 필요합니다. 드로잉에 WebGL을 사용하는 경우 2070 그래픽 카드를 사용하면 21FPS까지만 실행할 수 있고 각 프레임의 CPU 시간은 44밀리초가 필요하지만 WebGPU를 사용하여 처리하면 123프레임까지 실행할 수 있으며 CPU는 각 프레임당 시간은 단 0.1밀리초로 WebGPU와 WebGL 사이의 가장 크고 중요한 성능 차이입니다.
다른 하나는 코드 갭입니다. WebGL 네이티브 API로 드로잉을 하는 과정에서 모든 것의 출발점은 Canvas인데, 이것은 아무것도 그릴 필요가 없더라도 사용자가 Canvas 요소를 생성해야 한다는 점에서 매우 놀라운 일입니다. 프런트엔드에는 불필요할 수 있습니다. 체감하지만 브라우저 개발자에게는 새로운 DOM 요소를 생성하고 필요한 모든 것을 추가해야 합니다. 일단 DOM 요소가 축소되면 브라우저가 이 모든 것을 처리해야 합니다. 개발자에게는 , 다음은 매우 복잡해질 수 있습니다.
하지만 WebGPU는 그렇지 않습니다.WebGPU의 진입점은 navigator.gpu입니다.사용자는 여기에서 그래픽 카드를 가져온 다음 그래픽 카드에서 장치를 가져올 수 있지만 중간에 Canvas가 없습니다.