▲

Firefox 141에서 Windows용 WebGPU 정식 출시

 (mozillagfx.wordpress.com)
3P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • WebGPU가 오랜 개발 끝에 Firefox 141 Windows 버전에서 공식 지원됨
  • WebGPU는 최신 그래픽 처리와 고성능 연산을 위한 웹 기반 GPU 인터페이스로, 게임·** 시각화**·** 로컬 연산**의 수준을 크게 높일 것으로 기대됨
  • Firefox의 WebGPU 구현은 Rust 기반 WGPU 라이브러리 위에 구축되었으며, Direct3D 12, Metal, Vulkan 등 다양한 백엔드 지원
  • 현재는 Windows에서만 정식 활성화되며, Mac과 Linux, Android 지원도 향후 예정
  • 아직 성능 개선과 표준 준수 등 추가 개발 과제가 남아 있음

WebGPU Windows 지원의 의미

  • 오랜 기간 개발한 WebGPU가 Firefox 141에서 Windows 환경에 정식 탑재됨
  • WebGPU는 웹 콘텐츠가 사용자 GPU와 직접 연동해 고성능 그래픽과 병렬 연산을 구현할 수 있도록 해주는 최신 표준임
  • 이 기술로 인해 웹 기반 게임, 데이터 시각화, 머신러닝 등 다양한 분야에서 성능 한계가 크게 확장될 전망임
  • WebGPU 튜토리얼, WebGPU 샘플, MDN 문서를 통해 관련 학습과 실습 가능함
  • WebGPU는 WebGPU W3C 표준과 WGSL 표준로 정의되며, Mozilla는 2017년부터 표준화 과정에 적극 참여해 왔음

브라우저별 WebGPU 현황

  • Chrome에서는 이미 2023년부터 WebGPU 지원이 이뤄짐
  • Safari 26에서는 올해 가을 출시 예정
  • Firefox 141은 현재 Windows만 정식 지원, Mac/Linux/Android는 향후 업데이트로 확대 예정
  • Firefox Nightly 버전에서는 그동안 Android 제외 모든 플랫폼에서 실험적으로 사용 가능했음

Firefox의 WebGPU 구현

  • Firefox의 WebGPU는 오픈소스 Rust 라이브러리인 ** WGPU**를 기반으로 개발됨
    • WGPU는 다양한 플랫폼 하드웨어에 맞춰 Direct3D 12, Metal, Vulkan 등 저수준 그래픽 API와 연결됨
    • Mozilla는 WGPU 프로젝트의 주요 기여자임
    • Rust 개발자라면 Firefox WebGPU에 기여하려면 WGPU 프로젝트에서 시작하는 것이 적합함
  • WGPU는 Firefox 외부에서도 널리 쓰이며 활발한 커뮤니티가 존재함

주요 과제와 개선 작업

  • WebGPU는 대형·복잡한 API로, 현재까지는 주요 데모 및 실사용 사례 중심으로 안정화에 집중함
  • 추가 개선이 필요한 영역:
    • GPU 샌드박스 프로세스와의 비버퍼링 IPC로 인해 발생하는 성능 저하 문제 해결(버그 1968122, Firefox 142에서 성능 개선 예정)
    • GPU 작업 완료 시점을 인터벌 타이머로만 감지해 생기는 대기 시간 증가(버그 1870699, 더 나은 방식으로 개선 중)
    • importExternalTexture 미지원으로 디코더에서 GPU로의 영상 데이터 직접 읽기 불가(버그 1827116, 개발 진행 중)
  • 실사용에서 문제가 발생하면 Bugzilla WebGPU 컴포넌트에 상세 내용을 첨부해 제보 필요

