구글 WebGPU팀 리더의 팟캐스트

출처 : https://www.youtube.com/watch?v=CklvTsKogTg


아나운서:

오늘, 오픈 메타버스 구축하기에서...

코랑탱 왈레즈:

웹 표준은 웹에 기술을 도입하기 전에 네이티브 환경에서 기술이 통합되도록 해야 합니다.

그렇지 않으면 기술적 막다른 골목에 갇히거나 웹에서 제거함으로써 웹을 망가뜨리는 위험을 감수해야 합니다.

아나운서:

커뮤니티가 함께 오픈 메타버스를 구축하는 방법에 대해 기술 전문가들이 논의하는 오픈 메타버스 구축하기에 오신 것을 환영합니다. 패트릭 코지와 마크 쁘띠가 진행합니다.

마크 쁘띠:

안녕하세요, 메타버스 구축자, 몽상가, 개척자 여러분, 다시 오신 것을 환영합니다. 저는 마크 쁘띠이고, 이쪽은 제 공동 진행자 패트릭 코지입니다.

패트릭 코지:

안녕하세요, 마크, 함께하게 되어 기쁩니다. 오늘은 제가 좋아하는 분들과 함께 제가 가장 좋아하는 주제에 대해 이야기해 보겠습니다.

마크 쁘띠:

네, 좋습니다. 여러분은 오픈 메타버스 구축하기 시즌 5를 듣고 계십니다. 아시다시피 이 팟캐스트는 오픈 가상 세계와 특수 컴퓨팅으로 향하는 여러분의 포털입니다.

우리는 미래의 몰입형 인터넷, 모두를 위한 개방적이고 상호 운용 가능한 메타버스를 구축하는 최전선에 있는 사람들과 프로젝트를 소개합니다.

패트릭 코지:

오늘 우리는 그 임무에 함께할 두 명의 특별한 손님을 모셨습니다. 그들은 수년 동안 WebGL 및 WebGPU 작업을 통해 웹에서 그래픽 프로그래밍에 큰 기여를 해왔습니다.

Google의 켄 러셀과 코랑탱 왈레즈를 환영해 주세요.

마크 쁘띠:

이미 짐작하셨겠지만, 이 에피소드는 웹 브라우저와 3D 그래픽에 관한 것입니다.

본격적으로 들어가기 전에, 우리 게스트들에게 메타버스로 향하는 그들만의 여정에 대해 들어보겠습니다.

켄, 먼저 당신부터 시작해 볼까요?

켄 러셀:

안녕하세요, 저는 켄입니다. 저는 여전히 WebGL 워킹 그룹의 의장을 맡고 있으며 Google에서 WebGL WebGPU 팀을 관리하고 있습니다.

메타버스로 향하는 여정이라... 제가 업계에서 처음 맡은 일은 Silicon Graphics에서 인턴으로 PC용 웹 브라우저의 Cosmo Player 버벌 플러그인 작업을 한 것입니다.

코랑탱 왈레즈:

안녕하세요, 저는 코랑탱 왈레즈입니다. 2017년부터 WebGPU 그룹의 공동 의장을 맡고 있으며 Chromium의 WebGPU 구현 기술 책임자입니다.

제 메타버스 여정은 아마도 다른 많은 사람들처럼 다양한 MMORPG로 시작되었을 것입니다. 제 경우에는 MUD, 즉 멀티 유저 던전이었습니다. 이름이 정확히 기억나지는 않지만, 어렸을 때는 그것이 제 메타버스였습니다.

패트릭 코지:

켄, WebGL 워킹 그룹 의장을 맡고 있다고 언급하셨는데요, 먼저 큰 감사와 찬사를 보내고 싶습니다.

저는 당신이 수년 동안 매우 포괄적인 커뮤니티를 구축했다고 생각합니다. 우리가 glTF로 했던 작업은 당신의 커뮤니티 구축과 문화에서 영감을 받았습니다.

켄 러셀:

감사합니다. 우리는 때로는 느리게, 때로는 빠르게, 모든 것을 우호적이고 존중하며 앞으로 나아가도록 노력합니다.

마크 쁘띠:

네, 그건 정말 중요합니다. 그 노고에 감사드립니다.

Google은 방금 Chrome에 WebGPU를 출시했습니다. 왜 그게 그렇게 중요한지 말씀해 주시겠어요?

코랑탱 왈레즈:

그것은 중요합니다. 왜냐하면 첫째, 개인적으로 6년 이상의 엔지니어링 작업 끝에 이룬 이정표이기 때문입니다. 하지만 Google 팀과 W3C의 표준 기구에서 집단적으로 생각해 보면, 지금까지 1세기가 아니라면 수십 년 동안의 엔지니어링 작업이었을 것입니다.

WebGPU의 좋은 점은 웹 그래픽을 한 단계 끌어올린다는 것입니다. 일반적으로 그래픽과 GPU 컴퓨팅을 말이죠. WebGPU의 핵심 기능은 컴퓨팅 셰이더를 제공한다는 것입니다. 컴퓨팅 셰이더는 WebGL로 할 수 있었던 것과 비교하여 임의의 계산을 수행하려는 경우 GPU의 병렬 특성을 나타내는 더 나은 방법이며, 훨씬 더 많은 작업, 훨씬 더 많은 알고리즘, 훨씬 더 많은 유연성, 잠재적인 성능 향상 등을 수행할 수 있습니다.

또 다른 좋은 점은 WebGPU가 새로운 종류의 그래픽 API, 즉 현대적이라고 부르는 오래 지속될 API를 기반으로 구축되었기 때문에 견고한 기반을 가지고 있다는 것입니다. 그리고 다른 한편으로는 웹을 우선으로 구축되었기 때문에 WebGL에서 보는 것보다 더 관용적입니다.

패트릭 코지:

채택에 대해 이야기해 보겠습니다. 저는 사람들이 매우 미래 지향적이고 혁신적이기 때문에 웹 프로그래밍을 좋아합니다. 그리고 Babylon과 Three와 같은 엔진이 있어서 빠르게 채택할 것입니다. WebGPU 채택이 어떻게 진행되고 있는지 궁금합니다.

코랑탱 왈레즈:

