[WebGPU]에 대해서 Araboza...(3)

본 게시글은 W3C에 게시된 WebGPU Explainer 글을 학습을 위해 번역한 글입니다.

 

3. 자바스크립트 API

  이 섹션은 WebGPU JS API의 중요하고 특이한 면들에 관한 세부 내용을 다룹니다. 일반적으로 서브 섹션은 매칭되는 상위 섹션을 설명하기 위해 만들어졌지만 몇몇 서브 섹션은 이전 서브 섹션의 문맥을 참조하기도 합니다.

3.1 Adapter와 Device

※ Adapter와 Device는 WebGPU 코드 구현의 핵심이 되는 두 개념입니다.

 GPUAdapter란 시스템에서 특정 WebGPU 구현(implementation)을 식별하는 객체입니다. (ex. 통합 또는 개별 GPU에서 하드웨어/소프트웨어 가속 구현)

  같은 페이지에서 두 개의 서로 다른 GPUAdapter 객체가 동일한 underlying implementation(system 단에서 구현된 객체를 말하는 듯??)을 참조할 수도 있고, (통합/개별 GPU와 같은) 서로 다른 두 구현체를 참조할 수도 있습니다.

  페이지에 표시되는 어댑터들은 유저 에이전트의 재량에 따릅니다.

  WebGPU Device는 WebGPU Adapter에 대한 논리적 연결을 의미합니다. "device"라고 불리는 이유는 WebGPU Device가 underlying implementation을 추상화하고 single connection을 캡슐화하기 때문입니다. * 여기서 single connection을 캡슐화한다는 말은 device의 소유자가 해당 Adapter의 유일한 사용자인 것처럼 동작한다는 의미입니다. 이 일환으로 device는 그로부터 생성된 모든 WebGPU 객체(textures, etc.)의 root 권한을 갖습니다. 따라서, device가 삭제되거나 소실되면 그 객체들은 (내부적으로) 자유로워집니다.(* owner가 없어진다.) SPA에서 multiple 컴포넌트들은 각각 자신만의 WebGPU device를 보유할 수 있습니다.

※ 하드웨어 GPU의 API를 제공하는 객체(underlying implementation으로 추정)를 GPU Adapter가 참조한다. 이 GPU Adapter를 device가 참조하고 하나의 adapter는 각 컴포넌트 별로 여러 개의 device를 인스턴스로 보유할 수 있다는 의미로 보입니다.

  모든 WebGPU의 사용은 WebGPU device와 그 객체들에서 생성되어 동작합니다. 이러한 관점에서 보면, WebGPU는 WebGLRenderingContext의 목적에 그 목적이 포함되는 셈입니다. 하지만 WebGLRenderingContext와 달리, WebGPU는 canvas(?) 객체에 연합되지 않으며 대부분의 명령어들이 자식 객체를 통하여 실행됩니다.

3.1.1 Adapter 선택과 Device 초기화

  adapter는 app에서 navigator로 호출합니다. gpu.requestAdapter()의 인자로 어떤 adapter를 선택할 지 영향을 줄 수 있는 옵션들을 전달합니다. (powerPreference()에 "low-power" 또는 "high-performance"를 인자로 주는 것처럼, 또는 forceSoftware에 소프트웨어 구현을 강제하는 것처럼)

  requestAdapter는 절대 요청을 거부하지는 않지만, 특정 옵션에 응답할 수 없는 경우 null을 반환할 수는 있습니다.

  반환된 adapter는 implementation-defined한 이름과 fallback paths가 있는 애플리케이션의 slow software implementations를 피할 수 있는 isSoftware(boolean type) 변수 등 다양한 값을 갖고있습니다.

[ 코드 예시 ]
const adapter = await navigator.gpu.requestAdapter(options);
if (!adapter) return goToFallback();

  device는 app에서 adapter.requestDevice()로 호출합니다. 마찬가지로 추가적인 옵션들을 인자로 전달합니다. adapter.requestDevice()는 요청이 유효하지 않으면(adapter의 기능을 초과하는 경우) 거절할 것입니다. device 생성 시 문제가 발생하면 이미 소실된 device로 간주할 것입니다. 이는 가능한 반환값들(null or exception type 등등..)을 배제함으로써 app에서 다루어야 할 상황들(예외 처리)을 단순화합니다.

[ 코드 예시 ]
const device = await adapter.requestDevice(descriptor);
device.lost.then(recoverFromDeviceLoss);

  시스템에서 분리되었거나 전원 절약을 위해 비활성화 되었거나 "stale" 상태(현재는 false로 변경됨)인 경우 adapter는 사용할 수 없게 될 수 있습니다. 이런 경우, adapter는 더 이상 유효한 device들을 제공할 수 없으며 항상 이미 소실된 device만을 제공합니다.

3.1.2 선택적 기능들

  각각의 어댑터들은 "features" 그리고 "limits"라는 선택적 기능들을 가지고 있습니다. 이것들(features and limits)은 device가 생성될 때, 요청할 수 있는 최대 가용 기능입니다.

  이러한 선택적 기능들을 어댑터에서 사용하는 것은 유저 에이전트의 재량입니다.

  device는 adapter.requestDevice()함수 호출 시 전달된 인수에 따라 명확한 기능들을 제공합니다.

  device에서 어떤 작업이 발생할 때, adapter의 기능이 아니라 device의 기능에 대해 엄격하게 검증됩니다. 이는 개발 시스템의 기능에 대한 암시적 의존성을 피함으로써 유연한 프로그램 개발이 가능하도록 만들어줍니다.

※ 내가 이해한 바대로 요약하자면 adapter로 하드웨어 GPU와 연결을 맺고 그 adapter를 통해 device 객체(인스턴스)를 생성한다. 결국 device별로 기능이 할당되고 해당 기능을 해당 device가 속한 컴포넌트에서 사용함으로써 캡슐화되고 유연한 개발을 가능하도록 한다.