앞으로의 계획

  • Windows 이후 Mac, Linux, Android 순으로 정식 지원 확대 예정
  • 성능, 호환성, 표준 준수 등 지속 개선 계획
  • WebGPU의 정식 지원을 통해 웹 애플리케이션의 새로운 가능성이 열릴 것으로 기대
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 정말 기대되는 소식임, Firefox 팀에게 축하 인사 전함
    내 회사는 Unreal을 브라우저에서 실행할 수 있도록 개발 중이며, Unreal Engine 5에 맞춘 커스텀 WebGPU RHI를 구축했음
    기술 데모를 직접 보고 싶은 사람들은 아래 링크 참고 바람
    (데스크톱의 Chromium 기반 브라우저와 일부 안드로이드 폰에서만 작동함)
    Cropout: https://play-dev.simplystream.com//…
    Car configurator: https://garage.cjponyparts.com/

    • Firefox 142 (nightly)에서 테스트해 봤음
      Cropout은 오랫동안 0%에 머물러 있으면서 1200개 이상의 네트워크 요청이 있었음
      결국 메뉴까지는 로드되는데 배경이 검은색이고 UI 요소만 보임
      쉐이더 파싱 시 많은 에러가 발생했고 기타 에러들도 있었음
      Car configurator는 여러 에러를 내며 0%에서 멈추고 로드가 되지 않음
      "게임 파일이 누락되어 전역 셰이더와 콘텐츠 초기화가 어렵다"는 메시지가 뜸
      Firefox에서도 최소한의 테스트 후 공유했으면 하는 바람임

    • "Chromium 기반 브라우저에서만 작동"이라고 밝혔지만, 이 글이 바로 Firefox의 WebGPU에 관한 이야기이므로
      혹시 Firefox 호환 버전을 테스트하거나 출시할 계획이 있는지 궁금함

    • Pixel 7a에서 Android Chrome으로 "cropout"을 실행해 보니 0%에서 멈춤
      "car configurator"는 97~98%까지 진행되지만 그 이후로 더 이상 진행되지 않음

    • Firefox 141을 사용하는 Windows에서 동작하는지 궁금함
      아니라면 그 이유가 무엇인지 알고 싶음

    • macOS용 Google Chrome에서 첫 번째 링크는 0%에서 멈춰 움직이지 않았으며
      두 번째 데모는 98% 혹은 97%에서 멈춤
      Safari에서도 동일한 현상이 있었음

  • 지금 그래픽스 API의 상황을 보면 OpenGL 시대보다도 오히려 퇴보한 듯한 느낌임
    현대 API들은 사용의 간편함이나 진정한 의미의 포터블성, 크로스 플랫폼성을 제대로 제공하지 못한다는 생각임
    Vulkan, Metal, DirectX12 같은 다양한 그래픽스 백엔드에 맞춘 커스텀 래퍼를 만드는 건 오히려 시간 낭비에 가까움
    마치 성능을 위해 문자열 대신 char 배열로 되돌아가는 느낌과 비슷함

    • 어떤 약속이 있었는지, 누가 그런 약속을 했는지 모르겠음
      그래픽스 API 목적은 어디까지나 GPU에 최대한 빠르게 코드와 데이터를 넣는 것이지, 개발자 경험이 우선은 아니었음
      WebGPU는 브라우저 안에서 컴퓨트와 렌더를 꽤 잘 래핑해 준다고 느꼈음
      아직 완벽하진 않지만 WebGL이나 OpenGL보다 더 직관적이고 탐색성이 뛰어나다고 생각함

    • 문제를 잘 못 느끼겠음
      그래픽스 스택에는 오래 전부터 저수준 API가 존재해왔고 (예시: Mesa의 Gallium), 이제는 그것들이 표준화되었고 사용자가 직접 선택함
      고수준 API도 여전히 존재하며, OpenGL도 합리적인 플랫폼에서 지원됨
      WebGPU도 native 코드에서 꽤 쓸 수 있었음
      이런 저수준 API의 진정한 포터블성 부족은 거의 Apple과 콘솔 제조사 탓임
      다만 콘솔 제조사는 원래 협력 기대를 안 했었음

    • OpenGL 시대로부터 얻은 교훈은 모든 플랫폼이 동일한 고수준 API를 사용한다고 해서 꼭 좋은 결과를 보장하지 않는다는 것임
      결국 중요한 것은 해당 플랫폼의 하드웨어 제어를 잘 해주는 API가 있느냐임
      OpenGL을 그대로 번역해주는 래퍼가 늘 필요했고, 과거에는 이 래퍼를 피할 방법이 없었음
      각 하드웨어 타입별로 최고의 결과를 내는 방식은 실용성이 떨어짐
      진짜 중요한 것은 쉬운 번역 레이어를 제공하느냐이지
      정말 하드웨어에 딥하게 접근하고 싶으면 오히려 단순하거나 범용적인 인터페이스 대신 하드웨어에 직접 다가갈 수 있는 API가 필요함

    • OpenGL은 2.0 이후 API가 너무 복잡해졌고, WebGPU는 Vk, D3D12, Metal의 기능을 꽤나 편하게 래핑하고 있음
      OpenGL보다 훨씬 설계가 잘됐다 생각함
      별도로 D3D11과 Metalv1이 아마 사용성, 성능 면에서 가장 적당한 균형점임 (특히 D3D11의 성능은 Vulkan, D3D12에서도 따라잡기 힘듦)

    • 나 역시 동의함
      OpenGL과 CUDA 인터롭으로 계속 개발할 예정임
      Vulkan은 너무 오버엔지니어링된 복잡성에 비해 실제 사용상의 이점이 없어서 오히려 CUDA를 쓰게 됐음

  • WebGPU가 브라우저 외부 환경에서도 성공적으로 확장되어
    공식 스펙으로 다루는 사용하기 쉬운 크로스 플랫폼 API(즉, opengl의 대체재)가 되길 여전히 기대하고 있음
    하지만 Rust 쪽을 제외하면 native 코드에서 WebGPU를 쓰려는 흐름은 크지 않다고 느낌
    예를 들어 Dawn을 쓰는 대형 프로젝트는 들어본 적 없음
    아마 WebGPU가 너무 늦게 나와서 대부분 이미 dx, vulkan, metal 위에 자체 추상화 계층을 구축하고 있었기 때문이기도 함

    • 결과적으로 안 퍼질 것으로 생각함
      단순함은 조금 있지만, 기능도 많이 부족함
      Vulkan에서 옵션이 된 일부 기능(예: 렌더 패스)이 WebGPU에서는 여전히 필수임
      바인드 그룹이 정적이라 오히려 불편하고
      또 WebGPU는 여러 제한과 불필요한 요소가 있음
      예를 들어 호스트에서 버퍼 서브리전에 바로 쓸 수 없고 반드시 중간 버퍼(스테이징 버퍼)를 사용해야 함
      대안이 없어서 웹에서는 활용하겠으나, 데스크톱에선 OpenGL+CUDA 인터롭 프레임워크로 계속 진행할 예정임
      더 합리적인 현대식 그래픽스 API가 나오길 바라는 입장임
      간단하게 cuMemAlloc, cuMemcpy 정도로 끝날 작업이, 복잡한 버퍼 할당 및 바인딩, 파이프라인, 엑스플리싯 싱크, 바인딩 그룹, 디스크립터 셋 등 쓸데없는 요소들로 복잡하다면 사용하고 싶지 않음

    • WebGPU는 Vulkan만큼의 최적화와 세밀한 컨트롤을 제공하지 않으며, Vulkan만큼의 성능도 나오지 않는 편임
      Vulkan에 있는 다양한 확장(extension)들도 아직 WebGPU에서는 지원되지 않음

    • 이미 존재하는 미들웨어가 있음
      브라우저 외부에서는 굳이 WebGPU를 기다릴 필요가 없다고 생각함
      애초에 브라우저 샌드박스에 초점을 맞춘 API 디자인이 갖는 제약들이 있기 때문임

    • 이름 자체도 큰 문제였다고 생각함
      나는 순수 native 개발자라 "web gpu"라는 이름 자체를 수년간 그냥 웹 전용 기술이라 여겨서 신경 쓰지 않았는데, 막상 들어보니 오해였음

  • 우리 gpu-allocator https://github.com/Traverse-Research/gpu-allocator/ 크레이트가 훨씬 더 많은 사람들에게 알려질 것 같아 매우 기쁜 마음임
    지금까지는 wgpu의 dx12 백엔드나 자체 gpu 벤치마크 제품 evolve https://www.evolvebenchmark.com/에 썼었음
    앞으로는 더 넓게 활용될 수 있을 거라 기대함

  • macOS용 Firefox Nightly에서 이미 WebGPU를 쓸 수 있다는 사실을 이제야 알게 됨
    https://www.mozilla.org/en-US/firefox/channel/desktop/에서 mac용 나이틀리 받아서
    https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu 데모를 돌려봤고, 잘 작동했음
    이 데모는 SmolLM2 모델을 WebAssembly로 컴파일해서 구조화된 데이터 추출에 사용함
    기존에는 크롬에서만 동작한다고 생각했는데, 정식 Firefox(Stable)에서는 "WebGPU가 지원되지 않는다"는 에러가 남

    • Firefox WebGPU 팀 멤버임
      macOS 지원은 곧 정식으로 제공할 예정임
      Windows 외에도 곧 Mac, Linux, 마지막으로 Android에서도 WebGPU를 지원할 계획임

  • "Mac과 Linux, 그리고 마지막으로 Android에서 WebGPU를 지원할 계획"이라는 내용이 반갑게 느껴짐
    하지만 지금 시점에서는 큰 기대를 하긴 어려움
    Linux 브라우저에서 WebGPU 지원이 그동안 불가능했던 이유는 아마도 새로운 공격 벡터(attack surface)를 만드는 게 너무 어렵기 때문이라 생각함
    이런 복잡성이야말로 브라우저 개발을 어렵게 만든 웹 표준의 거대함을 보여주는 증거임
    넷스케이프 시절부터 이어진 설계 결정의 영향이 지금까지도 남아 웹 브라우저의 단일화, 펀딩 문제 등 걱정의 뿌리가 되는 것 같음

    • 어떤 리눅스냐에 따라 다름
      Android/Linux, WebOS/Linux, ChromeOS/Linux 등에선 이미 WebGPU가 지원됨
      다만, GNU/Linux에서 이런 작업 로드를 위한 지원은 브라우저 벤더들 입장에선 우선순위가 떨어진다는 점을 방증함

  • Linux용 구현도 기대하고 있음
    WebGPU가 나오면 해볼 만한 데모들이 있는지 궁금함

  • Firefox가 Chrome보다 먼저 Linux에서 WebGPU를 지원하게 될 것 같음

    • 사실 좀 의외임
      dawn(Google의 webgpu 구현)이 Linux에서 꽤 잘 동작하는데도 Firefox가 더 앞서서 지원하는 상황임

  • 드디어 WebGPU 지원이 시작됨에 모두에게 박수를 보냄
    Chrome에서만 WebGPU를 가지고 실험했던 것이 살짝 껄끄러웠는데
    Safari 역시 최근 프리뷰 버전에서 지원을 시작함

  • 나는 주요 프로젝트에서 거의 2년 째 wgpu를 사용 중임
    이번 WebGPU 확장으로 인해 유지보수자가 늘어나서
    18달 전에 올려둔 이슈들이 더 빠르게 해결되길 기대함
    아직 Rust는 손대지 않았지만 언젠가 직접 기여할 동기와 시간이 생기길 바람
    wgpu-native 바인딩에 의존하고 있는데 업데이트가 느리게 도달함
    예를 들어 지난 주에 드디어 v25로 갔는데 불과 며칠 전에 v26이 나온 상황임

답변달기