WebGPU는 출시되기도 전에 채택되었습니다. Babylon을 언급하셨는데요, 그들은 우리가 사양을 출시하고 Chrome에서 첫 번째 구현을 출시하기 몇 년 전에 기본적으로 전체 WebGPU 백엔드를 구축했습니다. 즉, 그들은 우리가 가끔 해야 했던 변경 사항을 따라잡아야 했지만, 모든 것이 작동했습니다.

지금 Babylon은 WebGPU를 완벽하게 지원한다고 생각합니다. Three와 같은 다른 프레임워크는 WebGPU 지원 작업을 하고 있습니다. 아직 완료되지는 않았지만 확실히 진행 중입니다. TensorFlow.js와 같은 것들은 자체적으로 WebGPU를 선택했으며 WebGPU에서 훨씬 더 빠르게 작업을 실행할 수 있습니다. 이전보다 훨씬 더 많은 최적화를 수행할 수 있습니다.

켄 러셀:

우리는 특히 WebGPU 백엔드에서 1년 넘게 Unity와 협력해 왔습니다. 웹으로 WebGL을 내보내는 데 있어 오랜 파트너십이 있었고, 이제 그들은 완전한 기능을 갖춘 WebGPU 백엔드를 구축했으며 WebGL로는 할 수 없는 파티클 시스템, 비주얼 이펙트 그래프와 같은 기능을 추가하는 데 열중하고 있습니다.

이러한 것들은 컴퓨팅 셰이더와 읽기-쓰기 저장 텍스처를 기반으로 하며, 다른 팀원들이 기꺼이 구현했고 Intel이 매우 빠르게 기여했습니다. 우리는 기능을 추가하고 있습니다. OpenGL 파이프라인에서 훨씬 더 복잡했을 WebGPU 프레임워크에 추가하는 것은 간단합니다.

코랑탱 왈레즈:

하지만 그 외에도 훨씬 더 많은 것이 있습니다. 예를 들어 PlayCanvas는 엔진에서 WebGPU를 지원한다고 발표했으며 훨씬 더 효율적으로 클러스터 조명을 수행할 수 있습니다. WebGPU를 사용하는 데모가 여기저기서 튀어나오는 것을 볼 수 있습니다. 많은 프레임워크가 이를 사용하기로 선택하고 있습니다. 네이티브와 웹에 걸쳐 있는 머신 러닝 툴박스인 Apache TVM도 떠오릅니다.

내부적으로 많은 사람들이 WebGPU를 사용하려고 합니다. Earth는 오랫동안 포트를 가지고 있었고 Meet는 포트 작업을 하고 있습니다. 물론 여기서 목표는 단순히 포트를 만드는 것이 아니라 WebGPU를 통해 얻을 수 있는 개선 사항을 얻는 것입니다. Skia는 WebGPU로 이식되고 있지만 웹이 아니기 때문에 나중에 다시 다루겠습니다. 그 외에도 훨씬 더 많은 것이 있습니다.

마크 쁘띠:

다른 웹 브라우저에서도 WebGPU가 채택될 것으로 예상하시나요?

코랑탱 왈레즈:

네, 물론입니다. WebGPU는 처음부터 다른 브라우저와의 협력적인 노력이었습니다. WebGPU 그룹은 실제로 Apple에서 만들었고 Microsoft, Mozilla, Intel과 같은 많은 다른 회사들이 많이 기여하고 있습니다. Firefox는 WebGPU를 빠르게 구현하고 있으며 곧 출시하려고 합니다. 물론 정확한 일정은 알 수 없지만, 그들은 정말 열심히 노력하고 있으며 몇 가지 플래그를 사용하여 WebGPU 지원을 테스트할 수 있습니다. 그들은 꽤 많이 진행했습니다.

Safari는 진행 상황에 대해 언급하지 않지만 오픈 소스 저장소를 보면 WebGPU 디렉터리에서 많은 작업이 진행되고 있음을 알 수 있습니다. 그래서 그들은 작업 중입니다. 언제 출시할 예정인지, 출시할 예정인지조차 알 수 없지만, 그들은 매우 적극적으로 참여하고 있습니다.

켄 러셀:

OpenGL 상태 머신은 30년 동안 실시간 그래픽 영역에서 우리 모두를 발전시켰으며 놀라운 혁신이었지만, 하나의 큰 상태 머신입니다. 그리고 어려운 점은 다른 애플리케이션과 다른 라이브러리를 함께 구성하는 것입니다. 왜냐하면 이들 중 어느 것도 다른 애플리케이션이 설정하는 그래픽 상태에 대해 아무것도 모르기 때문입니다.

필연적으로 수많은 사용자 생성 콘텐츠를 가져와야 하는 메타버스와 같은 하나의 큰 애플리케이션으로 결합하려고 하면 모든 상태 설정을 추상화하고 이러한 것들이 잘 상호 운용되도록 하는 것이 매우 어렵고 비용이 많이 들며 때로는 불가능해집니다. WebGPU는 새로운 현대적인 API를 기반으로 구축되었으며 상태 비저장입니다. 이는 큰 진전이며 실제로 함께 상호 운용될 더 많은 라이브러리나 작은 코드 조각과 유용한 기술을 작성할 수 있게 해 줄 것입니다.

우리는 이미 이러한 파트너십 중 일부에서 더 잘 협력하고 WebGPU 도우미 라이브러리를 더 쉽게 선택할 수 있다는 것을 보고 있습니다.

패트릭 코지:

켄, 개발자 경험에 대한 좋은 지적이라고 생각합니다. API가 더 현대적이고 오늘날의 GPU를 더 잘 나타냅니다. 또한 컴퓨팅 셰이더에 액세스할 수 있다는 것은 엣지에서 그 수준의 컴퓨팅을 얻는 데 있어 획기적인 일입니다.

개발자 경험과 관련하여 도구든 다른 것이든 더 하고 싶은 말씀이 있으신가요? 사람들이 꽤 빨리 시작할 수 있는 것 같아서요.

코랑탱 왈레즈:

사양과 구현 모두에서 개발자 경험에 노력을 기울였습니다. 사양에는 개발자를 돕기 위한 멋진 기능이 많이 있습니다. 예를 들어 명령이나 명령 버퍼의 개체나 부분에 태그를 지정하는 것과 같은 기능입니다. 그런 다음 Chromium에서는 실행 가능한 오류 메시지를 제공하기 위해 정말 많은 노력을 기울입니다. 오류 메시지가 버그를 빠르게 찾을 수 있을 만큼 충분한 정보를 제공하지 않는 경우 버그로 취급합니다.

언젠가는 GPU 디버거를 갖고 싶지만, 그것은 엄청난 노력입니다. 또한 우리 마음속에 떠오르는 것입니다. 하지만 적어도 지금은 오류 메시지, 약속 통합, 다른 HTML 항목을 WebGPU로 가져오는 것을 정말 쉽게 만드는 것과 같은 것들을 통해 개발자 경험을 좋게 만들려고 노력하고 있습니다. 예를 들어 제로 카피 비디오 가져오기는 코드 5줄 이하이며 대부분 그냥 작동합니다. 개발자 경험은 우리가 집중하는 것입니다.

또 다른 점은 WebGPU가 이미 큰 생태계라는 것입니다. 사양과 이를 구현하는 브라우저가 있지만, 많은 사람들이 튜토리얼, 블로그 게시물 등을 작성하고 있습니다. 또한 Chrome과 Firefox의 두 가지 구현은 네이티브에서 자체적으로 사용할 수 있는 네이티브 라이브러리로 분리되어 있습니다. 사람들은 그것을 사용합니다. 하지만 그것을 사용하면 Emscripten을 사용하여 WebGPU를 네이티브로 사용하는 네이티브 애플리케이션을 웹으로 컴파일할 수 있습니다. 그래서 작동합니다.

하지만 반대로, 우리는 또한 이 라이브러리를 사용하여 WebGPU에 대한 Node.js 바인딩을 만들었습니다. 따라서 브라우저에서 실행되는 JavaScript가 있으며 서버에 배치하면 서버에서 WebGPU를 실행할 수 있습니다. 물론 이 모든 것이 정확히 우리가 원하는 대로 정해진 것은 아닙니다.

하지만 Emscripten은 여전히 약간 유동적입니다. Node.js는 여전히 약간 유동적이지만 큰 생태계를 위한 기반이 마련되어 있습니다. 그것은 우리에게 정말 소중한 것입니다. 사양만이 아니라 개발자 커뮤니티를 구축하는 것입니다.

마크 쁘띠:

네이티브 애플리케이션에 WebGPU를 사용하려는 사람은 누구일까요? 거기에 몇 가지 흥미로운 사용 사례가 있을 것입니다.

코랑탱 왈레즈:

WebGPU 네이티브를 사용하려는 애플리케이션 중 하나는 예를 들어 Chromium입니다. Chromium은 Skia라는 라이브러리를 통해 모든 2D 렌더링에 GPU를 사용합니다. 우리는 차세대 Skia의 GPU 알고리즘을 Chrome에 도입하려고 하고 있으며 Graphite라고 부를 수 있습니다. 우리가 이 작업을 수행하는 방법은 Chromium의 WebGPU 라이브러리 위에 Graphite를 구축하는 것입니다. Chrome의 2D 렌더링은 Chromium의 WebGPU 라이브러리를 거칩니다. 이는 WebGPU가 다양한 GPU API를 위한 이식성 계층이기 때문에 유용합니다.

오늘날 GPU를 사용하는 라이브러리나 소프트웨어를 만드는 경우 Vulkan에 대해 배우고 Vulkan 렌더러를 작성한 다음 D3D12 렌더러를 작성한 다음 메탈 렌더러를 작성해야 합니다. 농담으로 Vulkan에서는 페라리 자동차를 만들 수 있는 모든 부품을 제공하지만 직접 만들어야 합니다. 정말 정말 어렵습니다.

WebGPU는 이식성이 뛰어날 뿐만 아니라 훨씬 더 간단합니다. 이 모든 것이 결합되어 WebGPU를 네이티브로 사용하는 것이 매우 흥미롭다는 것을 의미합니다. 이식성을 유지하고 GPU를 사용하기 위한 개발 비용이 절감되므로 고급 최적화에 더 집중하고 WebGPU 구현이 다른 모든 것을 처리하도록 할 수 있습니다.

마크 쁘띠:

말이 됩니다. 그래서 일종의 추상화 계층이군요.

코랑탱 왈레즈:

Rust 세계를 보면 WebGPU는 이미 Mozilla의 WebGPU 구현을 사용하는 네이티브의 사실상 그래픽 API입니다.

정말 흥미롭습니다.

패트릭 코지:

그런 점에서 웹 개발의 미래를 어떻게 보시나요?

Rust로 개발한 다음 WebAssembly를 사용할까요? TypeScript로 작성할까요? 아니면 조합일까요? 어떻게 될까요?

켄 러셀:

저는 그 모든 것이 될 것이라고 생각합니다. WebAssembly의 도입과 네이티브 언어를 웹으로 컴파일할 수 있는 기능으로 최근에 발전해 온 방식의 아름다움은 웹 API와 정말 잘 상호 운용된다는 것입니다. 어딘가에 있는 헤더에 잘 정의된 것으로 C 함수를 호출하는 것처럼 보입니다. 종종 웹 내부에서 컴파일한 다음 다시 컴파일할 수 있으며 그냥 실행됩니다. JavaScript와 어느 정도 TypeScript를 사용한 웹 개발의 빠른 반복은 웹이 아닌 애플리케이션 및 웹이 아닌 언어로 개발하는 것에 비해 생산성을 크게 높입니다.

정말 상호 운용성이며 코드의 일부를 웹 외부에서 개발하고 스크립트로 식별하여 가져올 수 있는 기능입니다. 이는 엄청난 이점입니다.

Java 시대를 되돌아보세요. Java 애플릿을 빌드했지만 반복, 다시 컴파일하는 것은 여전히 다소 고통스러웠고, 이제 웹에서 개발하는 경우 코드의 다음 버전을 보는 데 다시 로드하면 됩니다. 개발자에게는 좋은 이점입니다.

마크 쁘띠:

그럼 glTF 또는 USD는 어떤가요?

켄 러셀:

glTF는 개방형 표준이며 처음부터 개방형 표준으로 개발되었습니다. USD는 영화 산업을 위해 업계 전문가들이 개발한 훌륭한 기술이며, 그 주변에 커뮤니티를 개발하고 더 개방적으로 만들기 위해 노력하는 모습을 보니 좋습니다. 동시에 USD 커뮤니티는 glTF를 개발하는 데 들어간 모든 혁신을 인식하고 웹과 솔직히 메타버스를 위한 훌륭한 전달 수단으로 채택하고 적어도 마지막 마일 전달을 위해서는 아니더라도 교환을 위해 채택했어야 했다고 생각합니다.

패트릭 코지:

켄, 거기서 전달에 대한 정말 흥미로운 지적을 하셨는데요, 마크와 저는 메타버스 표준 포럼 내에서 USD의 사용 사례와 glTF의 사용 사례에 대한 정보를 커뮤니티 간에 공유하기 위해 많은 노력을 기울이고 있었습니다. 아마도 우리는 코드 변환과 상호 운용을 할 수 있을 것입니다.

웹 전달에 효율적이고 적합하다고 생각하는 USD의 하위 집합이 있다고 생각하시나요, 아니면 올바른 경로는 마지막 마일을 위해 glTF로 코드 변환하는 것이라고 생각하시나요?

켄 러셀:

저는 USD 전문가가 아닙니다. 저는 USDZ가 그 하위 집합이라는 것을 어렴풋이 알고 있습니다. 제가 아는 한, 사람들이 리버스 엔지니어링을 할 정도로 잘 지정되어 있지는 않습니다. 그리고 three.js 프로젝트를 운영하는 팀원 Ricardo Cabello는 three.js용 USDZ 내보내기를 작성하여 기본적으로 장면과 자산을 glTF로 작성한 다음 한 번의 클릭으로 iOS의 Quick Look으로 내보내고 즉석에서 해당 세트의 재료와 자산을 보는 데 필요한 USDZ를 생성할 수 있습니다.

어쨌든, 솔직히 말해서 USDZ, 특히 glTF 전문가는 아닙니다. 그래서 패트릭, 당신이 glTF에 도입한 혁신은 셰이더를 재료로 사용하는 것에서 벗어나는 것이었습니다. 이것이 glTF 1이었습니다. 그것은 요약하자면 WebGL과 같았고, 모든 것이 셰이더와 기하 도형에 싸여 있었고, 모든 것이 같은 파일에 있었습니다.

그리고 문제는 구성할 수 없다는 것이었습니다. 이러한 셰이더는 같은 장면에서 상호 운용될 수 없습니다. 당신과 Microsoft는 혁신을 개발했는데, 그것이 바로 glTF-PBR 모델이었고, 그것은 갑자기 모든 재료를 물리 기반으로 만들고 glTF 자산의 출처에 관계없이 같은 장면에서 쉽게 구성할 수 있게 했습니다. 그것이 메타버스에 여러 장소에서 많은 자산을 가져오기 위해 필요한 선구자, 전조입니다.

저는 그 핵심 혁신이 이미 존재하고 있으며 몇 년 동안 존재해 왔다고 생각하며, 솔직히 업계가 그냥 그것을 따라갈 수 있다고 생각합니다. 또 다른 장점은 웹에서 이제 JavaScript에 CPU 대역폭이 있고 WebGPU로 GPU에 많은 데이터를 전송하여 스키닝과 같은 작업을 GPU에 완전히 오프로드할 수 있다는 것입니다.

우리는 메타버스 사이트에서 웹 플랫폼에서 이러한 자산을 효율적으로 변경하여 기본적으로 glTF 자산을 기반으로 모든 것을 구축할 수 있다고 생각합니다.

패트릭 코지:

저는 또한 2012년에 GLSL을 재료로 정말 원했던 유죄인이기도 하지만, 그런 다음 Microsoft가 확실히 우리를 설득했고, 우리는 PBR의 길을 보았고, 많은 사람들이 오늘날의 모습을 위해 기여했습니다.

스키닝과 같은 작업을 위해 언급하신 것처럼 엣지의 컴퓨팅 성능만 해도 그렇습니다. 서브서피스 스캐터링과... 죄송합니다. 서브서피스 스캐터링뿐만 아니라 세분화 표면에 대한 이야기도 있습니다. 런타임 효율성은 10년 전에 비해 흥미로운 대화 주제라고 생각합니다. 왜냐하면 첫째, 더 많은 컴퓨팅을 사용할 수 있기 때문입니다.

마크 쁘띠:

여러분이 그래픽 전문가라는 것은 알지만, 웹의 즉각적인 액세스와 스토어에 대한 모든 대화 때문에 여기서 가상의 대화를 실행하기 위해 브라우저 전반에 대해 다시 한 번 생각해 보겠습니다.

저는 단기적으로, 심지어 장기적으로도 3D를 위한 웹 브라우저의 역할에 대해 많은 의문이 있다고 생각합니다. 우리는 인터넷이 가상 세계를 포용하는 것을 보고 있습니다. 그래서 여러분에게 그것에 대해 생각해 보는 연습을 해 보라고 요청하고 싶습니다.

첫 번째 질문은 정말로 이렇습니다. 저는 사용자이고, 솔직히 말해서 간단한 애플리케이션조차도 웹 애플리케이션이 항상 네이티브 애플리케이션만큼 선명하지는 않습니다. Outlook에서 그런 것을 볼 수 있습니다. 예를 들어 보겠습니다. 환상적인 웹 앱이 있지만 데스크톱 앱만큼 선명하지 않습니다. 그럼 WebGPU가 도움이 될까요?

그 격차를 어떻게 해소할 수 있을까요? 아니면 그 격차가 영원히 존재할까요?

켄 러셀:

반례를 하나 들어보겠습니다. Figma. Figma는 처음부터 웹 기본 요소 위에 구축된 디자인 애플리케이션입니다. 모양 렌더링은 이전 Figma CTO인 Evan Wallace가 WebGL로 구축했으며, 셰이더를 사용하여 Illustrator가 처음부터 웹을 지원하는 것과는 다른 이러한 다중 접합 경로를 그리는 방법을 알아냈습니다. Adobe는 그것의 가치를 충분히 인식하여 "알았어, 우리는 그것들을 우리의 도구 모음에 추가할 거야"라고 말했습니다. 몇 달 전에 공개적으로 광고되었습니다. WebGL 생태계를 200억 달러 이상으로 만드는 Figma의 가치는 200억 달러입니다.

요점은 웹 애플리케이션을 네이티브 애플리케이션과 구분하는 것이 정말 선명도나 느림 또는 그런 종류의 것이라고 확신하지 못한다는 것입니다. 그것은 정말로 보안 모델과 이식성 측면입니다. 이것들은 웹이 이점으로 제공하는 두 가지 주요 사항입니다.

보안 모델이 어느 정도 성능 오버헤드를 부과하고 이식성 측면이 액세스해야 할 수도 있는 API의 일부를 잘라내고 액세스하지 못하게 하거나 광범위한 장치 도달 범위를 얻기 위해 선택적 기능이어야 할 수도 있다는 것은 사실입니다. 하지만 우리의 목표는 오버헤드를 최소화하고 웹을 통해 가능한 한 가장 광범위한 장치 배포에 도달하는 것입니다. 그리고 그것이 우리가 노력하는 것입니다.

코랑탱 왈레즈:

Outlook을 보면 네이티브 애플리케이션으로 먼저 개발되었고, 네이티브 애플리케이션을 빌드하는 것은 웹 앱을 빌드하는 것과는 매우 다른 노력입니다. 데이터의 대부분이 필요에 따라 로드해야 하는 멀리 떨어진 곳에 있기 때문입니다. 거기에는 다른 엔지니어링 문화가 있습니다.

또 다른 점은 Slack이나 Teams와 같은 다른 데스크톱 애플리케이션을 보면 실제로 웹 기술을 사용하고 있다는 것입니다. 웹 기술이 놀라운 이식성을 제공하기 때문입니다. 네이티브 앱을 빌드할 수도 있지만 Chrome 인스턴스의 고정 탭에 Slack을 넣을 수도 있습니다. 작동합니다. 웹에는 특정 유형의 애플리케이션을 더 빠르게 개발할 수 있게 해 주는 많은 도구와 개발자 편의 기능이 있습니다.

물론 React를 사용하면 원시 dom 작업을 사용하는 경우보다 속도가 느려지는 것과 같이 더 많은 오버헤드를 지불하지만 개발자 생산성을 얻고 컴퓨터는 빠릅니다. 그럴 만한 가치가 있는 트레이드오프가 될 수 있습니다.

마크 쁘띠:

저는 지난주에 새로운 iPhone이 출시된 후 "마침내 휴대폰이 그래픽에서 콘솔과 경쟁할 수 있게 되었습니다"라는 헤드라인을 몇 개 보았습니다.

저에게 질문은 이것을 기준 또는 이정표로 삼아 보겠습니다. 웹 브라우저가 콘솔과 경쟁할 수 있는 유사한 기능을 갖추려면 얼마나 걸릴까요?

코랑탱 왈레즈:

여기서 콘솔과 경쟁하는 것은 기본적으로 하드웨어와 브라우저의 플롭스에 관한 것이라고 생각합니다. 물론 Raspberry Pi에서 브라우저를 실행하면 Xbox Series X와 경쟁할 수 없을 수도 있지만 Nintendo 64와는 경쟁할 수 있을 것입니다. 브라우저를 통해 충분한 하드웨어 성능에 액세스할 수 있는지 여부가 더 중요합니다. 그리고 그것은 상황에 따라 다릅니다. 브라우저는 이식성 때문에 기능 면에서 항상 네이티브보다 뒤처질 것입니다.

웹 표준은 웹에 기술을 도입하기 전에 네이티브 환경에서 기술이 통합되도록 해야 합니다. 그렇지 않으면 기술적 막다른 골목에 갇히거나 웹에서 제거함으로써 웹을 망가뜨리는 위험을 감수해야 합니다. 그것은 끔찍할 것입니다.

우리는 상황이 합쳐지기를 기다려야 합니다. 우리는 충분히 좋은 콘솔 수준의 품질에 도달할 수 있다고 생각합니다.

마크 쁘띠:

저는 확신합니다. 실제로 다음 대화를 통해 모든 사람이 브라우저에서 Fortnite와 같은 것을 하는 것과 그리 멀지 않다고 생각합니다. 요소가 있는 것 같고, AAA 게임은 아니지만 AAA에 가까운 그 정도 품질의 게임을 갖추고 그 정도의 멀티 유저를 갖는 것은 놀라운 업적이 될 것이라고 생각합니다.

코랑탱, 그렇게 하는 데 필요한 모든 구성 요소를 살펴볼 수 있을까요?

코랑탱 왈레즈:

맞습니다. Fortnite와 같은 것을 언급하셨는데요, 오늘날 웹의 그래픽 기능 면에서 보면 우리는 확실히 Fortnite와 같은 것을 실행하는 데 필요한 것을 갖추고 있습니다. Fortnite는 성능이 떨어지는 휴대폰에서도 실행할 수 있지만 웹은 이미지 품질, 렌더링, 잠재적으로 GP 성능 면에서 데스크톱 Fortnite의 품질에 도달할 수도 있습니다.

이제 Fortnite와 같은 것을 만드는 데 중요한 것은 렌더링과 관련된 모든 것입니다. 까다로운 부분은 자산을 스트리밍하는 것입니다. 사용자가 동시에 다른 여러 곳에서 웹을 탐색하는 경우 브라우저에 항목을 캐시된 상태로 유지하려면 어떻게 해야 할까요? 입력 지연 시간이 있습니다. 페이지에서 페이지로 이동할 때 사용자 인증을 처리하는 방법은 무엇일까요? 핵심 주변의 이러한 모든 제약 조건은 계산으로 이어집니다. 그것이 어려운 부분입니다.

예를 들어 Cesium과 같은 것은 이를 위해 스트리밍 사용 사례를 멋지게 해결하려고 하거나 해결합니다. 따라서 필요한 브레이크 중 하나이지만 다른 브레이크도 있습니다.

마크 쁘띠:

컴퓨팅 성능 면에서 우리는 멀티스레드 기능을 잘 지원하는 WebAssembly를 가지고 있습니다. 그것은 좋은 향상이 될 것입니다.

여러분은 WebAssembly가 WebGPU와 함께 발전하는 옵션으로 보시나요, 아니면 어떻게 보시나요?

켄 러셀:

물론입니다. 브라우저의 Google Earth와 아마도 Cesium도 이미 멀티스레드이며, 그렇게 함으로써 성능상의 이점을 보고 있습니다. Earth의 싱글스레드와 멀티스레드 빌딩을 비교하면 멀티스레드로 실행할 때 훨씬 더 부드럽습니다. WebGPU는 기본적으로 처음부터 멀티스레딩을 위해 설계되었습니다.

물론 JavaScript API 수준에서조차 아직 완벽하지는 않습니다. API의 몇 가지 측면은 조정해야 합니다. 하지만 우리 팀은 이미 네이티브 수준에서 멀티스레딩 구현 작업을 하고 있으며, 텍스처 로딩과 아마도 기하 도형 업로드를 다른 스레드에 오프로드할 수 있기 때문에 네이티브 API 수준에서 보고 있는 오버헤드 감소를 웹에서 결국 얻을 수 있을 것으로 기대합니다.

특정 플랫폼에 맞게 튜닝하여 웹에서 쉽게 할 수 있는 것에 점점 더 가까워지고 있다고 생각합니다. Wasm은 멀티스레딩을 사용하고 렌더링을 위해 WebGPU를 사용하고 아마도 여러 스레드에서 동시에 액세스하여 Wasm이 정의한 이식 가능한 SIMD 하위 집합을 사용합니다.

이는 본질적으로 싱글스레드 API인 WebGL로 가능했던 것에 비해 큰 진전입니다. API의 의미를 너무 많이 변경하여 작동하지 않았기 때문에 여러 WebGL 컨텍스트 경로를 선택하지도 않았습니다.

패트릭 코지:

이 혼합된 생태계를 보시나요? 예를 들어 오늘날 Google이 수행한 Draco 메쉬 압축 해제가 있고 브라우저에서 이를 사용하기 위한 WebAssembly가 있을 수 있습니다.

하지만 Google이 수행한 Filament과 같은 전체 엔진이나 전체 애플리케이션을 작성하는 사람들도 있습니다. 그런 다음 WebAssembly는 전체를 브라우저에 넣습니다.

켄 러셀:

이것은 절대적으로 많은 사람들이 이용하고 싶어할 방향이라고 생각합니다. 네.

Unity의 특정 사용 사례를 언급해도 될까요? 그들은 WebGPU 백엔드에서 작업하고 있었고 전체를 실행했지만 몇 가지 문제를 파악할 수 없었고 무시무시한 검은색 화면 버그가 발생했습니다. 오, 아니, 컴퓨터 그래픽의 검은색 화면. 뭐죠? 조명을 켜는 것을 잊었나요? 카메라가 잘못된 방향을 향하고 있나요? 최종 프레임 버퍼 블립이 깨졌나요? 잘못될 수 있는 것이 너무 많습니다. 그리고 브라우저 내 Wasm 개발 경험은 아직 부족했고, 버그가 어디에 있는지 정확히 파악할 수 없었습니다. 그래서 웹 앱을 네이티브로 다시 이식하고 Chromium의 네이티브 WebGPU 구현인 Dawn을 엔진과 함께 네이티브 애플리케이션으로 빌드했습니다.

Visual Studio에서 디버깅하여 API 사용에서 정당한 몇 가지 버그를 발견했습니다. 그들은 그것들을 수정한 다음 웹용으로 다시 컴파일했고 그냥 작동했습니다. 이것이 바로 이 결합된 네이티브 및 웹 개발 환경의 힘입니다. 개발이 어디에서 이루어지는지 정말 걱정할 필요가 없습니다.

가장 적합한 곳에서 작업한 다음 웹으로 원활하게 가져올 수 있습니다.

코랑탱 왈레즈:

반면에 어떤 이유로 JavaScript 엔진을 만들고 있고 압축 해제를 위해 WebAssembly 모듈을 사용하거나 Filament을 사용하고 싶지만 엔진의 나머지 부분은 JavaScript에 있는 경우 함수 호출을 수행하고 JavaScript와 WebAssembly 간에 데이터를 전달하여 이를 실현할 수 있습니다.

과거에는 이것이 괜찮았고 충분히 괜찮았지만 가장 유용하지는 않았습니다. 하지만 요즘에는 몇 년 전에 출시된 첫 번째 WebAssembly MVP 이후 Wasm과 JS

=======================

마크 쁘띠:

서버 측 Node.js가 잠재적으로 GPU 가속을 받을 수 있다고 언급하셨고, WebSocket 및 WebRTC와 같은 기술이 있습니다. 멀티 유저의 지연 시간에 대해 언급하셨습니다.

모든 재료가 있는 것 같고, 질문은 그것들을 함께 넣으면 적절한 수준의 성능을 얻을 수 있느냐는 것입니다. 개인적으로 브라우저 기반 게임을 더 많이 볼 수 있기를 바랍니다. Three.js, Babylon.js, PlayCanvas와 같은 훌륭한 엔진이 있는데도 그렇다는 것이 매우 놀랍습니다.

브라우저에서 훨씬 더 많은 멀티 유저 3D 경험을 보게 될 것으로 예상하시나요? 그런 일이 일어날 것이라고 보시나요?

코랑탱 왈레즈:

우리는 그런 일이 일어나는 것을 보고 싶고, 점점 더 많이 일어나고 있습니다.

켄 러셀:

dotbigbang.com을 보면 브라우저 내 멀티 유저 구성 및 멀티플레이어입니다.

코랑탱 왈레즈:

하지만 이것이 있고 순수하게 웹 기반인 다른 게임도 있으므로 그런 일이 일어나기 시작했습니다. 하지만 웹 게임을 살펴본 파리 사무실의 몇몇 사람들과 이야기를 나눠 보면, 웹 게임의 주요 문제는 입력, 지연 시간, 비디오 또는 그래픽 등을 수행하는 API에 관한 것이 아닙니다. 문제는 발견 가능성, 수익 창출, 사용자 신원입니다.

예를 들어 휴대폰에서 게임을 하고 싶다면 앱 스토어를 열고 게임을 다운로드합니다. 데스크톱에서 게임을 하고 싶다면 Steam 또는 Epic Games 스토어를 열고 게임을 찾아서 플레이합니다.

웹에서 게임을 하고 싶다면 어떻게 해야 할까요? Google에서 게임 이름을 검색할 수도 있지만 통합되어 있지 않으므로 발견 가능성 문제가 있습니다.

웹에서의 수익 창출 또한 일반적으로 광고 기반이기 때문에 다릅니다. 웹 사용자는 무료 콘텐츠를 기대합니다. 따라서 이는 또 다른 과제입니다.

마크 쁘띠:

결국 게이머는 좋은 게임에 끌리고, 새 URL을 전달하기만 하면 웹에서 얻을 수 있는 접근성은 매우 가치가 있을 것입니다.

코랑탱 왈레즈:

그런 면에서 Worldle과 같은 것을 게임이라고 부르시겠습니까?

사람들과 공유하기가 매우 쉽기 때문에 발견되고 공유되어 매우 인기를 얻었습니다. 물론 그래픽적으로 집약적이지는 않지만 웹의 매우 넓은 도달 범위의 이점을 누렸습니다.

패트릭 코지:

잠시 VR에 대해 이야기해 볼까요? 우리는 웹에서 WebXR을 사용하고 있는데, 상황이 어떻게 발전하고 있다고 보시나요?

코랑탱 왈레즈:

WebGPU는 아직 WebXR을 지원하지 않으며, 이는 WebGPU에서 WebGL의 마지막 몇 가지 회귀 중 하나입니다. 왜냐하면 오늘날 WebXR을 사용하려면 WebGL을 사용하거나 WebGPU를 사용하여 미친 짓(제발 하지 마세요)을 해야 하기 때문입니다. 끔찍합니다.

우리는 곧 그것을 출시하고 싶지만, 몰입형 웹 워킹 그룹에서 조금 더 작업하고 브라우저에서 구현 작업을 해야 합니다. 바라건대 곧 출시될 것이고, 바라건대 매우 유용할 것입니다.

마크 쁘띠:

오늘 브라우저에 대해 많은 이야기를 나눴으니, 이제 여러분이 수정 구슬을 꺼내 보시기 바랍니다. 항상 어려운 일입니다. 앞을 내다보겠습니다.

아시다시피, 이 팟캐스트에서는 메타버스가 인터넷이 실시간 3D와 웹을 포용한 결과라고 생각합니다.

여러분의 경험에 비추어 볼 때, 백지 상태에서 공유된 영구 가상 세계에 최적화된 인터넷 및 웹 버전을 만들라는 임무를 받았다면 어떻게 시작하시겠습니까?

켄 러셀:

현재 기술 스택을 살펴보는 것이 유익할 수 있습니다. 안정적이지 않은 패킷 전송은 저지연 게임에 매우 중요하며, 웹은 과거에 이에 액세스하는 데 어려움을 겪었습니다. WebRTC에는 UDP에 액세스할 수 있는 데이터 연결 API가 있습니다. 이는 매우 중요하지만, 이러한 것들에 액세스하기가 조금 더 쉽도록 웹 전송이 개발 중이며, 적극적으로 개발 중이며, 저는 이것이 큰 누락된 부분이 될 것이라고 생각합니다.

하지만 자산을 전달할 때는 자체적인 안정적인 전송 계층을 작성하고 싶지 않고 일반적인 가져오기를 사용하고 싶을 것입니다. 웹은 이러한 종류의 콘텐츠를 전달하는 데 매우 적합합니다. 다운로드할 매우 큰 자산을 기다리기만 하면 됩니다.

저는 여기에서 스트리밍에 대한 더 많은 작업이 필요하다고 생각하며, 게임 엔진에서 즉시 시작하고 무언가를 볼 수 있는 세부 수준 내보내기가 필요하며, 그런 다음 반복적으로 더 높은 해상도, 텍스처 및 자산을 얻을 수 있습니다.

즉, 전송 통신 계층의 한 측면입니다. 저는 웹에서 이러한 종류의 기술이 이미 정말 좋다고 생각합니다. 왜냐하면 이미 웹 콘텐츠를 제공하는 일종의 서버가 있기 때문입니다. 일반적으로 자산을 단순히 전달하는 것과는 달리 클라이언트에 약간의 왕복을 추가하는 점진적인 델타입니다. 바라건대, 메타버스의 고유한 부분인 멀티플레이어를 기존 서버 인프라에 추가하는 것이 너무 어렵지는 않을 것입니다.

코랑탱 왈레즈:

세계 간 이동을 위한 구성 가능성은 오늘날 거의 가능해 보입니다. 예를 들어 포털을 생각해 보세요. 다른 출처의 세계에서도 가능합니다. 왜냐하면 우리는 웹사이트 간 전환 작동 방식을 제어할 수 있는 포털이라는 새로운 HTML 요소를 가지고 있기 때문입니다. 현재 있는 세계의 캔버스를 뚫고 그 뒤에 로드된 다음 URL의 캔버스를 표시하는 데 사용되는 구멍을 낼 수 있는 방법이 있을 것이라고 확신합니다.

둘 사이에 많은 동기화가 필요하겠지만 아마도 가능할 것입니다. 하지만 프로그래밍 가능한 것들을 사용하여 여러 세계를 같은 페이지에 구성하는 데는 큰 어려움이 있습니다. 보안 및 샌드박싱 문제가 있을 것이라고 생각하기 때문입니다. 따라서 이는 여전히 매우 열린 질문입니다.

켄 러셀:

단일 웹사이트에서 호스팅되는 메타버스 인스턴스에 대해 생각해 보세요. 오늘날 해야 할 일을 거의 다 할 수 있습니다. 많은 다른 출처에서 온 신뢰할 수 없는 자산과 코드를 가져와서 샌드박스 내에서 안전하게 실행할 수 있습니다. 과제 중 하나는... 웹에는 단일 출처 보안 정책이 있는데, 여러 출처에 대해 이야기할 때는 어떻게 해야 할까요?

Apple이 visionOS로 이를 해결한 방법은 공유 공간에 있을 때 모든 책임을 운영 체제에 위임해야 한다는 것입니다. 그들은 장면 그래프를 제공하며, 해당 형식으로 자산을 운영 체제에 제공해야 합니다. 프로그래밍할 수 없습니다. 더 이상 정점을 업로드할 수 없습니다. 우리가 할 수 있기를 기대하는 방식으로 동적으로 물건을 만질 수 없습니다. 정당한 이유가 있습니다.

그들은 "좋아요, 공유된 것들에 대해 어느 정도 제어해야 합니다."라고 말하고 있습니다. 저는 그것이 다중 출처 메타버스에서 큰 과제의 일부가 될 것이라고 생각합니다.

마크 쁘띠:

우리는 대화 초반에 보안 오버헤드에 대해 이야기했습니다. 우리는 차세대 브라우저에서도 여전히 이 문제를 해결해야 한다고 생각합니다.

코랑탱 왈레즈:

사용자의 보안은 브라우저의 최우선 관심사입니다. 사양에서는 이를 사용자 에이전트라고 부르는데, 그 이유는 사용자를 위한 것이기 때문입니다. 우리는 모두 브라우저를 더 안전하게 만들려고 노력하고 있습니다. 제가 모두라고 말할 때, 모든 브라우저는 가능한 한 보안 오버헤드를 줄이면서 더 안전해지려고 노력하고 있습니다. 그리고 WebAssembly는 그 방향으로 나아가는 한 걸음이었습니다.

많은 JavaScript 최적화가 그것입니다. WebGPU가 이것이며, WebGPU의 낮은 오버헤드 보안을 설계하는 데 많은 노력을 기울였습니다. 하지만 그 오버헤드는 항상 조금 있을 것입니다. 왜냐하면 그것이 웹 보안의 가장 중요한 속성이기 때문입니다.

패트릭 코지:

오늘 두 분을 모시게 되어 정말 좋았습니다. WebGPU의 이점부터 개발자 경험 및 현재 채택 현황, 웹에서 3D 자산을 전송하는 방법, 오늘날 웹 기술로 Fortnite와 같은 경험을 구축하는 데 필요한 것, 그리고 잠재적인 미래 웹 기술 스택에 이르기까지 매우 다양한 주제를 다루었습니다.

아시다시피, 우리는 외침으로 마무리하는 것을 좋아합니다. 하지만 그 전에 코랑탱과 켄, 두 분께 외침을 보내고 싶습니다.

마크, 저는 펜실베니아 대학교에서 몇 년 동안 GPU 프로그래밍 아키텍처를 가르쳤습니다. 그리고 매년 켄, 코랑탱, 섀넌, 브랜든, Chrome GPU 팀이 항상 와서 특강을 하고, 코스를 적극적으로 지원하며, 제가 가르쳤던 세 명의 훌륭한 학생인 오스틴, 카이, 트렉을 고용했습니다.

교육자로서 저는 이 학생들이 켄과 코랑탱과 함께 일하고 WebGPU와 WebGPL 또는 WebGL에 기여하고 있다는 사실에 매우 기쁩니다. 두 분께 감사드립니다.

이제 두 분께 개인 또는 조직에 대한 외침을 부탁드립니다.

코랑탱 왈레즈:

저의 첫 번째 외침은 WebGPU 워킹 그룹의 공동 의장이자 매우 적극적인 기여자인 Kelsey Gilbert에게 갑니다. 그녀는 첫날부터 함께했으며 WebGL 워킹 그룹의 의장이기도 합니다.

또한 WebGPU의 스펙 작성자이자 스펙에 많은 것을 기여한 Apple의 Myles Maxfield에게도 감사드립니다. 표준 기구에서 토론은 어려울 수 있지만, 모두 함께하면 더 나은 결과를 얻을 수 있다고 생각합니다. 그들에게 큰 박수를 보냅니다.

켄 러셀:

저는 개인적으로 상하이의 Intel 웹 그래픽 팀에 큰 박수를 보내고 싶습니다. 이 팀은 수년 동안 Chromium, 특히 그래픽 스택과 WebGPU 구현에 크게 기여했습니다.

그들의 엄청난 기여와 협력 없이는 오늘날의 우리가 없었을 것입니다. 웹에 많은 투자를 해 준 팀에 감사드립니다.

코랑탱 왈레즈:

실제로 제가 외침을 보내고 싶은 두 사람이 더 있습니다.

WebGPU는 브라우저 구현자와 같지만 기술을 중심으로 한 커뮤니티이기도 하며, 커뮤니티의 두 사람은 무언가를 만들거나 다른 사람들을 돕는 것으로 눈에 띕니다.

첫 번째 사람은 Connor Fitzgerald입니다. 그의 본업이 무엇인지는 모르지만 Firefox에서 사용하는 WebGPU 라이브러리의 관리자 중 한 명입니다. 그는 구현 방법을 파악하고, 다른 사람들이 WebGPU를 사용하거나 WebGPU 아래의 그래픽 API를 사용하도록 돕는 데 끊임없이 도움을 주었습니다. 그에게 큰 박수를 보냅니다.

다른 한 사람은 Jasper St. Pierre입니다. 그는 비디오 게임을 위한 가상 박물관인 noclip.website의 배후에 있는 사람입니다. 마찬가지로 그는 사양에 많은 기여를 했습니다. 그는 그래픽에 대한 질문이 있는 사용자를 돕고, 모범 사례를 제공하며, 커뮤니티의 기둥입니다. 정말 놀랍습니다.

마크 쁘띠:

오늘 우리와 이야기를 나누고 웹 브라우저와 3D 그래픽에서 중요한 미래 역할을 할 수 있는 웹 브라우저에 대해 조명해 주신 Google의 켄 러셀과 코랑탱 왈레즈에게 감사드립니다. 특히 여러분의 기여에 감사드립니다. 정말 감사합니다.

웹이 큰 역할을 하고, 큰 역할을 할 것이며, 메타버스가 될 것이라는 사실은 우리 모두에게 매우 중요합니다. 브라우저는 그 중요한 구성 요소입니다. 이 대화가 모든 사람에게 유익했기를 바랍니다. 정말 감사합니다.

또한 끊임없이 성장하는 청중 여러분께도 감사드립니다. 웹사이트 buildingtheopenmetaverse.org에서 피드백을 보내거나 LinkedIn 페이지, YouTube 채널 및 대부분의 팟캐스트 플랫폼을 구독할 수 있습니다.

코랑탱, 켄, 패트릭, 감사합니다.