WebGPU 셰이딩 언어

1. 소개

WebGPU 셰이딩 언어(WGSL)는 [WebGPU]의 셰이더 언어입니다. 즉, WebGPU API를 사용하는 애플리케이션은 GPU에서 실행되는 프로그램(셰이더라고 불림)을 표현하기 위해 WGSL을 사용합니다.

// 텍스처가 적용된 기하 도형에 점광원으로 조명을 비추는 프래그먼트 셰이더입니다.

// 스토리지 버퍼 바인딩에서 조명 정보를 가져옵니다.
struct PointLight {
  position : vec3f,
  color : vec3f,
}

struct LightStorage {
  pointCount : u32,
  point : array<PointLight>,
}
@group(0) @binding(0) var<storage> lights : LightStorage;

// 텍스처와 샘플러.
@group(1) @binding(0) var baseColorSampler : sampler;
@group(1) @binding(1) var baseColorTexture : texture_2d<f32>;

// 함수 인자는 버텍스 셰이더에서 전달된 값입니다.
@fragment
fn fragmentMain(@location(0) worldPos : vec3f,
                @location(1) normal : vec3f,
                @location(2) uv : vec2f) -> @location(0) vec4f {
  // 표면의 기본 색상을 텍스처에서 샘플링합니다.
  let baseColor = textureSample(baseColorTexture, baseColorSampler, uv);

  let N = normalize(normal);
  var surfaceColor = vec3f(0);

  // 씬의 점광원을 반복합니다.
  for (var i = 0u; i < lights.pointCount; i++) {
    let worldToLight = lights.point[i].position - worldPos;
    let dist = length(worldToLight);
    let dir = normalize(worldToLight);

    // 이 광원이 표면 색상에 미치는 기여도를 계산합니다.
    let radiance = lights.point[i].color * (1 / pow(dist, 2));
    let nDotL = max(dot(N, dir), 0);

    // 표면 색상에 빛의 기여도를 누적합니다.
    surfaceColor += baseColor.rgb * radiance * nDotL;
  }

  // 누적된 표면 색상을 반환합니다.
  return vec4(surfaceColor, baseColor.a);
}

1.1. 개요

WebGPU는 GPU 명령 형태로 GPU에 작업 단위를 전달합니다. WGSL은 두 가지 종류의 GPU 명령과 관련이 있습니다:

• 드로우 명령 은 렌더 파이프라인을 입력, 출력, 그리고 연결된 리소스의 컨텍스트에서 실행합니다.

• 디스패치 명령은 컴퓨트 파이프라인을 입력과 연결된 리소스의 컨텍스트에서 실행합니다.

두 종류의 파이프라인 모두 WGSL로 작성된 셰이더를 사용합니다.

셰이더는 파이프라인에서 셰이더 단계를 실행하는 WGSL 프로그램의 일부입니다. 셰이더는 다음으로 구성됩니다:

• 엔트리 포인트 함수.

• 엔트리 포인트에서 시작하는 모든 호출된 함수의 추이적 폐쇄. 이 집합에는 사용자 정의 및 내장 함수가 모두 포함됩니다. (더 엄밀한 정의는 "셰이더 단계의 함수"에서 볼 수 있습니다.)

• 해당 모든 함수들이 정적으로 접근한 변수 및 상수의 집합.

• 해당 함수, 변수 및 상수들을 정의하거나 분석하는 데 사용된 타입의 집합.

참고: WGSL 프로그램은 엔트리 포인트가 필요하지 않지만, 엔트리 포인트가 없으면 API에서 실행할 수 없습니다. 엔트리 포인트는 GPUProgrammableStage 를 생성하는 데 필요합니다.

셰이더 단계를 실행할 때, 구현체는 다음을 수행합니다:

• 모듈 범위에서 선언된 상수의 값을 계산합니다.

• 셰이더의 리소스 인터페이스에 있는 변수에 리소스를 바인딩하여, 실행 중에 해당 리소스의 내용을 셰이더가 사용할 수 있도록 만듭니다.

• 기타 모듈 범위 변수에 대해 메모리를 할당하고, 해당 메모리에 지정된 초기값을 채워 넣습니다.

• 엔트리 포인트의 형식 인수가 있다면, 셰이더 단계의 입력으로 값을 채워 넣습니다.

• 엔트리 포인트 반환값이 있다면, 셰이더 단계의 출력에 연결합니다.

• 그런 다음 엔트리 포인트를 호출합니다.

WGSL 프로그램은 다음으로 구성됩니다:

• 디렉티브: 모듈 수준의 동작 제어를 지정합니다.

• 함수: 실행 동작을 지정합니다.

• 문장: 선언 또는 실행 가능한 동작 단위입니다.

• 리터럴: 순수 수학적 값을 위한 텍스트 표현입니다.

• 상수: 특정 시점에 계산된 값에 이름을 제공합니다.

• 변수: 값을 저장하는 메모리에 이름을 제공합니다.

• 식: 값 집합을 결합하여 결과 값을 만듭니다.

• 타입: 다음을 설명합니다.

  • 값의 집합

  • 지원되는 식의 제약 조건

  • 해당 식의 의미론

• 속성: 객체에 추가 정보를 지정합니다. 예:

  • 인터페이스를 엔트리 포인트에 지정

  • 진단 필터 지정

참고: WGSL 프로그램은 현재 하나의 WGSL 모듈로 구성되어 있습니다.

WGSL은 명령형 언어입니다: 동작은 실행할 문장들의 순서로 지정됩니다. 문장은 다음을 수행할 수 있습니다:

• 상수 또는 변수 선언

• 변수의 내용을 수정

• 구조적 프로그래밍 구문을 사용하여 실행 순서 제어:

  • 선택적 실행: if (옵션 else if, else 포함), switch

  • 반복: loop, while, for

  • 중첩 실행 구조에서 탈출: continue, break, break if

  • 리팩토링: 함수 호출 및 return

• 위 동작의 일부로 값을 계산하기 위해 식 평가

• 전제를 셰이더 생성 시점에 상수 식에 대해 확인

WGSL은 정적 타입 언어입니다: 특정 식에서 계산된 값은 프로그램 소스만을 통해 결정된 특정 타입에 속합니다.

WGSL은 불리언과 숫자 (정수, 부동소수점)를 설명하는 타입을 가집니다. 이 타입들은 합성 타입으로 집계할 수 있습니다 (벡터, 행렬, 배열, 구조체). WGSL은 고유한 연산을 제공하는 원자 타입 등 특별한 타입도 포함합니다. WGSL은 메모리에 저장할 수 있는 타입을 메모리 뷰로 설명합니다. WGSL은 텍스처와 샘플러 형태로 자주 사용하는 렌더링 타입을 제공합니다. 이러한 타입들은 내장 함수와 연계되어 GPU 하드웨어의 그래픽 렌더링 기능을 노출합니다.

WGSL은 구체적 타입 간 암시적 변환 또는 승격을 제공하지 않지만, 추상적 타입에서는 암시적 변환 및 승격을 제공합니다. 한 구체적 숫자 또는 불리언 타입에서 다른 타입으로 값을 변환하려면, 명시적인 변환, 값 생성자, 또는 비트 재해석이 필요합니다. 단, WGSL은 스칼라 타입을 벡터 타입으로 승격하는 제한적인 기능을 제공합니다. 이는 합성 타입에도 적용됩니다.

셰이더 단계의 작업은 하나 이상의 인보케이션으로 분할되며, 각각은 엔트리 포인트를 약간 다른 조건에서 실행합니다. 셰이더 단계의 인보케이션들은 특정 변수에 대한 접근을 공유합니다:

• 해당 단계의 모든 인보케이션은 셰이더 인터페이스의 리소스를 공유합니다.

• 컴퓨트 셰이더에서 동일한 워크그룹 내 인보케이션들은 워크그룹 주소 공간의 변수를 공유합니다. 다른 워크그룹의 인보케이션들은 해당 변수를 공유하지 않습니다.

하지만 인보케이션은 서로 다른 셰이더 단계 입력 집합, 즉 인보케이션을 구분하는 식별 값을 제공하는 내장 입력을 포함한 입력 집합을 다룹니다. 각 인보케이션은 private 및 function 주소 공간에 있는 변수 형태로 독립적인 메모리 공간을 가집니다.

셰이더 단계 내 인보케이션들은 동시에, 그리고 종종 병렬로 실행됩니다. 셰이더 작성자는 셰이더 단계의 인보케이션 동적 동작에 대한 책임을 집니다:

• 특정 기본 연산(텍스처 샘플링, 컨트롤 배리어 등)의 균일성 요구 사항을 충족

• 공유 변수에 대한 잠재적 충돌적 접근을 조정하여 데이터 레이스를 방지

WGSL은 특정 기능에 대해 여러 동작을 허용할 수 있습니다. 이는 이식성 위험이 될 수 있으며, 구현에 따라 다른 동작이 나타날 수 있습니다. WGSL의 설계는 이러한 경우를 최소화하는 데 목적을 두지만, 현실적 제약 및 다양한 장치에서 높은 성능을 달성하기 위한 목표에 의해 제한됩니다.

행동적 요구사항은 WGSL 프로그램을 처리하거나 실행할 때 구현체가 수행해야 할 작업을 의미합니다. 이는 프로그래머와의 계약에서 구현체가 준수해야 할 의무를 설명합니다. 명세서는 이러한 의무가 명확하지 않을 수 있는 경우에 대해 이를 명시적으로 기술합니다.

1.2. 구문 표기법

아래의 구문 표기법은 WGSL의 구문 문법 규칙을 설명합니다:

• 규칙 양쪽의 이탤릭체 텍스트는 구문 규칙을 나타냅니다.

• 규칙 오른쪽에 있는 단일 따옴표(')로 시작하고 끝나는 굵은 모노스페이스 텍스트는 키워드와 토큰을 나타냅니다.

• 일반 텍스트의 콜론(:)은 구문 규칙을 등록합니다.

• 일반 텍스트의 수직 막대(|)는 대안을 나타냅니다.

• 일반 텍스트의 물음표(?)는 이전 키워드, 토큰, 규칙 또는 그룹이 0회 또는 1회 발생함(선택적임)을 나타냅니다.

• 일반 텍스트의 별표(*)는 이전 키워드, 토큰, 규칙 또는 그룹이 0회 이상 발생함을 나타냅니다.

• 일반 텍스트의 플러스(+)는 이전 키워드, 토큰, 규칙 또는 그룹이 1회 이상 발생함을 나타냅니다.

• 일반 텍스트에서 여는 괄호(()와 닫는 괄호())가 쌍으로 있는 경우, 요소들의 그룹을 나타냅니다.

1.3. 수학 용어 및 표기법

각도:

• 관례적으로, 각도는 라디안 단위로 측정합니다.

• 각도를 측정하는 기준 광선은 원점(0,0)에서 (+∞,0) 방향입니다.

• θ를 비교 광선과 기준 광선 사이에 이루어지는 각도로 정의합니다. 비교 광선이 반시계 방향으로 이동하면 θ가 증가합니다.

• 완전한 원에는 2π 라디안이 있습니다.

• 예시:

  • 각도 0은 원점에서 오른쪽(1,0) 방향을 가리킵니다.

  • 각도 2π도 원점에서 오른쪽(1,0) 방향을 가리킵니다.

  • 각도 π/4는 원점에서 (1,1) 지점을 가리킵니다.

  • 각도 π/2는 원점에서 (0,1) 지점을 가리킵니다.

  • 각도 π는 원점에서 (-1,0) 지점을 가리킵니다.

  • 각도 (3/2)π는 원점에서 (0,-1) 지점을 가리킵니다.

쌍곡각은 전통적인 의미의 각도가 아니라 단위 없는 면적입니다. 구체적으로:

• x² - y² = 1이며 x > 0인 쌍곡선을 고려합니다.

• R을 원점에서 쌍곡선 위의 임의의 점(x, y)으로 향하는 광선이라고 합니다.

• a를 R, x축, 그리고 쌍곡선 곡선 자체가 둘러싼 면적의 두 배로 정의합니다.

• R이 x축 위에 있으면 a는 양수, 아래에 있으면 음수로 간주합니다.

이때 면적 a는 쌍곡각이며, x는 a의 쌍곡코사인, y는 a의 쌍곡사인입니다.

양의 무한대(+∞로 표기)은 모든 실수보다 엄격하게 큰 고유한 값입니다.

음의 무한대(−∞로 표기)은 모든 실수보다 엄격하게 작은 고유한 값입니다.

확장 실수(affinely extended real numbers)은 실수 집합에 +∞, −∞를 포함한 집합입니다. 컴퓨터는 부동소수점 타입을 사용하여 확장 실수를 근사적으로 표현하며, 두 무한대 값도 포함합니다. § 15.7 부동소수점 평가를 참고하세요.

구간은 하한과 상한이 있는 연속된 숫자 집합입니다. 맥락에 따라 정수, 부동소수점, 실수, 또는 확장 실수 집합일 수 있습니다.

• 폐구간 [a,b]은 a ≤ x ≤ b를 만족하는 x의 집합입니다.

• 반개방 구간 [a,b)은 a ≤ x < b를 만족하는 x의 집합입니다.

• 반개방 구간 (a,b]은 a < x ≤ b를 만족하는 x의 집합입니다.

바닥 함수 표현은 확장 실수 x에 대해 정의됩니다:

• ⌊ +∞ ⌋ = +∞

• ⌊ −∞ ⌋ = −∞

• 실수 x에 대해서는, ⌊x⌋ = k이며, k는 k ≤ x < k+1을 만족하는 유일한 정수입니다.

천장 함수 표현은 확장 실수 x에 대해 정의됩니다:

• ⌈ +∞ ⌉ = +∞

• ⌈ −∞ ⌉ = −∞

• 실수 x에 대해서는, ⌈x⌉ = k이며, k-1 < x ≤ k를 만족하는 유일한 정수 k입니다.

절삭 함수는 확장 실수 x에 대해 정의됩니다:

• truncate(+∞) = +∞

• truncate(−∞) = −∞

• 실수 x에 대해, 절댓값이 x의 절댓값보다 작거나 같은 가장 가까운 정수를 계산합니다:

  • truncate(x) = ⌊x⌋ (x ≥ 0일 때),
    truncate(x) = ⌈x⌉ (x < 0일 때)

올림 함수는 양의 정수 k와 n에 대해 다음과 같이 정의합니다:

• roundUp(k, n) = ⌈n ÷ k⌉ × k

전치는 c개의 열과 r개의 행을 갖는 행렬 A에 대해, r개의 열과 c개의 행을 갖는 행렬 A^T로, A의 행을 A^T의 열로 복사하여 만듭니다:

• transpose(A) = A^T

• transpose(A)_i,j = A_j,i

열 벡터의 전치는 해당 열 벡터를 1행 행렬로 해석하여 정의합니다. 동일하게, 행 벡터의 전치는 해당 행 벡터를 1열 행렬로 해석하여 정의합니다.

2. WGSL 모듈

WGSL 프로그램은 하나의 WGSL 모듈로 구성됩니다.

모듈은 선택적 디렉티브의 시퀀스 뒤에 모듈 범위 선언 및 단언문이 이어집니다. 모듈은 다음과 같이 구성됩니다:

• 디렉티브: 모듈 수준의 동작 제어를 지정합니다.

• 함수: 실행 동작을 지정합니다.

• 문장: 선언 또는 실행 가능한 동작 단위입니다.

• 리터럴: 순수 수학적 값을 위한 텍스트 표현입니다.

• 변수: 값을 저장하는 메모리에 이름을 제공합니다.

• 상수: 특정 시점에 계산된 값에 이름을 제공합니다.

• 식: 값 집합을 결합하여 결과 값을 만듭니다.

• 타입: 다음을 설명합니다.

  • 값의 집합

  • 지원되는 식의 제약 조건

  • 해당 식의 의미론

• 속성: 객체에 추가 정보를 지정합니다. 예:

  • 인터페이스를 엔트리 포인트에 지정

  • 진단 필터 지정

2.1. 셰이더 라이프사이클

WGSL 프로그램과 그 안에 포함될 수 있는 셰이더의 라이프사이클에는 네 가지 주요 이벤트가 있습니다. 처음 두 개는 WGSL 프로그램을 실행 준비하는 데 사용되는 WebGPU API 메서드에 해당합니다. 마지막 두 개는 셰이더의 실행 시작과 종료입니다.

이벤트는 다음과 같습니다:

1. 셰이더 모듈 생성

   • 이는 WebGPU createShaderModule() 메서드가 호출될 때 발생합니다. WGSL 프로그램의 소스 텍스트가 이 시점에 제공됩니다.

2. 파이프라인 생성

   • 이는 WebGPU createComputePipeline() 메서드 또는 WebGPU createRenderPipeline() 메서드가 호출될 때 발생합니다. 이들 메서드는 이전에 생성된 하나 이상의 셰이더 모듈과 기타 구성 정보를 함께 사용합니다.

   • 지정된 엔트리 포인트의 GPUProgrammableStage 셰이더를 구성하는 코드만 파이프라인 생성 시 고려됩니다. 즉, 엔트리 포인트와 관련 없는 코드는 컴파일 전 효과적으로 제거됩니다.

   • 참고: 각 셰이더 단계는 별도로 컴파일된 것으로 간주되며, 따라서 모듈의 서로 다른 부분을 포함할 수 있습니다.

3. 셰이더 실행 시작

   • 이는 draw 또는 dispatch command가 GPU에 발행되어 파이프라인 실행을 시작하고, 셰이더 단계 엔트리 포인트 함수를 호출할 때 발생합니다.

4. 셰이더 실행 종료

   • 이는 셰이더 내 모든 작업이 완료될 때 발생합니다:

     • 모든 인보케이션이 종료되고,

     • 모든 리소스 접근이 완료되고,

     • 출력이 있다면, 다음 파이프라인 단계로 전달됩니다.

이 이벤트들은 다음 때문에 순서가 지정됩니다:

• 데이터 의존성: 셰이더 실행에는 파이프라인이 필요하고, 파이프라인에는 셰이더 모듈이 필요합니다.

• 인과성: 셰이더는 실행을 시작해야 실행을 종료할 수 있습니다.

2.2. 오류

WebGPU 구현체는 두 가지 이유로 셰이더 처리에 실패할 수 있습니다:

• 프로그램 오류 셰이더가 WGSL 또는 WebGPU 명세의 요구 사항을 충족하지 못하면 발생합니다.

• 분류되지 않은 오류 WGSL 및 WebGPU의 모든 요구 사항을 충족하더라도 발생할 수 있습니다. 가능한 원인으로는:

  • 셰이더가 너무 복잡하여 구현체의 능력을 초과하지만, 제한으로 쉽게 파악할 수 없는 경우. 셰이더를 단순화하면 문제가 해결될 수 있습니다.

  • WebGPU 구현체의 결함.

처리 오류는 셰이더 라이프사이클의 세 단계에서 발생할 수 있습니다:

• 셰이더 생성 오류 셰이더 모듈 생성 시점에 탐지 가능한 오류입니다. 탐지는 WGSL 모듈 소스 텍스트와 createShaderModule API 메서드에서 사용할 수 있는 기타 정보에만 의존합니다. 명세서에서 프로그램이 반드시 해야 한다고 기술된 사항을 위반하면 일반적으로 셰이더 생성 오류가 발생합니다.

• 파이프라인 생성 오류 파이프라인 생성 시점에 탐지 가능한 오류입니다. 탐지는 WGSL 모듈 소스 텍스트와 해당 파이프라인 생성 API 메서드에서 사용할 수 있는 정보에 의존합니다. 이러한 오류는 셰이더의 엔트리 포인트 컴파일 시에만 트리거됩니다. GPUProgrammableStage.

• 동적 오류 셰이더 실행 중에 발생하는 오류입니다. 이 오류는 탐지 가능할 수도, 불가능할 수도 있습니다.

참고: 예를 들어, 데이터 레이스는 탐지되지 않을 수 있습니다.

각 요구 사항 will은 가능한 한 빨리 확인됩니다. 즉:

• 셰이더 생성 시점에 탐지 가능한 요구 사항을 충족하지 못하면 셰이더 생성 오류가 발생합니다.

• 파이프라인 생성 시점에만 탐지 가능한 요구 사항을 충족하지 못하면 파이프라인 생성 오류가 발생합니다. 이전에 탐지되지 않은 경우에 한함.

맥락에서 명확하지 않은 경우, 이 명세서는 특정 요구 사항을 충족하지 못할 때 셰이더 생성 오류, 파이프라인 생성 오류, 또는 동적 오류 중 어떤 오류가 발생하는지 명시합니다.

오류의 결과는 다음과 같습니다:

• 셰이더 생성 오류 또는 파이프라인 생성 오류가 있는 WGSL 모듈은 파이프라인에 포함되지 않으며 실행되지 않습니다.

• 탐지 가능한 오류는 will 트리거되어 진단을 발생시킵니다.

• 동적 오류가 발생하면:

  • 메모리 접근은 다음으로 제한됩니다:

    • 셰이더 단계 입력,

    • 셰이더 단계 출력,

    • WGSL 모듈의 변수에 바인딩된 리소스의 어떤 부분,

    • WGSL 모듈에 선언된 기타 변수

  • 그 외에는, 프로그램이 이 명세서의 나머지 부분에서 설명한 대로 동작하지 않을 수 있습니다. 참고: 이러한 영향은 비국소적일 수 있습니다.

2.3. 진단

구현체는 셰이더 모듈 생성 또는 파이프라인 생성 중에 진단을 생성할 수 있습니다. 진단은 구현체가 애플리케이션 작성자를 위해 생성하는 메시지입니다.

특정 조건이 만족되면 진단이 생성되거나 트리거됩니다. 이 조건을 트리거 규칙이라고 합니다. 조건이 만족된 소스 텍스트 내의 위치(지점 또는 범위)를 트리거 위치라고 합니다.

진단은 다음 속성을 가집니다:

• 심각도

• 트리거 규칙

• 트리거 위치

심각도는 다음 중 하나이며, 높은 순서대로 나열됩니다:

오류

진단이 오류임을 의미합니다. 이는 셰이더 생성 오류 또는 파이프라인 생성 오류에 해당합니다.

경고

진단은 오류는 아니지만, 애플리케이션 개발자가 주목할 만한 이상 현상을 설명합니다.

정보

진단은 오류나 경고는 아니지만, 개발자가 주목해야 할 중요한 상황을 설명합니다.

꺼짐

진단이 비활성화되었습니다. 애플리케이션에 전달되지 않습니다.

트리거 규칙의 이름은 다음 중 하나입니다:

• diagnostic_name_token

• 두 개의 diagnostic_name_token 토큰이 마침표 '.' (U+002E)로 구분되어 있습니다.

2.3.1. 진단 처리

트리거된 진단은 다음과 같이 처리됩니다:

1. 각 진단 D에 대해, D의 트리거 위치를 포함하고 동일한 트리거 규칙을 가진 가장 작은 진단 필터를 찾습니다.

   • 해당 필터가 있으면, D에 적용하여 D의 심각도를 갱신합니다.

   • 없으면 D는 변경되지 않습니다.

2. 심각도가 꺼짐인 진단을 버립니다.

3. 남은 진단 중 적어도 하나 DI가 정보 심각도를 가지면:

   • 동일한 트리거 규칙을 가진 다른 정보 진단은 일부 버려질 수 있으며, 원래 진단 DI만 남길 수 있습니다.

4. 남은 진단 중 적어도 하나 DW가 경고 심각도를 가지면:

   • 동일한 트리거 규칙을 가진 다른 정보 또는 경고 진단은 일부 버려질 수 있으며, 원래 진단 DW만 남길 수 있습니다.

5. 남은 진단 중 하나라도 오류 심각도를 가지면:

   • 다른 진단(다른 오류 진단 포함)도 일부 버려질 수 있습니다.

   • 프로그램 오류가 생성됩니다.

     • 진단이 셰이더 모듈 생성 시점에 트리거된 경우, 오류는 셰이더 생성 오류입니다.

     • 진단이 파이프라인 생성 시점에 트리거된 경우, 오류는 파이프라인 생성 오류입니다.

6. 셰이더 모듈 생성 시점에 처리하는 경우, 남은 진단은 WebGPU messages 멤버에 저장됩니다. GPUCompilationInfo 객체입니다.

7. 파이프라인 생성 중에 처리하는 경우, 오류 진단은 WebGPU GPUProgrammableStage 검증 시 실패로 이어집니다.

참고: 이 규칙들은 구현체가 오류를 발견하면 WGSL 모듈 처리 작업을 즉시 중단할 수 있도록 허용합니다. 또한, 경고에 대한 분석은 첫 번째 경고에서 중단될 수 있고, 정보 진단에 대한 분석도 첫 발생 시 중단될 수 있습니다. WGSL은 다양한 종류의 분석 수행 순서나 단일 분석 내 순서도 지정하지 않습니다. 따라서 동일한 WGSL 모듈에 대해 서로 다른 구현체가 동일한 심각도의 진단을 다르게 보고할 수 있습니다.

2.3.2. 필터링 가능한 트리거 규칙

대부분의 진단은 무조건 WebGPU 애플리케이션에 보고됩니다. 일부 종류의 진단은 필터링될 수 있으며, 그중 일부는 트리거 규칙의 이름을 지정하여 필터링할 수 있습니다. 다음 표는 필터링할 수 있는 표준 트리거 규칙 집합을 나열합니다.

단일 diagnostic name-token으로 구성된 인식되지 않은 트리거 규칙을 사용하면 사용자 에이전트가 경고를 발생해야 합니다.

구현체는 여기 명시되지 않은 트리거 규칙도 지원할 수 있습니다. 단, diagnostic_rule_name의 다중 토큰 형식으로 철자가 되어야 합니다. 인식되지 않은 다중 토큰 형식의 트리거 규칙 사용은 자체적으로 진단을 트리거할 수 있습니다.

이 명세의 향후 버전에서는 특정 규칙을 제거하거나 기본 심각도를 완화(현재의 기본값을 더 약한 기본값으로 대체)할 수 있으며, 여전히 이전과의 호환성을 만족한 것으로 간주됩니다. 예를 들어, WGSL의 미래 버전에서는 derivative_uniformity의 기본 심각도를 오류에서 경고 또는 정보로 변경할 수 있습니다. 이러한 명세 변경 후에도 이전에 유효했던 프로그램은 계속 유효합니다.

2.3.3. 진단 필터링

필터링 가능한 진단의 트리거 규칙이 트리거되면, WGSL은 해당 진단을 버리거나 심각도를 수정할 수 있는 메커니즘을 제공합니다.

진단 필터 DF는 세 개의 매개변수를 가집니다:

• AR: 영향 범위라 불리는 소스 텍스트의 범위

• NS: 새로운 심각도

• TR: 트리거 규칙

진단 필터 DF(AR,NS,TR)를 진단 D에 적용하면 다음 효과가 있습니다:

• D의 트리거 위치가 AR 내에 있고, D의 트리거 규칙이 TR이면, D의 심각도 속성을 NS로 설정합니다.

• 그 외에는 D는 변경되지 않습니다.

범위 진단 필터는 진단 필터 중 영향 범위가 소스 텍스트의 특정 범위인 것입니다. 범위 진단 필터는 아래 표에 명시된 대로, 영향 범위 시작에 @diagnostic 속성으로 지정됩니다. @diagnostic 속성은 다른 위치에 등장해서는 안 됩니다.

참고: 다음도 복합문에 해당합니다: 함수 본문, case 절, default-alone 절, while, for 루프의 본문, if_clause, else_if_clause, else_clause의 본문.

var<private> d: f32;
fn helper() -> vec4<f32> {
  // "if"의 본문에서 derivative_uniformity 진단을 비활성화합니다.
  if (d < 0.5) @diagnostic(off,derivative_uniformity) {
    return textureSample(t,s,vec2(0,0));
  }
  return vec4(0.0);
}

글로벌 진단 필터를 사용하면 전체 WGSL 모듈에 진단 필터를 적용할 수 있습니다.

diagnostic(off,derivative_uniformity);
var<private> d: f32;
fn helper() -> vec4<f32> {
  if (d < 0.5) {
    // 글로벌 진단 필터에 의해 derivative_uniformity 진단이 비활성화됩니다.
    return textureSample(t,s,vec2(0,0));
  } else {
    // derivative_uniformity 진단의 심각도가 'warning'으로 설정됩니다.
    @diagnostic(warning,derivative_uniformity) {
      return textureSample(t,s,vec2(0,0));
    }
  }
  return vec4(0.0);
}

두 진단 필터 DF(AR1,NS1,TR1)와 DF(AR2,NS2,TR2)는 다음의 경우 충돌합니다:

• (AR1 = AR2)이고,

• (TR1 = TR2)이고,

• (NS1 ≠ NS2)일 때.

진단 필터는 충돌해서는 안 됩니다.

참고: 글로벌 진단 필터는 충돌하지 않는 한 여러 개 허용됩니다.

WGSL의 진단 필터는 영향 범위가 완전히 중첩되도록 설계되었습니다. DF1의 영향 범위가 DF2와 겹치면, DF1의 영향 범위가 DF2에 완전히 포함되거나 그 반대입니다.

소스 위치 L와 트리거 규칙 TR에 대한 가장 가까운 포함 진단 필터는, 존재한다면 다음 조건을 만족하는 진단 필터 DF(AR,NS,TR)입니다:

• L이 영향 범위 AR 내에 포함되고,

• 만약 L이 AR'에도 포함되는 다른 필터 DF'(AR',NS',TR)가 있다면, AR이 AR'에 포함됩니다.

영향 범위가 중첩되므로, 가장 가까운 포함 진단 필터는:

• 고유한 범위 진단 필터입니다,

• 그 외에는 중복된(충돌하지 않는) 글로벌 진단 필터 중 하나입니다,

• 그 외에는 존재하지 않습니다.

2.4. 제한

WGSL 구현체는 다음 제한을 충족하는 셰이더를 지원합니다. WGSL 구현체는 명시된 제한을 초과하는 셰이더도 지원할 수 있습니다.

참고: WGSL 구현체가 명시된 제한을 초과하는 셰이더를 지원하지 않으면 오류를 발생시켜야 합니다.

3. 텍스트 구조

text/wgsl 미디어 타입은 WGSL 모듈의 콘텐츠임을 식별하는 데 사용됩니다. 부록 A: text/wgsl 미디어 타입을 참고하세요.

WGSL 모듈은 UTF-8 인코딩을 사용하는 유니코드 텍스트이며, 바이트 순서 표시(BOM)는 없습니다.

WGSL 모듈 텍스트는 연속된 비어 있지 않은 유니코드 코드 포인트들의 시퀀스로 구성되며, 다음과 같이 그룹화됩니다:

• 주석

• 토큰

• 공백

프로그램 텍스트에는 null 코드 포인트(U+0000)가 포함되어서는 안 됩니다.

3.1. 파싱

WGSL 모듈을 파싱하려면:

1. 주석을 제거합니다:

   • 첫 번째 주석을 공백 코드 포인트(U+0020)로 대체합니다.

   • 주석이 더 이상 남지 않을 때까지 반복합니다.

2. 템플릿 리스트를 찾습니다. 알고리즘은 § 3.9 Template Lists를 참고하세요.

3. 전체 텍스트를 파싱하여 translation_unit 문법 규칙과 일치하는지 시도합니다. 파싱은 LALR(1) 파서(토큰 하나 lookahead)를 사용하며 [DeRemer1969], 다음과 같은 커스터마이즈가 적용됩니다:

   • 토큰화는 파싱과 병행되며, 컨텍스트 인식형입니다. 파서가 다음 토큰을 요청할 때:

     • 초기 연속 공백 코드 포인트들을 소비하고 무시합니다.

     • 다음 코드 포인트가 템플릿 리스트의 시작이면, 이를 소비하고 _template_args_start를 반환합니다.

     • 다음 코드 포인트가 템플릿 리스트의 끝이면, 이를 소비하고 _template_args_end를 반환합니다.

     • 그 외의 경우:

       • 토큰 후보란 남은 미소비 코드 포인트의 비어 있지 않은 접두사로 형성된 WGSL 토큰입니다.

       • 반환되는 토큰은 현재 파서 상태에서 유효한 lookahead 토큰이면서 가장 긴 토큰 후보입니다. [VanWyk2007]

다음 경우 셰이더 생성 오류가 발생합니다:

• 전체 소스 텍스트를 유효한 토큰의 유한 시퀀스로 변환할 수 없는 경우

• translation_unit 문법 규칙이 전체 토큰 시퀀스와 일치하지 않는 경우

3.2. 공백 및 줄바꿈

공백은 유니코드 Pattern_White_Space 속성의 코드 포인트들 중 하나 이상으로 구성된 조합입니다. Pattern_White_Space에 속하는 코드 포인트 집합은 다음과 같습니다:

• 공백 (U+0020)

• 수평 탭 (U+0009)

• 줄 바꿈 (U+000A)

• 수직 탭 (U+000B)

• 폼 피드 (U+000C)

• 캐리지 리턴 (U+000D)

• 다음 줄 (U+0085)

• 좌에서 우 마크 (U+200E)

• 우에서 좌 마크 (U+200F)

• 줄 구분자 (U+2028)

• 문단 구분자 (U+2029)

줄바꿈은 공백 코드 포인트의 연속으로, 줄의 끝을 나타냅니다. UAX14 섹션 6.1 Non-tailorable Line Breaking Rules의 "mandatory break"를 신호하는 공백으로 정의되며, LB4 및 LB5를 참고하세요. 즉, 줄바꿈은 다음 중 하나입니다:

• 줄 바꿈 (U+000A)

• 수직 탭 (U+000B)

• 폼 피드 (U+000C)

• 캐리지 리턴 (U+000D)이 줄 바꿈(U+000A) 뒤에 오지 않을 때

• 캐리지 리턴 (U+000D) 다음에 줄 바꿈(U+000A)이 올 때

• 다음 줄 (U+0085)

• 줄 구분자 (U+2028)

• 문단 구분자 (U+2029)

참고: 소스 텍스트 위치를 줄 번호로 보고하는 진단은 줄 개수를 셀 때 줄바꿈을 사용해야 합니다.

3.3. 주석

주석은 WGSL 프로그램의 유효성이나 의미에 영향을 주지 않는 텍스트 영역이며, 주석은 토큰을 분리할 수 있습니다. 셰이더 작성자는 프로그램을 문서화하기 위해 주석을 사용할 수 있습니다.

줄 끝 주석은 주석의 한 종류로, 두 코드 포인트 // (U+002F와 U+002F)와 그 뒤에 오는 코드 포인트들로 구성되며, 다음 중 하나가 나오기 전까지입니다:

• 다음 줄바꿈

• 프로그램 끝

블록 주석은 주석의 한 종류로, 다음으로 구성됩니다:

• 두 코드 포인트 /* (U+002F와 U+002A)

• 그리고 아래 중 하나의 시퀀스:

  • 블록 주석

  • */ (U+002A와 U+002F) 또는 /* (U+002F와 U+002A)를 포함하지 않는 텍스트

• 마지막으로 두 코드 포인트 */ (U+002A와 U+002F)

참고: 블록 주석은 중첩될 수 있습니다. 블록 주석은 시작과 끝 텍스트 시퀀스가 반드시 일치해야 하며, 임의의 중첩을 허용하기 때문에 정규표현식으로 인식할 수 없습니다. 이는 정규 언어의 펌핑 렘마(Pumping Lemma)로 인한 결과입니다.

const f = 1.5; // 이것은 줄 끝 주석입니다.
const g = 2.5; /* 이것은 여러 줄에 걸친 블록 주석입니다
                블록 주석은 중첩될 수 있습니다.
                /* 블록 주석은 중첩 가능합니다.
                 */
                모든 블록 주석은 반드시 종료되어야 합니다.
               */

3.4. 토큰

토큰은 연속된 코드 포인트 시퀀스로 다음 중 하나를 형성합니다:

• 리터럴

• 키워드

• 예약어

• 구문 토큰

• 식별자

• 상황에 따라 달라지는 이름

3.5. 리터럴

리터럴은 다음 중 하나입니다:

• 불리언 리터럴: true 또는 false 중 하나.

• 숫자 리터럴: 정수 리터럴 또는 부동소수점 리터럴이며, 숫자를 나타내는 데 사용됨.

3.5.1. 불리언 리터럴

const a = true;
const b = false;

3.5.2. 숫자 리터럴

숫자 리터럴의 형태는 패턴 매칭을 통해 정의됩니다.

정수 리터럴은 다음과 같습니다:

• 정수는 아래 중 하나로 지정됩니다:

  • 0

  • 첫 번째 숫자가 0이 아닌 십진수 숫자의 시퀀스.

  • 0x 또는 0X 뒤에 16진수 숫자 시퀀스.

• 그 뒤에 선택적으로 i 또는 u 접미사가 올 수 있음.

참고: 0이 아닌 정수 리터럴 앞에 0이 오는 것(예: 012)은 금지되며, 이는 다른 언어에서 0으로 시작하면 8진수로 인식되는 혼동을 방지하기 위함입니다.

const a = 1u;
const b = 123;
const c = 0;
const d = 0i;

const a = 0x123;
const b = 0X123u;
const c = 0x3f;

부동소수점 리터럴은 십진수 부동소수점 리터럴 또는 16진수 부동소수점 리터럴입니다.

부동소수점 리터럴은 두 개의 논리적 부분을 가집니다: 분수를 나타내는 유효숫자와 선택적인 지수입니다. 대략적으로, 리터럴의 값은 유효숫자에 기저값을 지수만큼 거듭제곱한 값을 곱한 것입니다. 유효숫자 자리수는 유효숫자라고 하며, 0이 아니거나, 해당 숫자의 왼쪽과 오른쪽에 모두 0이 아닌 유효숫자가 있을 때 유효숫자입니다. 유효숫자는 왼쪽부터 오른쪽으로 센다: N번째 유효숫자는 왼쪽에 N-1개의 유효숫자가 있습니다.

십진수 부동소수점 리터럴은 다음과 같습니다:

• 유효숫자(분수)는 숫자 시퀀스로 지정되며, 중간에 선택적으로 소수점(.)이 올 수 있음. 유효숫자는 10진법 분수를 나타냅니다.

• 그 뒤에 선택적으로 지수 접미사가 올 수 있는데, 다음으로 구성됨:

  • e 또는 E

  • 그 뒤에 선택적으로 부호(+, -)가 붙은 십진수로 지정된 지수.

  • 그 뒤에 선택적으로 f 또는 h 접미사가 올 수 있음.

• 소수점, 지수, f 또는 h 접미사 중 하나 이상이 반드시 포함되어야 합니다. 아무 것도 없으면 해당 토큰은 정수 리터럴입니다.

const a = 0.e+4f;
const b = 01.;
const c = .01;
const d = 12.34;
const f = .0f;
const g = 0h;
const h = 1e-3;

참고: 십진수 유효숫자는 20자리 이후로 잘려, 약 log(10)/log(2)×20 ≈ 66.4 비트가 보존됩니다.

16진수 부동소수점 리터럴은 다음과 같습니다:

• 0x 또는 0X 접두사

• 그 뒤에 16진수 숫자 시퀀스로 지정된 유효숫자, 중간에 선택적으로 16진수 소수점(.)이 올 수 있음. 유효숫자는 16진법 분수를 나타냄.

• 그 뒤에 선택적으로 지수 접미사:

  • p 또는 P

  • 그 뒤에 선택적으로 부호(+, -)가 붙은 십진수로 지정된 지수.

  • 그 뒤에 선택적으로 f 또는 h 접미사가 올 수 있음.

• 16진수 소수점 또는 지수 중 최소 하나는 반드시 포함되어야 합니다. 둘 다 없으면 해당 토큰은 정수 리터럴입니다.

const a = 0xa.fp+2;
const b = 0x1P+4f;
const c = 0X.3;
const d = 0x3p+2h;
const e = 0X1.fp-4;
const f = 0x3.2p+2h;

참고: 16진수 유효숫자는 16자리 이후로 잘려, 약 4 ×16 = 64 비트가 보존됩니다.

숫자 리터럴에 접미사가 있으면 해당 리터럴은 특정 구체적 스칼라 타입의 값을 나타냅니다. 그렇지 않으면 아래 정의된 추상 숫자 타입 중 하나의 값을 나타냅니다. 두 경우 모두, 리터럴이 나타내는 값은 대상 타입으로 변환된 수학적 값이며, 변환 규칙은 § 15.7.6 부동소수점 변환을 따릅니다.

셰이더 생성 오류는 다음 경우 발생합니다:

• i 또는 u 접미사가 붙은 정수 리터럴이 대상 타입으로 나타낼 수 없는 경우

• f 또는 h 접미사가 붙은 16진수 부동소수점 리터럴이 오버플로우되거나 대상 타입에 정확히 나타낼 수 없는 경우

• f 또는 h 접미사가 붙은 십진수 부동소수점 리터럴이 대상 타입에서 오버플로우된 경우

• h 접미사가 붙은 부동소수점 리터럴이 f16 확장이 활성화되지 않은 상태에서 사용된 경우

참고: 16진수 float 값 0x1.00000001p0은 정확히 표현하려면 33 유효숫자 비트가 필요하지만, f32는 명시적 유효숫자 비트가 23개뿐입니다.

참고: 16진수 float 리터럴에 f 접미사를 붙여 타입을 강제하려면 반드시 이진 지수도 사용해야 합니다. 예시: 0x1p0f로 작성. 0x1f는 16진수 정수 리터럴로 취급됨.

3.6. 키워드

키워드는 미리 정의된 언어 개념을 참조하는 토큰입니다. WGSL 키워드 목록은 § 16.1 키워드 요약을 참고하세요.

3.7. 식별자

식별자는 이름으로 사용되는 토큰의 한 종류입니다. 자세한 내용은 § 5 선언과 범위를 참고하세요.

WGSL은 사용 사례를 구분하기 위해 두 개의 문법 비종결(nonterminal)을 사용합니다:

• ident는 선언된 객체에 이름을 붙일 때 사용됩니다.

• member_ident는 structure 타입의 멤버에 이름을 붙일 때 사용됩니다.

식별자의 형식은 Unicode Standard Annex #31(Unicode Version 14.0.0 기준)에 따라 정의되며, 아래와 같은 추가 설명이 있습니다.

식별자는 다음과 같이 UAX31 문법 기준 프로필을 사용합니다:

<Identifier> := <Start> <Continue>* (<Medial> <Continue>+)*

<Start> := XID_Start + U+005F
<Continue> := <Start> + XID_Continue
<Medial> :=

즉, 다음과 같이 비ASCII 코드 포인트가 포함된 식별자도 유효합니다: Δέλτα, réflexion, Кызыл, 𐰓𐰏𐰇, 朝焼け, سلام, 검정, שָׁלוֹם, गुलाबी, փիրուզ.

단, 다음 예외가 있습니다:

• 식별자는 키워드 또는 예약어와 철자가 같으면 안 됩니다.

• 식별자는 _(단일 언더스코어, U+005F)이면 안 됩니다.

• 식별자는 __(두 개의 언더스코어, U+005F + U+005F)로 시작하면 안 됩니다.

Unicode Character Database for Unicode Version 14.0.0에는 XID_Start 및 XID_Continue의 모든 유효 코드 포인트의 비공식 목록이 포함되어 있습니다.

참고: 일부 내장 함수의 반환 타입은 이름을 WGSL 소스에서 사용할 수 없는 구조체 타입입니다. 이러한 구조체 타입은 두 개의 언더스코어로 시작하는 이름이 선언된 것처럼 설명됩니다. 결과 값은 새로운 let 또는 var에 타입 추론을 이용해 저장하거나, 바로 멤버 이름으로 추출할 수 있습니다. frexp와 modf 설명의 예시 사용을 참고하세요.

3.7.1. 식별자 비교

두 WGSL 식별자가 동일하다는 것은, 오직 두 식별자가 동일한 코드 포인트 시퀀스로 구성되어 있을 때만입니다.

참고: 이 명세는 비교 목적으로 유니코드 정규화를 허용하지 않습니다. 시각적으로/의미적으로 동일하지만 다른 유니코드 문자 시퀀스를 사용하는 값은 일치하지 않습니다. 콘텐츠 작성자는 값 선택 시 동일한 인코딩 시퀀스를 일관되게 사용하거나 문제가 될 수 있는 문자를 피할 것을 권장합니다. 자세한 내용은 [CHARMOD-NORM] 참고.

참고: 사용자 에이전트는 WGSL 모듈의 의미가 동일 식별자의 모든 인스턴스를 해당 식별자의 동형(homograph)으로 치환할 때 달라질 경우, 개발자에게 경고를 표시해야 합니다. (동형문자(homoglyph)는 코드 포인트 시퀀스가 독자에게 다른 시퀀스와 동일하게 보일 수 있는 경우를 의미합니다. 동형문자 탐지 예시로는 앞 문단에 언급된 변환, 매핑, 매칭 알고리즘 등이 있습니다. 두 코드 포인트 시퀀스는 하나의 시퀀스를 반복적으로 동형문자로 치환하여 다른 시퀀스로 만들 수 있으면 동형문자입니다.)

3.8. 상황에 따라 달라지는 이름

상황에 따라 달라지는 이름은 특정 문법적 맥락에서만 개념에 이름을 붙일 때 사용하는 토큰입니다. 이 토큰의 철자는 식별자와 같을 수 있지만, 해당 토큰은 선언된 객체로 해결되지 않습니다. 이 섹션에서는 상황에 따라 달라지는 이름으로 사용되는 토큰을 나열합니다. 해당 토큰은 키워드나 예약어이면 안 됩니다.

3.8.1. 속성 이름

§ 12 속성 참고.

속성 이름은 다음과 같습니다:

• 'align'

• 'binding'

• 'builtin'

• 'compute'

• 'const'

• 'diagnostic'

• 'fragment'

• 'group'

• 'id'

• 'interpolate'

• 'invariant'

• 'location'

• 'blend_src'

• 'must_use'

• 'size'

• 'vertex'

• 'workgroup_size'

3.8.2. 내장 값 이름

내장 값 이름 토큰은 토큰으로, 내장 값의 이름에 사용됩니다.

§ 13.3.1.1 내장 입력 및 출력를 참고하세요.

내장 값 이름은 다음과 같습니다:

• 'vertex_index'

• 'instance_index'

• 'position'

• 'front_facing'

• 'frag_depth'

• 'sample_index'

• 'sample_mask'

• 'local_invocation_id'

• 'local_invocation_index'

• 'global_invocation_id'

• 'workgroup_id'

• 'num_workgroups'

• 'subgroup_invocation_id'

• 'subgroup_size'

3.8.3. 진단 규칙 이름

진단 이름 토큰은 토큰으로, 진단 트리거 규칙의 이름에 사용됩니다.

§ 2.3 진단을 참고하세요.

미리 정의된 진단 규칙 이름은 다음과 같습니다:

• 'derivative_uniformity'

• 'subgroup_uniformity'

3.8.4. 진단 심각도 제어 이름

유효한 진단 필터 심각도 제어 이름은 § 2.3 진단에 나열되어 있지만, 일반적으로 식별자와 동일한 형식을 가집니다:

진단 필터 심각도 제어 이름은 다음과 같습니다:

• 'error'

• 'warning'

• 'info'

• 'off'

3.8.5. 확장 이름

유효한 enable-extension 이름은 § 4.1.1 확장 활성화에 나열되어 있지만, 일반적으로 식별자와 동일한 형식을 가집니다:

enable-extension 이름은 다음과 같습니다:

• 'f16'

• 'clip_distances'

• 'dual_source_blending'

• 'subgroups'

• 'primitive_index'

유효한 언어 확장 이름은 § 4.1.2 언어 확장에 나열되어 있지만, 일반적으로 식별자와 동일한 형식을 가집니다:

언어 확장 이름은 다음과 같습니다:

• 'readonly_and_readwrite_storage_textures'

• 'packed_4x8_integer_dot_product'

• 'unrestricted_pointer_parameters'

• 'pointer_composite_access'

3.8.6. 보간 타입 이름

보간 타입 이름 토큰은 토큰으로, 보간 타입 (interpolate_type_name)의 이름에 사용됩니다.

§ 13.3.1.4 보간을 참고하세요.

보간 타입 이름은 다음과 같습니다:

• 'perspective'

• 'linear'

• 'flat'

3.8.7. 보간 샘플링 이름

보간 샘플링 이름 토큰은 토큰으로, 보간 샘플링의 이름에 사용됩니다.

§ 13.3.1.4 보간을 참고하세요.

보간 샘플링 이름은 다음과 같습니다:

• 'center'

• 'centroid'

• 'sample'

• 'first'

• 'either'

3.8.8. 스위즐 이름

스위즐 이름은 벡터 접근 식에서 사용됩니다:

3.9. 템플릿 리스트

템플릿 매개변수화는 일반 개념을 수정하는 매개변수를 지정하는 방법입니다. 템플릿 매개변수화를 작성하려면 일반 개념을 쓴 뒤 템플릿 리스트를 씁니다.

주석과 공백을 무시하면, 템플릿 리스트란 다음과 같습니다:

• 처음 '<' (U+003C) 코드 포인트, 그리고

• 하나 이상의 쉼표로 구분된 템플릿 매개변수 리스트, 그리고

• 선택적으로 끝에 쉼표, 그리고

• 마지막 '>' (U+003E) 코드 포인트.

템플릿 매개변수의 형식은 아래 템플릿 리스트 발견 알고리즘에 의해 암시적으로 정의됩니다. 일반적으로 이름, 식, 또는 타입입니다.

참고: 예를 들어 vec3<f32>는 vec3라는 일반 개념을 <f32>라는 템플릿 리스트(매개변수 하나, f32 타입)로 수정한 매개변수화입니다. vec3<f32>는 구체적인 벡터 타입을 뜻합니다.

참고: 예를 들어 var<storage,read_write>는 일반 var 개념을 storage, read_write 템플릿 매개변수로 수정합니다.

템플릿 리스트를 구분하는 '<' (U+003C)와 '>' (U+003E) 코드 포인트는 다음에도 사용됩니다:

• 관계식에서 비교 연산자로,

• 시프트 식에서 시프트 연산자로,

• 복합 대입 연산자에서 시프트 연산 + 대입 시.

구문적 모호함은 템플릿 리스트 쪽으로 해결됩니다:

• 템플릿 리스트는 파싱 초기에 발견되며, 선언, 식, 문장 파싱 전에 처리됩니다.

• 이후 단계의 토큰화에서는, 템플릿 리스트의 초기 '<' (U+003C)는 _template_args_start 토큰으로, 마지막 '>' (U+003E)는 _template_args_end 토큰으로 매핑됩니다.

템플릿 리스트 발견 알고리즘은 아래와 같습니다. 다음과 같은 가정과 특성을 사용합니다:

1. 템플릿 매개변수는 식이며, 따라서 '<'(U+003C) 또는 '='(U+003D)로 시작하지 않습니다.

2. 식에는 ';'(U+003B), '{'(U+007B), ':'(U+003A) 코드 포인트가 포함되지 않습니다.

3. 식에는 대입문이 포함되지 않습니다.

4. '='(U+003D) 코드 포인트는 비교 연산('<=', '>=', '==', '!=')의 일부로만 나타납니다. 그 외의 경우 '='는 대입문의 일부입니다.

5. 템플릿 리스트 구분자는 괄호 '(...)'와 배열 인덱싱 '[...]'로 구성된 중첩 식을 존중합니다. 템플릿 리스트의 시작과 끝은 동일한 중첩 레벨에 있어야 합니다.

알고리즘: 템플릿 리스트 발견

입력: 프로그램 소스 텍스트.

레코드 타입:

UnclosedCandidate는 다음을 포함하는 레코드 타입입니다:

• position: 소스 텍스트 내 위치

• depth: position 위치의 식 중첩 깊이(정수)

TemplateList는 다음을 포함하는 레코드 타입입니다:

• start_position: 이 템플릿 리스트를 시작하는 '<'(U+003C) 코드 포인트의 소스 위치

• end_position: 이 템플릿 리스트를 끝내는 '>'(U+003E) 코드 포인트의 소스 위치

출력: DiscoveredTemplateLists: TemplateList 레코드의 리스트.

절차:

• DiscoveredTemplateLists를 빈 리스트로 초기화합니다.

• Pending 변수를 UnclosedCandidate 레코드의 빈 스택으로 초기화합니다.

• CurrentPosition 정수 변수를 0으로 초기화합니다. 이 변수는 현재 검사 중인 코드 포인트 위치(소스 텍스트 시작 이후 코드 포인트 수)를 나타냅니다.

  • 이 변수는 알고리즘 실행 중 텍스트를 앞으로 진행하며, 텍스트 끝에 도달하면 즉시 알고리즘을 종료하고 DiscoveredTemplateLists를 반환합니다.

• NestingDepth 정수 변수를 0으로 초기화합니다.

• 다음 단계들을 반복합니다:

  • CurrentPosition을 공백, 주석, 리터럴 이후로 이동합니다.

  • ident_pattern_token이 CurrentPosition의 텍스트와 일치하면:

    • CurrentPosition을 ident_pattern_token 이후로 이동합니다.

    • 공백과 주석이 있다면 CurrentPosition을 그 이후로 이동합니다.

    • '<' (U+003C)가 CurrentPosition에 있으면:

      • 참고: 이 코드 포인트는 템플릿 리스트 시작 후보입니다. 나중에 '>'와 매칭할 수 있도록 상태를 저장합니다.

      • UnclosedCandidate(position=CurrentPosition,depth=NestingDepth)를 Pending 스택에 푸시합니다.

      • CurrentPosition을 다음 코드 포인트로 이동합니다.

      • '<'가 CurrentPosition에 또 있으면:

        • 참고: 가정 1에 따라 어떤 템플릿 매개변수도 '<'로 시작하지 않으므로, 이전 코드 포인트는 템플릿 리스트 시작이 될 수 없습니다. 따라서 현재와 이전 코드 포인트는 '<<' 연산자입니다.

        • Pending 스택의 top을 팝합니다.

        • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

      • '='가 CurrentPosition에 있으면:

        • 참고: 가정 1에 따라 어떤 템플릿 매개변수도 '='로 시작하지 않으므로, 이전 코드 포인트는 템플릿 리스트 시작이 될 수 없습니다. 따라서 현재와 이전 코드 포인트는 '<=' 비교 연산자입니다. '=' 코드 포인트를 건너뛰어 나중에 대입으로 오인되지 않도록 합니다.

        • Pending 스택의 top을 팝합니다.

        • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

    • 다음 반복을 시작합니다.

  • '>'(U+003E)가 CurrentPosition에 있으면:

    • 참고: 이 코드 포인트는 템플릿 리스트 끝 후보입니다.

    • Pending이 비어 있지 않으면 top을 T로 두고 T.depth가 NestingDepth와 같다면:

      • 참고: 이 코드 포인트는 T에 기록된 템플릿 리스트를 끝냅니다.

      • TemplateList(start_position=T.position, end_position=CurrentPosition)를 DiscoveredTemplateLists에 추가합니다.

      • T를 Pending 스택에서 팝합니다.

      • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

    • 그 외에는 이 코드 포인트가 템플릿 리스트를 끝내지 않습니다:

      • CurrentPosition을 다음 코드 포인트로 이동합니다.

      • '='가 CurrentPosition에 있으면:

        • 참고: 현재와 이전 코드 포인트는 '>=' 비교 연산자입니다. '=' 코드 포인트를 건너뛰어 나중에 대입으로 오인되지 않도록 합니다.

        • CurrentPosition을 다음 코드 포인트로 이동합니다.

      • 다음 반복을 시작합니다.

  • '('(U+0028) 또는 '['(U+005B)가 CurrentPosition에 있으면:

    • 참고: 중첩 식 진입.

    • NestingDepth에 1을 더합니다.

    • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

  • ')'(U+0029) 또는 ']'(U+005D)가 CurrentPosition에 있으면:

    • 참고: 중첩 식 탈출.

    • Pending 스택의 top의 depth가 NestingDepth 미만이 될 때까지 팝하거나, 스택이 비울 때까지 팝합니다.

    • NestingDepth를 0 또는 NestingDepth − 1 중 더 큰 값으로 설정합니다.

    • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

  • '!'(U+0021)가 CurrentPosition에 있으면:

    • CurrentPosition을 다음 코드 포인트로 이동합니다.

    • '='가 CurrentPosition에 있으면:

      • 참고: 현재와 이전 코드 포인트는 '!=' 비교 연산자입니다. '=' 코드 포인트를 건너뛰어 나중에 대입으로 오인되지 않도록 합니다.

      • CurrentPosition을 다음 코드 포인트로 이동합니다.

    • 다음 반복을 시작합니다.

  • '='(U+003D)가 CurrentPosition에 있으면:

    • CurrentPosition을 다음 코드 포인트로 이동합니다.

    • '='가 CurrentPosition에 있으면:

      • 참고: 현재와 이전 코드 포인트는 '==' 비교 연산자입니다. '=' 코드 포인트를 건너뛰어 나중에 대입으로 오인되지 않도록 합니다.

      • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

    • 참고: 이 코드 포인트는 대입문의 일부로, 식에서 나올 수 없으므로 템플릿 리스트에도 나올 수 없습니다. 미결 후보를 모두 제거합니다.

    • NestingDepth를 0으로 설정합니다.

    • Pending 스택을 모두 비웁니다.

    • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

  • ';'(U+003B), '{'(U+007B), ':'(U+003A)가 CurrentPosition에 있으면:

    • 참고: 식 중에는 나올 수 없으므로 템플릿 리스트에도 나올 수 없습니다. 미결 후보를 모두 제거합니다.

    • NestingDepth를 0으로 설정합니다.

    • Pending 스택을 모두 비웁니다.

    • CurrentPosition을 다음 코드 포인트로 이동하고 다음 반복을 시작합니다.

  • '&&' 또는 '||'가 CurrentPosition의 텍스트와 일치하면:

    • 참고: 이들은 비교 연산보다 우선순위가 낮은 연산자입니다. 현재 식 레벨의 미결 후보를 모두 제거합니다.

    • 참고: 이 규칙으로 a<b || c>d는 템플릿 리스트 대신 두 비교의 단락 논리합으로 인식됩니다.

    • Pending 스택의 top의 depth가 NestingDepth 미만이 될 때까지 팝하거나, 스택이 비울 때까지 팝합니다.

    • CurrentPosition을 두 코드 포인트 이후로 이동하고 다음 반복을 시작합니다.

  • CurrentPosition을 현재 코드 포인트 이후로 이동합니다.

참고: 알고리즘은 리터럴을 명시적으로 건너뜁니다. 왜냐하면 일부 숫자 리터럴은 마지막에 문자가 올 수 있는데, 예를 들어 1.0f처럼 끝나는 f를 ident_pattern_token의 시작으로 오인하지 않아야 하기 때문입니다.

참고: A ( B < C, D > ( E ) )라는 구에서는 < C, D >가 템플릿 리스트입니다.

참고: 알고리즘은 식 중첩을 존중합니다. 특정 템플릿 리스트의 시작과 끝은 서로 다른 식 중첩 레벨에 올 수 없습니다. 예를 들어 array<i32,select(2,3,a>b)>에서 템플릿 리스트는 세 개의 매개변수를 가지며, 마지막 매개변수는 select(2,3,a>b)입니다. a>b의 '>'는 select 함수 호출식의 괄호 내부에 있으므로 템플릿 리스트를 종료하지 않습니다.

참고: 템플릿 리스트의 양 끝은 동일한 인덱싱 식 내에 있어야 합니다. 예를 들어 a[b<d]>()는 유효한 템플릿 리스트를 포함하지 않습니다.

참고: A<B<<C>에서 B<<C는 B 다음에 왼쪽 시프트 연산자 '<<'와 C가 이어진 것으로 파싱됩니다. 템플릿 발견 알고리즘은 B를 보고 '<'(U+003C)를 본 다음, 그 뒤의 '<'(U+003C)가 템플릿 인수 시작이 될 수 없음을 알게 되어, B 바로 뒤의 '<'는 템플릿 리스트 시작이 아닙니다. 처음 '<'와 마지막 '>'만 템플릿 리스트 구분자이며, 매개변수는 B<<C입니다.

참고: A<B<=C>도 위와 비슷하게 분석되어, B<=C는 B 다음에 작거나 같은 연산자 '<='와 C가 이어진 것으로 파싱됩니다. 템플릿 발견 알고리즘은 B를 보고 '<'(U+003C)를 본 다음, 그 뒤의 '='(U+003D)가 템플릿 인수 시작이 될 수 없음을 알게 되어, B 바로 뒤의 '<'는 템플릿 리스트 시작이 아닙니다. 처음 '<'와 마지막 '>'만 템플릿 리스트 구분자이며, 매개변수는 B<=C입니다.

참고: A<(B>=C)>를 검사할 때, 하나의 템플릿 리스트가 있으며 처음 '<'(U+003C)에서 마지막 '>'(U+003E)까지이고, 템플릿 인수는 B>=C입니다. B 이후 첫 번째 '>'(U+003C) 코드 포인트를 검사한 후, '='(U+003D) 코드 포인트는 대입이 아니도록 특별히 인식해야 합니다.

참고: A<(B!=C)>를 검사할 때, 하나의 템플릿 리스트가 있으며 처음 '<'(U+003C)에서 마지막 '>'(U+003E)까지이고, 템플릿 인수는 B!=C입니다. 'B' 이후 '!'(U+0021) 코드 포인트를 검사한 후, '='(U+003D) 코드 포인트는 대입이 아니도록 특별히 인식해야 합니다.

참고: A<(B==C)>를 검사할 때, 하나의 템플릿 리스트가 있으며 처음 '<'(U+003C)에서 마지막 '>'(U+003E)까지이고, 템플릿 인수는 B==C입니다. 'B' 이후 첫 번째 '='(U+003D) 코드 포인트를 검사한 후, 두 번째 '='(U+003D) 코드 포인트도 대입이 아니도록 특별히 인식해야 합니다.

템플릿 리스트 발견이 완료되면, 파싱에서 각 템플릿 리스트가 template_list 문법 규칙에 맞는지 검사합니다.

4. 지시문

지시문은 토큰 시퀀스로, WGSL 프로그램이 WebGPU 구현에서 처리되는 방식을 수정합니다.

지시문은 선택 사항입니다. 만약 존재한다면, 모든 지시문은 반드시 모든 선언 또는 const 단언문 이전에 나타나야 합니다.

4.1. 확장

WGSL은 시간이 지남에 따라 발전할 것으로 예상됩니다.

확장은 WGSL 명세의 일관된 수정 집합을 명명하여 그룹화한 것으로, 다음과 같은 내용을 포함할 수 있습니다:

• 새로운 문법을 통해 새로운 개념과 동작을 추가, 예를 들어:

  • 선언, 문(statement), 속성(attribute), 내장 함수(built-in function)

• 현행 표준 또는 기존에 발표된 확장에서의 제한 사항 제거

• 허용되는 동작의 범위를 줄이기 위한 문법

• 프로그램의 일부에서 사용할 수 있는 기능을 제한하는 문법

• 확장이 기존 명세 및 다른 확장과 어떻게 상호작용하는지에 대한 설명

가상적으로, 확장은 다음을 할 수 있습니다:

• 다양한 비트 너비의 정수 등 숫자 스칼라 타입 추가

• 부동 소수점 반올림 모드를 제한하는 문법 추가

• 셰이더에서 atomic 타입을 사용하지 않음을 신호하는 문법 추가

• 새로운 종류의 문(statement) 추가

• 새로운 내장 함수 추가

• 셰이더 호출 방식 제한을 위한 문법 추가

• 새로운 셰이더 단계 추가

확장에는 두 종류가 있습니다: enable-extensions와 language extensions입니다.

4.1.1. Enable Extension

enable-extension은 확장으로, 다음의 조건을 모두 만족해야 기능을 사용할 수 있습니다:

• 구현체가 해당 기능을 지원할 것

• 셰이더가 enable directive를 통해 명시적으로 요청할 것

• 해당 WebGPU GPUFeatureName 이 GPUDevice를 생성할 때 요청된 필수 기능 중 하나일 것

Enable-extension은 하드웨어 기능 중 보편적으로 제공되지 않는 부분을 노출하는 것을 목적으로 합니다.

enable directive는 하나 이상의 enable-extension 기능을 활성화하는 지시문입니다. 만약 구현체가 나열된 모든 enable-extension을 지원하지 않으면 셰이더 생성 오류가 발생합니다.

다른 지시문과 마찬가지로, enable directive가 존재한다면, 반드시 모든 선언과 const 단언문 이전에 나타나야 합니다. 확장 이름은 식별자가 아닙니다: 선언으로 해석되지 않습니다.

유효한 enable-extension 목록은 다음 표에 나와 있습니다.

// 임의 정밀도의 부동 소수점 타입용 가상 확장 활성화.
enable arbitrary_precision_float;
enable arbitrary_precision_float; // 중복된 enable 지시문도 허용됩니다.

// 반올림 모드 제어를 위한 가상 확장 활성화.
enable rounding_mode;

// arbitrary_precision_float 확장으로 아래 항목 사용 가능:
//    - 타입 f<E,M>
//    - 함수 반환 타입, 형식 매개변수, let 선언에서 타입으로 사용
//    - AbstractFloat로부터 값 생성자 사용 가능
//    - 나눗셈 연산자 /의 피연산자로 사용 가능
// rounding_mode enable 지시문으로 @rounding_mode 속성 사용 가능.
@rounding_mode(round_to_even)
fn halve_it(x : f<8, 7>) -> f<8, 7> {
  let two = f<8, 7>(2);
  return x / 2; // round to even 반올림 모드 사용
}

4.1.2. 언어 확장

언어 확장은 구현체가 지원한다면 자동으로 사용할 수 있는 확장입니다. 프로그램에서 명시적으로 요청할 필요가 없습니다.

언어 확장은 어떤 WebGPU 구현에서도 합리적으로 지원될 수 있는 기능을 구현합니다. 만약 해당 기능이 보편적으로 제공되지 않는다면, 이는 일부 WebGPU 구현체가 아직 해당 기능을 구현하지 않았기 때문입니다.

참고: 예를 들어, do-while 반복문은 언어 확장이 될 수 있습니다.

WebGPU wgslLanguageFeatures 멤버는 GPU 객체에 존재하며, 구현체가 지원하는 언어 확장 목록을 제공합니다.

requires-directive 는 프로그램이 하나 이상의 언어 확장을 사용함을 문서화하는 지시문입니다. 이는 구현체가 노출하는 기능을 변경하지 않습니다. 구현체가 요구된 확장 중 하나라도 지원하지 않으면 셰이더 생성 오류가 발생합니다.

WGSL 모듈은 requires-directive를 사용하여 이식성 문제 가능성과 의도된 최소 이식성 기준을 알릴 수 있습니다.

참고: WebGPU 구현 외부의 도구는 프로그램이 사용하는 모든 언어 확장이 프로그램 내 requires-directive에 포함되어 있는지 확인할 수 있습니다.

다른 지시문과 마찬가지로, requires-directive가 존재한다면, 모든 선언과 const 단언문 이전에 나타나야 합니다. 확장 이름은 식별자가 아닙니다: 선언으로 해석되지 않습니다.

참고: WGSL은 시간이 지남에 따라 당시에 일반적으로 지원되는 언어 확장 기능을 모두 포함하는 언어 확장을 정의할 의도를 가지고 있습니다. requires-directive에서는 이러한 확장을 모든 공통 기능을 나열하는 약어로 사용할 수 있습니다. 이는 점진적으로 기능 집합이 증가하는 것을 나타내며, 일종의 언어 버전처럼 볼 수 있습니다.

4.2. 글로벌 진단 필터

글로벌 진단 필터는 영향 범위가 WGSL 모듈 전체에 해당하는 진단 필터입니다. 지시문이므로, 모든 모듈 범위 선언 이전에 나타납니다. 속성 형태와 동일하게 작성되지만 앞의 @(U+0040) 코드 포인트 없이, 마지막에 세미콜론을 붙입니다.

5. 선언과 범위

선언은 식별자와 아래 객체 중 하나를 연결합니다:

• 타입

• 타입 생성자

• 값

• 변수

• 함수

• 형식 매개변수

• 열거자

즉, 선언은 객체에 대한 이름을 도입합니다.

선언이 프로그램 소스에 나타나지만 다른 선언의 본문 밖에 있다면 모듈 범위에 있습니다.

함수 선언은 모듈 범위에 나타납니다. 함수 선언은 형식 매개변수 선언을 포함할 수 있고, 변수와 값 선언을 본문 내부에 포함할 수 있습니다. 이러한 선언들은 모듈 범위에 있지 않습니다.

참고: 다른 선언을 포함할 수 있는 선언은 함수 선언만 있습니다.

일부 객체는 WebGPU 구현에서 제공되며, WGSL 모듈 소스가 시작되기 전에 선언된 것으로 간주됩니다. 이러한 객체를 사전 선언됨이라 합니다. 예를 들어, WGSL은 다음을 사전 선언합니다:

• 내장 함수,

• i32, f32 등 내장 타입,

• array, ptr, texture_2d와 같은 내장 타입 생성자,

• 열거자 (예: read_write, workgroup, rgba8unorm)

범위란 선언된 식별자가 연관된 객체를 가리킬 수 있는 프로그램 소스 위치 집합입니다. 이러한 위치에서 식별자가 해당 선언의 범위 내에 있음이라고 합니다.

선언이 나타나는 위치에 따라 범위가 결정됩니다:

• 사전 선언 객체와 모듈 범위에 선언된 객체는 프로그램 전체에서 범위 내입니다.

• 사용자가 선언한 함수의 각 형식 매개변수는 해당 함수 본문 전체에서 범위 내입니다. 자세한 내용은 § 11.1 사용자 정의 함수 선언을 참고하세요.

• 그 외의 경우, 범위는 선언 끝 바로 뒤에서 시작하는 텍스트 구간입니다. 자세한 내용은 § 7 변수와 값 선언을 참고하세요.

같은 WGSL 소스 프로그램에서 두 선언은 동시에 다음을 허용하지 않아야 합니다:

• 동일한 식별자 이름을 도입하거나,

• 동일한 범위 끝(end-of-scope)을 갖는 경우

참고: 사전 선언 객체는 WGSL 소스 내에 선언이 없습니다. 따라서 사용자가 모듈 범위나 함수 내부에서 같은 이름의 선언을 할 수 있습니다.

식별자는 문법적 맥락에 따라 다음과 같이 사용됩니다:

• ident 문법 요소와 일치하는 토큰은:

  • 선언에서 객체 이름으로 사용되거나,

  • 다른 곳에서 선언된 객체를 나타내는 이름으로 사용됨. 이것이 일반적입니다.

• member_ident 문법 요소와 일치하는 토큰은:

  • 구조체 타입 선언에서 멤버 이름으로 사용되거나,

  • 구조체 값의 멤버를 나타내는 이름으로, 또는 구조체 멤버 참조를 나타내는 이름으로 사용됨. 자세한 내용은 § 8.5.4 구조체 접근 표현식 참고.

ident 토큰이 다른 곳에 선언된 객체를 나타내는 이름으로 사용될 때, 반드시 어떤 선언의 범위 내에 있어야 합니다. 식별자 토큰이 가리키는 객체는 다음과 같이 결정됩니다:

• 토큰이 하나 이상의 모듈 범위가 아닌(non-module-scope) 선언의 범위 내에 있다면, 그 중 가장 가까운 선언의 객체를 나타냅니다.

  참고: 가장 가까운 선언은 식별자 토큰 앞에 나타납니다.

• 그 외에, 해당 이름을 가진 모듈 범위 선언이 있다면, 토큰은 그 객체를 나타냅니다.

  참고: 모듈 범위 선언은 식별자 토큰 앞이나 뒤에 올 수 있습니다.

• 그 외에, 해당 이름을 가진 사전 선언 객체가 있다면, 그 객체를 나타냅니다.

위 알고리즘으로 식별자를 선언에 대응시킬 때, 식별자가 해당 선언으로 해석됨이라고 합니다. 또한 식별자가 선언된 객체로 해석됨이라고도 합니다.

모든 모듈 범위 선언이 재귀적인 경우 셰이더 생성 오류입니다. 즉, 선언들 사이에 순환(cycle)이 존재하면 안 됩니다:

다음과 같은 방향 그래프를 생각합니다:

• 각 노드는 선언 D에 해당합니다.

• 선언 D의 정의가 T로 해석되는 식별자를 언급하면 D에서 T로의 엣지가 있습니다.

이 그래프에는 순환이 없어야 합니다.

참고: 함수 본문은 함수 선언의 일부이므로, 함수는 직접적 또는 간접적으로 재귀적이어서는 안 됩니다.

참고: 모듈 범위가 아닌(non-module scope) 식별자 선언은 반드시 사용보다 먼저 텍스트에 나타나야 합니다.

// 올바름: 사용자 정의 변수는 내장 함수와 같은 이름을 가질 수 있음.
var<private> modf: f32 = 0.0;

// 올바름: foo_1은 프로그램 전체에서 범위 내.
var<private> foo: f32 = 0.0; // foo_1

// 올바름: bar_1은 프로그램 전체에서 범위 내.
var<private> bar: u32 = 0u; // bar_1

// 올바름: my_func_1은 프로그램 전체에서 범위 내.
// 올바름: foo_2는 함수 끝까지 범위 내.
fn my_func(foo: f32) { // my_func_1, foo_2
  // 'foo'에 대한 참조는 모두 함수 매개변수를 해석함.

  // 잘못됨: modf는 모듈 범위 변수로 해석됨.
  let res = modf(foo);

  // 잘못됨: foo_2의 범위는 함수 끝에서 끝남.
  var foo: f32; // foo_3

  // 올바름: bar_2는 함수 끝까지 범위 내.
  var bar: u32; // bar_2
  // 'bar'에 대한 참조는 bar_2로 해석함.
  {
    // 올바름: foo_4는 복합문 끝까지 범위 내.
    var foo : f32; // foo_4

    // 올바름: bar_3는 복합문 끝까지 범위 내.
    var bar: u32; // bar_3
    // 'bar'에 대한 참조는 bar_3로 해석함.

    // 잘못됨: bar_4는 bar_3과 같은 범위 끝을 가짐.
    var bar: i32; // bar_4

    // 올바름: i_1은 for 루프 끝까지 범위 내.
    for ( var i: i32 = 0; i < 10; i++ ) { // i_1
      // 잘못됨: i_2는 i_1과 같은 범위 끝을 가짐.
      var i: i32 = 1; // i_2.
    }
  }

  // 잘못됨: bar_5는 bar_2와 같은 범위 끝을 가짐.
  var bar: u32; // bar_5

  // 올바름: later_def(모듈 범위 선언)은 프로그램 전체에서 범위 내.
  var early_use : i32 = later_def;
}

// 잘못됨: bar_6은 bar_1과 같은 범위를 가짐.
var<private> bar: u32 = 1u; // bar_6

// 잘못됨: my_func_2는 my_func_1과 같은 범위 끝을 가짐.
fn my_func() { } // my_func_2

// 올바름: my_foo_1은 프로그램 전체에서 범위 내.
fn my_foo( //my_foo_1
  // 올바름: my_foo_2는 함수 끝까지 범위 내.
  my_foo: i32 // my_foo_2
) { }

var<private> later_def : i32 = 1;

// 이 선언은 사전 선언된 'min' 내장 함수를 가립니다.
// 이 선언은 모듈 범위에 있으므로 전체 소스에서 범위 내입니다.
// 내장 함수는 더이상 접근할 수 없습니다.
fn min() -> u32 { return 0; }

const rgba8unorm = 12; // 이 선언은 사전 선언된 'rgba8unorm' 열거자를 가립니다.

6. 타입

프로그램은 값을 계산합니다.

WGSL에서 타입은 값의 집합이며, 각 값은 정확히 하나의 타입에 속합니다. 값의 타입은 해당 값에 대해 수행할 수 있는 연산의 문법과 의미를 결정합니다.

예를 들어, 수학적 숫자 1은 WGSL에서 다음과 같은 개별 값에 해당합니다:

• 32비트 부호 있는 정수 값 1i,

• 32비트 부호 없는 정수 값 1u,

• 32비트 부동 소수점 값 1.0f,

• f16 확장이 활성화된 경우 16비트 부동 소수점 값 1.0h,

• AbstractInt 값 1,

• AbstractFloat 값 1.0

WGSL은 이 값들을 서로 다르게 취급하는데, 이는 기계적 표현과 연산이 다르기 때문입니다.

타입은 사전 선언됨이거나, WGSL 소스에서 선언을 통해 생성됩니다.

일부 타입은 템플릿 파라미터화로 표현됩니다. 타입 생성자는 사전 선언된 객체로, 템플릿 리스트와 결합될 때 타입을 나타냅니다. 예를 들어, atomic<u32> 타입은 타입 생성자 atomic과 템플릿 리스트 <u32>를 결합한 것입니다.

타입의 개념과 WGSL에서 해당 타입을 나타내는 문법을 구분합니다. 많은 경우 이 명세에서 타입의 표기법은 WGSL 문법과 동일합니다. 예를 들어:

• 32비트 부호 없는 정수 값 집합은 이 명세에서 u32라고 표기하며, WGSL 모듈에서도 동일하게 표기됩니다.

• 구조체 타입이나 구조체를 포함하는 타입의 경우 표기법이 다릅니다.

일부 WGSL 타입은 소스 프로그램을 분석하거나 프로그램의 런타임 동작을 결정하는 데만 사용됩니다. 이러한 타입은 명세에서 설명하지만 WGSL 소스 텍스트에는 나타나지 않습니다.

참고: 참조 타입은 WGSL 모듈에서 작성되지 않습니다. § 6.4.3 참조 및 포인터 타입 참고.

6.1. 타입 검사

WGSL 값은 표현식을 평가하여 계산됩니다. 표현식은 WGSL 문법 규칙 중 이름이 "expression"으로 끝나는 규칙으로 파싱된 소스 텍스트의 일부분입니다. 표현식 E는 외부 표현식 E에 올바르게 포함된 부분 표현식을 포함할 수 있습니다. 최상위 표현식은 스스로 부분 표현식이 아닌 표현식입니다. 자세한 내용은 § 8.18 표현식 문법 요약 참고.

표현식 평가로 생성되는 특정 값은 다음에 따라 결정됩니다:

• 정적 컨텍스트: 표현식을 둘러싼 소스 텍스트

• 동적 컨텍스트: 표현식을 평가하는 호출의 상태와 해당 호출이 실행 중인 실행 컨텍스트

특정 표현식을 평가한 결과 얻을 수 있는 값들은 항상 특정 WGSL 타입에 속하며, 이를 해당 표현식의 정적 타입이라 합니다. WGSL의 규칙은 표현식의 정적 타입이 오직 해당 표현식의 정적 컨텍스트에만 의존하도록 설계되어 있습니다.

타입 단언은 WGSL 소스 표현식에서 WGSL 타입으로의 매핑입니다. 표기법은 다음과 같습니다:

e : T

이는 e 표현식의 정적 타입이 T임을 의미하는 타입 단언입니다.

참고: 타입 단언은 프로그램 텍스트에 대한 사실 진술이며, 런타임 검사(runtime check)가 아닙니다.

문(statement)은 종종 표현식을 사용하며, 해당 표현식의 정적 타입에 대해 요구 사항을 둘 수 있습니다. 예를 들면:

• if 문에서 조건 표현식은 반드시 bool 타입이어야 합니다.

• 명시적 타입이 지정된 let 선언에서는 초기화 표현식이 해당 타입으로 평가되어야 합니다.

타입 검사란 성공적으로 파싱된 WGSL 모듈에서 각 표현식을 정적 타입에 매핑하고, 각 문(statement)의 타입 요구 사항이 만족되는지 확인하는 과정입니다. 타입 검사가 실패하면 셰이더 생성 오류의 특별한 경우인 타입 오류가 발생합니다.

타입 검사는 타입 규칙을 구문적 구절(구문적 문장)에 재귀적으로 적용하는 방식으로 수행할 수 있습니다. 여기서 구문적 구절은 표현식 또는 문(statement)입니다. 타입 규칙은 구문적 구절의 정적 컨텍스트가 해당 구절에 포함된 표현식의 정적 타입을 어떻게 결정하는지 설명합니다. 타입 규칙은 두 부분으로 구성됩니다:

• 결론.

  • 구절이 표현식이면, 결론은 해당 표현식에 대한 타입 단언입니다.

  • 구절이 문(statement)면, 결론은 그 문의 타입 단언들의 집합입니다. 각 문의 최상위 표현식마다 하나씩 있습니다.

  • 두 경우 모두, 구문적 구절은 도식적으로 지정되며, 이탤릭체 이름으로 부분 표현식이나 기타 구문적으로 결정된 매개변수를 나타냅니다.

• 전제 조건, 다음을 포함합니다:

  • 표현식의 경우:

    • 부분 표현식의 타입 단언(부분 표현식이 있다면). 각각은 직접 만족되거나, 가능한 자동 변환으로 만족될 수 있습니다(§ 6.1.2 변환 순위 참고). WGSL은 프로그램의 정적 타입을 결정하기 위해 필요한 모든 상수 표현식을 평가합니다.

    • 표현식이 문(statement)에서 어떻게 사용되는지.

  • 문의 경우:

    • 문의 구문적 형식과,

    • 문의 최상위 표현식에 대한 타입 단언.

  • 다른 도식적 매개변수에 대한 조건(있다면).

  • 옵션으로, 기타 정적 컨텍스트.

타입 규칙은 타입 파라미터를 전제 조건이나 결론에 포함할 수 있습니다. 타입 규칙의 결론이나 전제 조건에 타입 파라미터가 있으면 파라미터화됨이라고 하며, 그렇지 않으면 완전히 구체화됨이라 합니다. 파라미터화된 규칙에서 각 타입 파라미터에 대해 타입을 대입(substitute)하여 완전히 구체화된 타입 규칙을 만들 수 있습니다. 규칙의 타입 파라미터에 타입을 할당하는 작업을 치환(substitution)이라고 합니다.

예를 들어, 논리 부정 (!e 형태의 표현식)에 대한 타입 규칙은 다음과 같습니다:

이 규칙은 타입 파라미터 T를 포함하므로 파라미터화된 규칙입니다. T는 bool, vec2<bool>, vec3<bool>, vec4<bool> 중 하나의 타입을 나타낼 수 있습니다. T를 vec3<bool>로 치환하면 아래와 같은 완전히 구체화된 타입 규칙이 나옵니다:

파라미터화된 규칙에서 치환을 통해 얻을 수 있는 각 완전히 구체화된 규칙을 오버로드라고 합니다. 예를 들어, 불리언 부정 규칙에는 네 가지 오버로드가 있는데, 이는 타입 파라미터 T에 할당할 수 있는 네 가지 타입이 있기 때문입니다.

참고: 즉, 파라미터화된 타입 규칙은 여러 완전히 구체화된 타입 규칙의 패턴을 제공하며, 각각은 파라미터화된 규칙에 다른 치환을 적용해서 얻어집니다.

타입 규칙이 구문적 구절에 적용됨이란 다음 경우를 의미합니다:

• 규칙의 결론이 구문적 구절의 올바른 파싱과 일치하고,

• 규칙의 전제 조건이 만족됨.

파라미터화된 타입 규칙은 어떤 표현식에 대해 치환이 존재하여, 완전히 구체화된 타입 규칙을 만들고, 그 규칙이 해당 표현식에 적용될 때 적용된다고 합니다.

예를 들어, 1u+2u 표현식을 생각해 봅시다. 이 표현식에는 두 개의 리터럴 부분 표현식 1u, 2u가 있고, 둘 다 u32 타입입니다. 최상위 표현식은 덧셈입니다. § 8.7 산술 표현식의 규칙을 참고하면, 덧셈에 대한 타입 규칙이 이 표현식에 적용됩니다. 그 이유는:

• 1u+2u는 e1+e2 형태의 파싱과 일치하며, e1은 1u, e2는 2u를 나타냅니다.

• e1는 u32 타입이고,

• e2도 u32 타입이며,

• 타입 파라미터 T에 u32를 치환할 수 있으므로, 전체 표현식에 적용되는 완전히 구체화된 규칙을 얻을 수 있습니다.

구문적 구절을 분석할 때 세 가지 경우가 발생할 수 있습니다:

• 적용 가능한 타입 규칙이 없음: 타입 오류가 발생합니다.

• 적용 가능한 완전히 구체화된 타입 규칙이 정확히 하나 있는 경우, 해당 규칙의 결론이 단언되어 표현식의 정적 타입이 결정됩니다.

• 적용 가능한 타입 규칙이 둘 이상 있음: 즉, 둘 이상의 오버로드의 전제 조건이 만족됨. 이 경우 § 6.1.3 오버로드 해결의 절차를 사용합니다.

  • 오버로드 해결이 성공하면, 하나의 오버로드가 해당 표현식에 적용된다고 결정됩니다. 그 오버로드의 타입 단언이 결론에서 단언되어, 구문적 구절의 표현식(들)의 타입을 결정합니다.

  • 오버로드 해결이 실패하면 타입 오류가 발생합니다.

위 예시에서 1u+2u 표현식에는 하나의 타입 규칙만 적용되므로, 타입 검사는 해당 규칙의 결론인 1u+2u의 타입이 u32임을 받아들입니다.

WGSL 소스 프로그램이 정상적으로 타입이 지정됨(well-typed)이란 다음의 경우입니다:

• 프로그램의 각 표현식에 대해 타입 규칙을 적용하여 정적 타입을 결정할 수 있고,

• 각 문(statement)의 타입 요구 사항이 만족됨.

그렇지 않으면 타입 오류가 발생하며, 해당 소스 프로그램은 올바른 WGSL 모듈이 아닙니다.

WGSL은 정적 타입 언어인데, 이는 WGSL 모듈에 대해 타입 검사를 수행하면 성공하거나 타입 오류를 발견하며, 오직 프로그램 소스 텍스트만 검사하면 되기 때문입니다.

6.1.1. 타입 규칙 표

WGSL 타입 규칙은 표현식에 대해 타입 규칙 표로 구성되어 있으며, 각 타입 규칙마다 한 행이 있습니다.

표현식의 의미론은 해당 표현식을 평가한 효과이며, 주로 결과 값을 생성하는 것입니다. 적용되는 타입 규칙의 설명 열에 해당 표현식의 의미론이 명시되어 있습니다. 의미론은 보통 타입 규칙 파라미터의 값, 그리고 부분 표현식의 가정된 값에 따라 달라집니다. 때로 표현식의 의미론에는 결과 값 생성 외의 효과(부분 표현식의 결과값이 아닌 효과 등)도 포함될 수 있습니다.

fn foo(p : ptr<function, i32>) -> i32 {
  let x = *p;
  *p += 1;
  return x;
}

fn bar() {
  var a: i32;
  let x = foo(&a); // foo 호출은 값을 반환함
                   // 그리고 a의 값을 갱신함
}

6.1.2. 변환 순위

타입 단언 e:T가 타입 규칙의 전제 조건으로 사용될 때, 다음 중 하나면 만족됩니다:

• e가 이미 타입 T이면,

• e가 타입 S이고, 타입 S가 아래 정의에 따라 타입 T로 자동 변환 가능할 때

이 규칙은 아래 표에 정의된 타입 쌍에 대한 ConversionRank 함수로 공식화됩니다. ConversionRank 함수는 한 타입(Src) 값을 다른 타입(Dest)으로 자동 변환하는 우선순위와 가능성을 나타냅니다. 순위가 낮을수록 더 바람직합니다.

가능한 자동 변환은 Src 타입의 값을 Dest 타입으로 변환하는 것으로, ConversionRank(Src,Dest)가 유한할 때 허용됩니다. 이러한 변환은 § 15.7 부동 소수점 평가에 설명된 제한을 제외하면 값 보존적입니다.

참고: 자동 변환은 두 가지 상황에서만 발생합니다. 첫째, 상수 표현식을 GPU에서 사용할 수 있는 해당 타입의 숫자 값으로 변환할 때. 둘째, 메모리 참조에서 값을 로드할 때 발생합니다.

참고: 변환 순위가 무한대인 변환은 불가능(허용되지 않음)입니다.

참고: 변환이 수행되지 않으면 변환 순위는 0입니다.

타입 T는 타입 S의 구체화(concretization)이며, 다음이 성립할 때입니다:

• T가 구체 타입이고,

• T가 참조 타입이 아니며,

• ConversionRank(S, T)가 유한하며,

• 다른 참조가 아닌 타입 T2에 대해 ConversionRank(S, T2) > ConversionRank(S, T)임.

값 e가 타입 T일 때, 그 구체화(concretization)란 e에 대해 T에서 해당 구체화 타입으로 가능한 변환을 적용한 값을 의미합니다.

참고: f32로의 변환이 항상 f16보다 우선되므로, 자동 변환은 f16을 생성하려면 반드시 모듈에서 확장(extension)이 활성화되어 있어야 합니다.

6.1.3. 오버로드 해결

둘 이상의 타입 규칙이 구문적 구절에 적용될 때는 어떤 규칙을 적용할지 결정하기 위한 동점(타이브레이크) 절차가 사용됩니다. 이 절차를 오버로드 해결이라 하며, 타입 검사가 이미 부분 표현식에 대한 정적 타입을 찾은 상태를 전제로 합니다.

구문적 구절 P와, P에 적용되는 모든 타입 규칙을 생각해 봅시다. 오버로드 해결 알고리즘은 이러한 타입 규칙을 오버로드 후보라 부릅니다. 각 후보에 대해 다음이 성립합니다:

• 전제 조건이 직접 또는 자동 변환을 통해 만족됨.

• 결론이 다음을 가짐:

  • P의 올바른 파싱과 일치하는 구문 형식

  • P의 각 최상위 표현식에 해당하는 타입 단언

P에 대한 오버로드 해결은 다음과 같이 진행되며, 가장 우선되는 오버로드 후보 하나를 찾는 것이 목표입니다:

1. 각 후보 C에 대해, 구문적 구절의 부분 표현식에 대한 변환 순위를 열거합니다. 후보의 전제 조건이 만족되었으므로, P의 i번째 부분 표현식에 대해:

   • 정적 타입이 계산됨.

   • 해당 표현식의 정적 타입에서 전제 조건의 타입 단언이 요구하는 타입으로 가능한 자동 변환이 존재함. C.R(i)는 그 변환의 ConversionRank입니다.

2. 부분 표현식 중 하나가 가능한 자동 변환 이후 추상 타입으로 해석되고, 다른 후보의 부분 표현식 중 일부가 상수 표현식이 아닌 경우, 해당 후보를 제외합니다.

   참고: 결과적으로, 구절 내 부분 표현식 중 하나라도 상수 표현식이 아니면, 구절 내 모든 부분 표현식은 구체 타입이어야 합니다.

3. 후보 순위 결정: 두 오버로드 후보 C1, C2에 대해, C1이 더 우선됨이란 다음의 조건을 만족할 때입니다:

   • P의 각 표현식 위치 i에서 C1.R(i) ≤ C2.R(i).

     • 즉, C1을 P에 적용하는 데 필요한 각 표현식 변환이 C2를 적용할 때 요구되는 표현식 변환과 최소한 동일하거나 더 우선됨.

   • 적어도 한 표현식 위치 i에서 C1.R(i) < C2.R(i).

     • 즉, C1을 적용할 때 요구되는 표현식 변환 중 적어도 하나는 C2를 적용할 때보다 엄격히 더 우선됨.

4. 모든 후보에 대해 더 우선되는 단일 후보 C가 있으면 오버로드 해결이 성공하며, 해당 후보 타입 규칙 C를 반환합니다. 그렇지 않으면 오버로드 해결은 실패합니다.

6.2. 단순 타입

단순 타입이란 불리언 값, 숫자, 벡터, 행렬, 또는 이러한 값들의 집합의 기계적 표현을 위한 타입입니다.

단순 타입은 스칼라 타입, 원자적 타입, 또는 복합 타입 중 하나입니다.

참고: WGSL의 단순 타입은 C++의 Plain-Old-Data 타입과 유사하지만, 원자적 타입과 추상 수치 타입도 포함합니다.

6.2.1. 추상 수치 타입

이 타입들은 WGSL 소스에서 표기할 수 없습니다. 오직 타입 검사에만 사용됩니다.

특정 표현식은 셰이더 생성 시점에 평가되며, GPU가 직접 구현하는 것보다 더 넓은 숫자 범위와 정밀도를 가질 수 있습니다.

WGSL은 이러한 평가를 위해 두 가지 추상 수치 타입을 정의합니다:

• AbstractInt 타입은 64비트 이진수 보수(two’s complement) 형식으로 표현 가능한 정수 집합입니다. 최상위 비트가 부호 비트입니다.

• AbstractFloat 타입은 IEEE-754 binary64(배정밀도) 형식으로 표현 가능한 유한 부동 소수점 수 집합입니다.

이 타입들로 표현식을 평가할 때 오버플로우, 무한값 또는 NaN 값이 발생하면 안 됩니다.

타입이 추상 수치 타입이거나 추상 수치 타입을 포함하면 추상 타입입니다. 추상 타입이 아니면 구체 타입입니다.

숫자 리터럴에 접미사가 없으면 추상 수치 타입의 값을 나타냅니다:

• 정수 리터럴에 i 또는 u 접미사가 없으면 AbstractInt 값을 나타냅니다.

• 부동 소수점 리터럴에 f 또는 h 접미사가 없으면 AbstractFloat 값을 나타냅니다.

예시: log2(32) 표현식의 분석 과정:

• log2(32)는 log2 내장 함수에 AbstractInt 값 32를 인자로 호출한 것으로 파싱됩니다.

• log2에 정수 스칼라 형식 매개변수를 받는 오버로드는 없습니다.

• 대신 오버로드 해결이 적용되어, 세 가지 가능한 오버로드와 가능한 자동 변환을 고려합니다:

  • AbstractInt에서 AbstractFloat로. (변환 순위 4)

  • AbstractInt에서 f32로. (변환 순위 5)

  • AbstractInt에서 f16로. (변환 순위 6)

• 결국 연산은 AbstractFloat(예: log2(32.0))에서 수행됩니다.

예시: 1 + 2.5 표현식의 분석 과정:

• 1 + 2.5는 AbstractInt 값 1, AbstractFloat 값 2.5의 덧셈 연산으로 파싱됩니다.

• 정수 타입과 부동 소수점 타입의 덧셈 오버로드는 없습니다.

• 그러나 가능한 자동 변환을 이용하면 세 가지 오버로드가 있습니다:

  • 1이 AbstractFloat 값 1.0으로 변환(순위 4), 2.5는 AbstractFloat 그대로(순위 0).

  • 1이 f32 값 1.0f로 변환(순위 5), 2.5가 f32 값 2.5f로 변환(순위 1).

  • 1이 f16 값 1.0f로 변환(순위 6), 2.5가 f16 값 2.5h로 변환(순위 2).

• 첫 번째 오버로드가 우선 후보이며 타입 검사가 성공합니다.

• 결국 연산은 AbstractFloat 1.0 + 2.5로 수행됩니다.

예시: let x = 1 + 2.5;

• 이 예시는 위와 유사하지만, x는 추상 수치 타입으로 해석될 수 없습니다.

• 따라서 덧셈에서 f32 또는 f16을 사용하는 두 가지 오버로드 후보가 남습니다.

• 우선 후보는 f32를 사용합니다.

• 선언의 효과는 let x : f32 = 1.0f + 2.5f;와 같습니다.

예시: 1u + 2.5는 셰이더 생성 오류가 발생합니다:

• 1u는 u32 타입의 표현식입니다.

• 2.5는 AbstractFloat 타입의 표현식입니다.

• 유효한 오버로드 후보가 없습니다:

  • GPU-구현 타입 정수 스칼라에서 부동 소수점 타입으로의 자동 변환은 불가능합니다.

  • e+f에서 e가 정수 스칼라 타입이고 f가 부동 소수점 타입인 경우에 해당하는 타입 규칙이 없습니다.

예시: -1 * i32(-2147483648)는 셰이더 생성 오류가 발생하지 않습니다:

• -1는 AbstractInt 타입의 표현식입니다.

• i32(-2147483648)는 i32 타입의 표현식입니다.

• 이 두 타입에 대해 곱셈 연산자 오버로드가 없고, i32는 AbstractInt로 업컨버전(up-convert)할 수 없습니다.

• 가능한 자동 변환은 AbstractInt를 i32로 변환하는 것 뿐이므로:

  • 결국 연산은 i32 간의 곱셈 연산이 됩니다.

  • i32 연산은 이진수 보수(two’s complement) 산술을 사용하며 오버플로우가 정의되어 있습니다.

  • 값이 래핑(wrapping)됩니다.

// 명시적 타입의 부호 없는 정수 리터럴
var u32_1 = 1u; // 변수는 u32를 가짐

// 명시적 타입의 부호 있는 정수 리터럴
var i32_1 = 1i; // 변수는 i32를 가짐

// 명시적 타입의 부동 소수점 리터럴
var f32_1 = 1f; // 변수는 f32를 가짐

// 부호 없는 정수 리터럴은 음수로 만들 수 없음
var u32_neg = -1u; // 잘못됨: u32에 대해 단항 마이너스 지원 안 함

// 구체 타입이 요구되지만 어떤 부분도 특정 구체 타입을 강제하지 않으면, 정수 리터럴은 i32 값으로 해석됨:
//   let 선언의 초기화자는 생성 가능 타입(또는 포인터)이어야 함.
//   AbstractInt에서 생성 가능 타입으로의 자동 변환 중 가장 우선순위가 높은(순위 2) 변환은 AbstractInt에서 i32로 변환임.
//   그래서 '1'은 i32로 추론됨.
let some_i32 = 1; // let some_i32: i32 = 1i;와 같음

// 선언 타입에서 추론됨
var i32_from_type : i32 = 1; // 변수는 i32. AbstractInt에서 i32로 변환, 순위 2
var u32_from_type : u32 = 1; // 변수는 u32. AbstractInt에서 u32로 변환, 순위 3

// 접미사 없는 정수 리터럴은 필요할 때 부동 소수점으로 변환 가능:
//   AbstractInt에서 f32로 자동 변환, 순위 5
var f32_promotion : f32 = 1; // 변수는 f32

// 잘못됨: 부동 소수점에서 정수로 변환 불가능
var i32_demotion : i32 = 1.0; // 잘못됨

// 표현식에서 추론됨
var u32_from_expr = 1 + u32_1; // 변수는 u32
var i32_from_expr = 1 + i32_1; // 변수는 i32

// 값은 표현 가능해야 함
let u32_too_large   : u32 = 1234567890123456890; // 잘못됨, 오버플로우
let i32_too_large   : i32 = 1234567890123456890; // 잘못됨, 오버플로우
let u32_large : u32 = 2147483649; // 올바름
let i32_large : i32 = 2147483649; // 잘못됨, 오버플로우
let f32_out_of_range1 = 0x1p500; // 잘못됨, 범위 초과
let f32_hex_lost_bits = 0x1.0000000001p0; // 잘못됨, f32로 정확히 표현 불가

// 최소 정수: AbstractInt에 단항 마이너스, 그 다음 i32로 추론
// AbstractInt에서 생성 가능 타입으로의 자동 변환 중 가장 우선순위가 높은(순위 2) 변환은 AbstractInt에서 i32로 변환임
let i32_min = -2147483648;  // 타입은 i32

// 잘못됨. AbstractInt에서 i32로 변환하지만 값이 범위 초과하여 셰이더 생성 오류 발생
let i32_too_large_2 = 2147483648; // 잘못됨

// 부분 표현식은 AbstractInt와 AbstractFloat로 해석될 수 있음
// 아래 예시는 모두 올바르며 변수 값은 6u임
var u32_expr1 = (1 + (1 + (1 + (1 + 1)))) + 1u;
var u32_expr2 = 1u + (1 + (1 + (1 + (1 + 1))));
var u32_expr3 = (1 + (1 + (1 + (1u + 1)))) + 1;
var u32_expr4 = 1 + (1 + (1 + (1 + (1u + 1))));

// 내장 함수 매개변수에 기반한 추론

// 최우선 후보는 clamp(i32,i32,i32)->i32
let i32_clamp = clamp(1, -5, 5);
// 최우선 후보는 clamp(u32,u32,u32)
// 리터럴은 AbstractInt에서 u32로 자동 변환
let u32_clamp = clamp(5, 0, u32_from_expr);
// 최우선 후보는 clamp(f32,f32,f32)->f32
// 리터럴은 AbstractInt에서 f32로 자동 변환
let f32_clamp = clamp(0, f32_1, 1);

// 아래 예시는 모두 f32로 승격(promote)되어 초기값은 10f임
let f32_promotion1 = 1.0 + 2 + 3 + 4;
let f32_promotion2 = 2 + 1.0 + 3 + 4;
let f32_promotion3 = 1f + ((2 + 3) + 4);
let f32_promotion4 = ((2 + (3 + 1f)) + 4);

// 타입 규칙 위반

// 잘못됨, 초기화자는 f32로만 해석됨:
// AbstractFloat에서 u32로의 가능한 자동 변환 없음
let mismatch : u32 = 1.0;

// 잘못됨, clamp는 부호가 혼합된 매개변수를 허용하는 오버로드가 없음
let ambiguous_clamp = clamp(1u, 0, 1i);

// 구문 수준에서 타입 추론이 완료됨

// let 선언의 초기화자는 생성 가능 타입(또는 포인터)이어야 함
// AbstractInt에서 생성 가능 타입으로의 자동 변환 중 가장 우선순위가 높은(순위 2) 변환은 AbstractInt에서 i32로 변환임
let some_i32 = 1; // let some_i32: i32 = 1i;와 같음

let some_f32 : f32 = some_i32; // 타입 오류: i32는 f32에 할당할 수 없음

// 또 다른 오버플로우 사례
let overflow_u32 = (1 -2) + 1u; // 잘못됨, -1은 u32 범위 초과

// 32비트 범위를 벗어난 이상적 값이지만 다시 범위 내로 복귀
let out_and_in_again = (0x1ffffffff / 8);

// 유사하지만 잘못됨
let out_of_range = (0x1ffffffff / 8u); // 32비트에서 연산해야 하므로 0x1ffffffff는 범위 초과

6.2.2. 불리언 타입

bool 타입은 true와 false 값을 포함합니다.

6.2.3. 정수 타입

u32 타입은 32비트 부호 없는 정수 집합입니다.

i32 타입은 32비트 부호 있는 정수 집합입니다. 이진수 보수(two’s complement) 표현을 사용하며, 최상위 비트가 부호 비트입니다.

표현식에서 구체 정수 타입이 오버플로우되는 경우 결과는 2^bitwidth로 모듈로(modulo) 처리됩니다.

참고: AbstractInt도 정수 타입입니다.

6.2.4. 부동 소수점 타입

f32 타입은 IEEE-754 binary32(단정밀도) 형식의 32비트 부동 소수점 값 집합입니다. 자세한 내용은 § 15.7 부동 소수점 평가 참고.

f16 타입은 IEEE-754 binary16(반정밀도) 형식의 16비트 부동 소수점 값 집합입니다. f16 타입을 사용할 때 프로그램에 enable f16; 지시문이 포함되어 f16 확장이 활성화되지 않으면 셰이더 생성 오류가 발생합니다. 자세한 내용은 § 15.7 부동 소수점 평가 참고.

다음 표는 부동 소수점 타입의 일부 극단값을 나열합니다. 각 값에는 대응되는 음수 값이 있습니다.

참고: AbstractFloat도 부동 소수점 타입입니다.

6.2.5. 스칼라 타입

스칼라 타입은 bool, AbstractInt, AbstractFloat, i32, u32, f32, f16입니다.

수치 스칼라 타입은 AbstractInt, AbstractFloat, i32, u32, f32, f16입니다.

정수 스칼라 타입은 AbstractInt, i32, u32입니다.

스칼라 변환이란 한 스칼라 타입의 값을 다른 스칼라 타입의 값으로 매핑하는 것입니다. 일반적으로 결과 값은 원래 값과 유사하며, 대상 타입의 제한 내에서 결정됩니다. 스칼라 변환은 다음 경우에 발생합니다:

• 값 생성자를 명시적으로 호출하거나,

• 추상 수치 타입의 상수 표현식을 다른 타입으로 자동 변환할 때 발생합니다.

6.2.6. 벡터 타입

벡터란 2, 3, 4개의 스칼라 성분을 그룹화한 시퀀스입니다.

벡터의 성분 타입이 수치 스칼라인 경우 수치 벡터입니다.

벡터의 주요 용도는 다음과 같습니다:

• 방향과 크기를 동시에 표현

• 공간상의 위치 표현

• 어떤 색 공간 내의 색상 표현 예를 들어, 성분이 빨강, 초록, 파랑의 강도일 수 있고, 네 번째 성분은 알파(불투명도) 값일 수 있습니다.

벡터(및 행렬)에 대한 많은 연산은 성분별로 동작하며, 즉 결과는 각 스칼라 성분에 대해 독립적으로 연산하여 만들어집니다.

vec2<f32>  // 두 개의 f32로 이루어진 벡터입니다.

let x : vec3<f32> = a + b; // a와 b는 vec3<f32>
// x[0] = a[0] + b[0]
// x[1] = a[1] + b[1]
// x[2] = a[2] + b[2]

WGSL은 또한 다음 타입 별칭을 사전 선언합니다:

6.2.7. 행렬 타입

행렬은 2, 3, 4개의 부동 소수점 벡터를 그룹화한 시퀀스입니다.

행렬의 주요 용도는 선형 변환을 구현하는 것입니다. 이 해석에서 행렬의 벡터들은 열벡터로 취급됩니다.

곱셈 연산자(*)는 다음에 사용됩니다:

• 변환을 스칼라 크기로 스케일링

• 벡터에 변환 적용

• 다른 행렬과 변환 결합

§ 8.7 산술 표현식 참고.

mat2x3<f32>  // 2열 3행의 32비트 부동 소수점 행렬입니다.
             // 동치적으로, vec3<f32> 타입의 열벡터 2개입니다.

WGSL은 또한 다음 타입 별칭을 사전 선언합니다:

6.2.8. 원자적 타입

원자적 타입은 구체 정수 스칼라 타입을 캡슐화하며 다음을 만족해야 합니다:

• 원자 객체는 동시 관찰자에 대한 특정 보장을 제공합니다.

• 원자 객체에 대해 허용되는 연산은 원자 내장 함수뿐입니다.

표현식이 원자적 타입으로 평가되는 것은 허용되지 않습니다.

원자적 타입은 workgroup 주소 공간의 변수 또는 storage buffer 변수 중 read_write 접근 모드를 가진 변수에서만 인스턴스화할 수 있습니다. 해당 타입에 대한 연산의 메모리 범위는 인스턴스화된 주소 공간에 따라 결정됩니다. workgroup 주소 공간의 원자적 타입은 Workgroup 메모리 범위를 가지며, storage 주소 공간의 원자적 타입은 QueueFamily 메모리 범위를 가집니다.

원자적 수정은 원자 객체의 내용을 변경하는 연산입니다. 새 값이 기존 값과 같아도 수정으로 간주됩니다.

WGSL에서 원자적 수정은 각 객체에 대해 상호 순서가 보장됩니다. 즉, 셰이더 단계를 실행하는 동안 각 원자 객체 A에 대해 모든 에이전트는 A에 적용된 수정 연산의 동일한 순서를 관찰합니다. 다른 원자 객체 간의 순서는 관련이 없을 수 있으며, 인과관계가 암시되지 않습니다. workgroup 주소 공간의 변수는 하나의 workgroup 내에서 공유되지만, 서로 다른 workgroup 간에는 공유되지 않습니다.

6.2.9. 배열 타입

배열은 원소 값들의 인덱스 가능한 시퀀스입니다.

배열의 첫 번째 원소는 인덱스 0에 있고, 이후 각 원소는 다음 정수 인덱스에 위치합니다. § 8.5.3 배열 접근 표현식 참고.

런타임 크기 배열 타입으로 평가되는 표현식은 허용되지 않습니다.

고정 크기 배열의 원소 수 표현식 N은 다음 제약을 만족해야 합니다:

• override-expression이어야 합니다.

• 구체 정수 스칼라로 평가되어야 합니다.

• N이 0 이하인 경우:

  • N이 상수 표현식이면 셰이더 생성 오류입니다.

  • 그 외에는 파이프라인 생성 오류입니다.

참고: 원소 수 값은 N이 override 선언에 의존하면 파이프라인 생성 시점에, 그렇지 않으면 셰이더 모듈 생성 시점에 완전히 결정됩니다.

참고: 타입 동치성(type-equivalency)을 만족하려면, 상수 표현식이 아닌 override 표현식은 반드시 식별자여야 합니다. Override 가능한 상수로 크기가 지정된 workgroup 변수 예시 참고

런타임 크기 배열의 원소 수는 해당 storage buffer 변수에 연결된 버퍼 바인딩의 크기로 결정됩니다. § 13.3.4 버퍼 바인딩에 의해 결정되는 런타임 크기 배열 원소 수 참고.

배열의 원소 타입은 다음 중 하나여야 합니다:

• 스칼라 타입

• 벡터 타입

• 행렬 타입

• 원자적 타입

• 배열 타입(단, 생성 시점 고정 footprint를 가져야 함)

• 구조체 타입(단, 생성 시점 고정 footprint를 가져야 함)

참고: 원소 타입은 단순 타입이어야 합니다.

두 배열 타입이 동일한 경우는 다음 모두를 만족할 때입니다:

• 원소 타입이 동일

• 원소 수 규격이 일치, 즉 다음 중 하나:

  • 둘 다 런타임 크기

  • 둘 다 생성 시점 고정 footprint의 고정 크기이고, 원소 수가 동일한 값(부호가 다르더라도). (이 경우 부호가 다르더라도 원소 수는 항상 양수이므로 비교 가능)

  • 둘 다 식별자로 지정된 고정 크기이며, 해당 식별자가 같은 파이프라인 오버라이드 가능 상수 선언으로 해석됨.

// array<f32,8>와 array<i32,8>은 다른 타입입니다:
// 원소 타입이 다름
var<private> a: array<f32,8>;
var<private> b: array<i32,8>;
var<private> c: array<i32,8u>;  // array<i32,8>과 array<i32,8u>는 동일 타입

const width = 8;
const height = 8;

// array<i32,8>, array<i32,8u>, array<i32,width>는 모두 동일 타입입니다.
// 원소 수가 8로 평가됨
var<private> d: array<i32,width>;

// array<i32,height>와 array<i32,width>는 동일 타입입니다.
var<private> e: array<i32,width>;
var<private> f: array<i32,height>;

참고: 오버라이드 가능 상수로 크기가 지정된 배열 타입의 유효한 사용은 workgroup 주소 공간에서 메모리 뷰로 사용하는 경우뿐입니다. 여기에는 workgroup 변수의 스토어 타입이 포함됩니다. § 7 변수와 값 선언 참고.

override blockSize = 16;

var<workgroup> odds: array<i32,blockSize>;
var<workgroup> evens: array<i32,blockSize>; // 동일 타입

// 아래 예시들은 'odds', 'evens'과 동일 타입이 아닙니다.

// 다른 타입: 'blockSize' 식별자가 아님
var<workgroup> evens_0: array<i32,16>;
// 다른 타입: 원소 수를 산술식으로 표현
var<workgroup> evens_1: array<i32,(blockSize * 2 / 2)>;
// 다른 타입: 괄호로 식별자를 감쌈
var<workgroup> evens_2: array<i32,(blockSize)>;

// 잘못된 예시: 오버라이드 가능 원소 수는 반드시 가장 바깥 레벨에만 올 수 있음
// var<workgroup> both: array<array<i32,blockSize>,2>;

// 잘못된 예시: 오버라이드 가능 원소 수는 workgroup 변수에만 유효함
// var<private> bad_address_space: array<i32,blockSize>;

6.2.10. 구조체 타입

구조체는 이름이 있는 멤버 값들의 이름이 있는 그룹입니다.

구조체 타입은 모듈 범위에서 선언됩니다. 프로그램 소스의 다른 위치에서는 구조체 타입을 식별자 이름으로 나타냅니다. § 5 선언과 범위 참고.

두 구조체 타입이 동일하려면 이름이 같아야 합니다.

구조체 멤버 타입은 다음 중 하나여야 합니다:

• 스칼라 타입

• 벡터 타입

• 행렬 타입

• 원자적 타입

• 고정 크기 배열 타입(단, 생성 시점 고정 footprint를 가져야 함)

• 런타임 크기 배열 타입(단, 구조체의 마지막 멤버여야 함)

• 구조체 타입(단, 생성 시점 고정 footprint를 가져야 함)

참고: 모든 사용자 선언 구조체 타입은 구체 타입입니다.

참고: 각 멤버 타입은 단순 타입이어야 합니다.

구조체 멤버, 배열 원소 타입의 제한에 따른 결과:

• 포인터, 텍스처, 샘플러는 어떠한 배열/구조체 중첩에서도 나타나면 안 됩니다.

• 런타임 크기 배열이 더 큰 타입의 일부일 경우, 반드시 구조체의 마지막 원소로만 나타나야 하며, 해당 구조체는 다른 배열/구조체에 포함될 수 없습니다.

// 세 개 멤버를 가진 구조체
struct Data {
  a: i32,
  b: vec2<f32>,
  c: array<i32,10>, // 마지막 컴마는 선택사항
}

// Data 타입 값을 저장하는 변수 선언
var<private> some_data: Data;

구조체 멤버에 적용할 수 있는 속성(attribute)은 다음과 같습니다:

• align

• builtin

• location

• blend_src

• interpolate

• invariant

• size

builtin, location, blend_src, interpolate, invariant 속성은 IO 속성입니다. 구조체 S의 멤버에 적용된 IO 속성은 S가 형식 매개변수 또는 반환 타입으로서 엔트리 포인트에서 사용될 때에만 효과가 있습니다. § 13.3.1 셰이더 단계 간 입력/출력 인터페이스 참고.

align, size 속성은 레이아웃 속성이며, 구조체 타입이 유니폼 버퍼 또는 스토리지 버퍼 정의에 사용될 때 필요할 수 있습니다. § 14.4 메모리 레이아웃 참고.

struct my_struct {
  a: f32,
  b: vec4<f32>
}

// 런타임 배열
alias RTArr = array<vec4<f32>>;
struct S {
  a: f32,
  b: f32,
  data: RTArr
}
@group(0) @binding(0) var<storage> buffer: S;

6.2.11. 복합 타입

타입이 내부 구조를 다른 타입들의 조합(composition)으로 표현한다면 복합입니다. 내부 부분은 겹치지 않으며, 이를 성분이라고 합니다. 복합 값은 성분으로 분해할 수 있습니다. § 8.5 복합 값 분해 표현식 참고.

복합 타입에는 다음이 있습니다:

• 벡터 타입

• 행렬 타입

• 배열 타입

• 구조체 타입

복합 타입 T에 대해, 중첩 깊이(nesting depth), NestDepth(T)는 다음과 같습니다:

• 벡터 타입이면 1

• 행렬 타입이면 2

• 배열 타입(원소 타입 E)이면 1 + NestDepth(E)

• 구조체 타입(멤버 타입 M₁,...,M_N)이면 1 + max(NestDepth(M₁),..., NestDepth(M_N))

6.2.12. 생성 가능한 타입

많은 종류의 값은 생성, 로드, 저장, 함수에 전달, 함수에서 반환할 수 있습니다. 이를 생성 가능이라고 합니다.

다음 중 하나인 타입은 생성 가능 타입입니다:

• 스칼라 타입

• 벡터 타입

• 행렬 타입

• 고정 크기 배열 타입(단, 생성 시점 고정 footprint를 가지며 원소 타입도 생성 가능이어야 함)

• 구조체 타입(단, 모든 멤버가 생성 가능이어야 함)

참고: 모든 생성 가능 타입은 생성 시점 고정 footprint를 가집니다.

참고: 원자적 타입과 런타임 크기 배열 타입은 생성 가능이 아닙니다. 원자적 또는 런타임 크기 배열을 포함하는 복합 타입도 생성 가능이 아닙니다.

6.2.13. 고정 footprint 타입

변수의 메모리 footprint란 변수의 내용을 저장하는 데 사용되는 메모리 위치의 수입니다. 변수의 메모리 footprint는 스토어 타입에 따라 달라지며, 이는 셰이더 생명주기의 어느 시점에서 확정됩니다. 대부분의 변수는 셰이더 생성 시점에 크기가 결정됩니다. 일부 변수는 파이프라인 생성 시점에, 또 다른 변수는 셰이더 실행 시작까지 늦춰질 수 있습니다.

타입이 생성 시점 고정 footprint를 가진다는 것은, 해당 타입의 구체화의 크기가 셰이더 생성 시점에 완전히 결정된다는 뜻입니다.

타입이 고정 footprint를 가진다는 것은, 크기가 파이프라인 생성 시점에 완전히 결정되는 것을 의미합니다.

참고: 모든 구체 생성 시점 고정 footprint 및 고정 footprint 타입은 저장 가능입니다.

참고: 파이프라인 생성은 셰이더 생성에 의존하므로, 생성 시점 고정 footprint가 있으면 고정 footprint도 가집니다.

생성 시점 고정 footprint를 가진 타입은 다음과 같습니다:

• 스칼라 타입

• 벡터 타입

• 행렬 타입

• 원자적 타입

• 고정 크기 배열 타입(단,

  • 그 원소 수가 상수 표현식일 때

• 구조체 타입(단, 모든 멤버가 생성 시점 고정 footprint를 가져야 함)

참고: 생성 가능 타입은 생성 시점 고정 footprint를 가집니다.

단순 타입 중 고정 footprint를 가진 것은 다음 중 하나입니다:

• 생성 시점 고정 footprint를 가진 타입

• 고정 크기 배열 타입(원소 수 제한 없이)

참고: 상수 표현식이 아닌 override-expression으로 원소 수가 지정된 고정 크기 배열의 유효한 사용은 workgroup 주소 공간의 메모리 뷰로 사용하는 경우뿐입니다. 여기에는 workgroup 변수의 스토어 타입이 포함됩니다.

참고: 고정 footprint 타입은 직접 또는 간접적으로 원자적 타입을 포함할 수 있지만, 생성 가능 타입은 포함할 수 없습니다.

참고: 고정 footprint 타입에는 런타임 크기 배열과, 런타임 크기 배열을 포함하는 구조체가 제외됩니다.

6.3. 열거 타입

열거 타입은 제한된 개수의 이름이 있는 값 집합입니다. 열거는 특정 개념(예: 유효한 텍셀 포맷 집합 등)의 가능한 선택지를 구분하는 데 사용됩니다.

열거자는 열거 타입의 이름이 있는 값 중 하나입니다. 각 열거자는 다른 열거자 및 다른 종류의 값들과 구분됩니다.

WGSL 소스에서 새로운 열거자나 열거 타입을 선언하는 방법은 없습니다.

참고: 열거자는 템플릿 파라미터로 사용됩니다.

6.3.1. 사전 선언 열거자

다음 표는 WGSL의 열거 타입과, 그 사전 선언된 열거자를 나열합니다. 열거 타입은 존재하지만 WGSL 소스에서 표기할 수 없습니다.

6.4. 메모리 뷰

WGSL 프로그램은 단순 값 계산뿐만 아니라, 메모리에서 값을 읽거나 메모리에 값을 기록하는 경우가 많으며, 이는 메모리 접근 연산을 통해 이루어집니다. 각 메모리 접근은 메모리 뷰를 통해 수행됩니다.

메모리 뷰는 다음으로 구성됩니다:

• 특정 주소 공간 내 메모리 위치 집합,

• 메모리 모델 참조,

• 해당 위치의 내용을 WGSL 타입으로 해석한 것(스토어 타입), 그리고

• 접근 모드.

메모리 뷰의 접근 모드는 해당 주소 공간에서 지원되어야 합니다. § 7 변수와 값 선언 참고.

6.4.1. 저장 가능 타입

변수에 저장된 값은 반드시 저장 가능 타입이어야 합니다. 저장 가능 타입은 WGSL에서 명시적 표현을 가질 수도 있고(§ 14.4.4 값의 내부 레이아웃 참고), 텍스처나 샘플러처럼 불투명할 수도 있습니다.

타입이 저장 가능이려면, 구체 타입이면서 다음 중 하나여야 합니다:

• 스칼라 타입

• 벡터 타입

• 행렬 타입

• 원자적 타입

• 배열 타입

• 구조체 타입

• 텍스처 타입

• 샘플러 타입

참고: 즉, 저장 가능 타입은 구체 단순 타입, 텍스처 타입, 샘플러 타입입니다.

6.4.2. 호스트 공유 가능 타입

호스트 공유 가능 타입은 호스트와 GPU 사이에서 공유되는 버퍼의 내용을 나타내거나, 형식 변환 없이 호스트와 GPU 사이에서 복사되는 데이터에 사용됩니다. 이 목적에 사용할 때는 레이아웃 속성을 적용할 수 있습니다(§ 14.4 메모리 레이아웃 참고). § 7.3 var 선언에 설명된 대로, 유니폼 버퍼와 스토리지 버퍼 변수의 스토어 타입은 반드시 호스트 공유 가능 타입이어야 합니다.

타입이 호스트 공유 가능이려면, 구체 타입이면서 다음 중 하나여야 합니다:

• 수치 스칼라 타입

• 수치 벡터 타입

• 행렬 타입

• 원자적 타입

• 고정 크기 배열 타입(단, 생성 시점 고정 footprint를 가지며 원소 타입도 호스트 공유 가능이어야 함)

• 런타임 크기 배열 타입(단, 원소 타입도 호스트 공유 가능이어야 함)

• 구조체 타입(단, 모든 멤버가 호스트 공유 가능이어야 함)

참고: 셰이더 단계 간 입력/출력 타입의 제한은 § 13.3.1 셰이더 단계 간 입력/출력 인터페이스 및 이후 절에 설명되어 있습니다. 해당 타입들도 사이즈가 결정되지만, 계산 방식이 다릅니다.

참고: 텍스처와 샘플러도 호스트와 GPU 사이에서 공유될 수 있지만, 내용은 불투명합니다. 이 절의 호스트 공유 가능 타입은 특히 storage와 uniform 버퍼에 사용됩니다.

6.4.3. 참조 및 포인터 타입

WGSL에는 메모리 뷰를 표현하는 두 종류의 타입이 있습니다: 참조 타입과 포인터 타입입니다.

두 포인터 타입이 동일하려면 주소 공간, 스토어 타입, 접근 모드가 모두 같아야 합니다.

WGSL 모듈을 분석할 때 참조 및 포인터 타입은 주소 공간, 저장 가능 타입, 접근 모드로 완전히 매개변수화됩니다. 이 명세의 코드 예시에서 주석은 이 완전히 매개변수화된 형태를 보여줍니다.

하지만 WGSL 소스 텍스트에서는:

• 참조 타입은 나타나면 안 됩니다.

• 포인터 타입은 나타날 수 있습니다.

  • 포인터 타입은 다음을 파라미터화하여 표기됩니다:

    • 주소 공간,

    • 스토어 타입,

    • 때때로 접근 모드도, § 14.3 주소 공간에 명시된 대로.

  • 프로그램 소스에 포인터 타입이 나타나면, 해당 포인터 타입의 주소 공간, 스토어 타입, 접근 모드로 변수를 선언하는 것도 반드시 가능해야 합니다.

    참고: 이 제한은 런타임에서 사용할 수 없는 타입 별칭과 함수 형식 매개변수 선언을 금지합니다. 이 제한이 없으면 포인터 타입의 별칭 선언은 유효하지만 해당 타입의 포인터 값을 생성할 수 없게 됩니다. 마찬가지로 포인터 형식 매개변수를 가진 함수 선언은 가능하지만 해당 함수를 호출할 수 없게 됩니다.

fn my_function(
  /* 'ptr<function,i32,read_write>'는 'function' 주소 공간의 메모리 위치를 참조하는 포인터 값의 타입입니다.
     여기에 'i32'가 스토어 타입입니다.
     암시적 접근 모드는 'read_write'입니다.
     기본값은 "주소 공간" 절 참고. */
  ptr_int: ptr<function,i32>,

  // 'ptr<private,array<f32,50>,read_write>'는 'private' 주소 공간의 메모리 위치를 참조하는 포인터 타입입니다.
  // 여기서 스토어 타입은 'array<f32,50>'입니다.
  // 암시적 접근 모드는 'read_write'입니다.
  // 기본값은 "주소 공간" 절 참고.
  ptr_array: ptr<private, array<f32, 50>>
) { }

참조 타입과 포인터 타입은 모두 메모리 뷰 집합입니다: 특정 메모리 뷰는 고유한 참조 값과 고유한 포인터 값에 대응합니다:

ptr<AS,T,AM> 타입의 각 포인터 값 p는 ref<AS,T,AM> 타입의 고유 참조 값 r에 대응하며, 그 반대도 성립합니다. 여기서 p와 r는 동일한 메모리 뷰를 나타냅니다.

6.4.4. 유효/무효 메모리 참조

참조 값은 유효 또는 무효입니다.

참조는 § 6.4.8 참조와 포인터 값 형성에서 자세히 설명된 대로 형성됩니다. 일반적으로 유효 참조는 다음과 같이 형성됩니다:

• 변수 이름으로, 또는

• 유효 포인터에 간접 참조(단항 *) 연산을 적용, 또는

• 메모리 뷰가 유효한 base인 이름 있는 성분 표현식, 또는

• 메모리 뷰가 유효한 base인 인덱싱 표현식, 그리고 범위 내 인덱스 사용.

일반적으로 무효 메모리 참조는 다음과 같이 형성됩니다:

• 무효 포인터에 간접 연산자를 적용, 또는

• base가 무효 메모리 참조인 이름 있는 성분 표현식, 또는

• 기반이 메모리 뷰인 인덱싱 표현식에서:

  • base가 무효 메모리 참조이거나,

  • 인덱스가 범위 밖인 경우.

유효 포인터는 유효 참조에 대응하는 포인터입니다. 무효 포인터는 무효 메모리 참조에 대응하는 포인터입니다.

6.4.5. 기원 변수

포인터 값의 기원 변수는 해당 참조 값의 기원 변수로 정의됩니다.

참고: 기원 변수는 동적 개념입니다. 함수의 형식 매개변수에 대한 기원 변수는 호출 지점에 따라 다릅니다. 서로 다른 호출 지점에서 서로 다른 기원 변수에 대한 포인터를 전달할 수 있습니다.

유효 참조는 항상 어떤 변수의 메모리 위치의 일부 또는 전체에 대해 비어 있지 않은 메모리 뷰에 대응합니다.

struct Particle {
   position: vec2f,
   velocity: vec2f,
   color_index: i32,
}

@group(0) @binding(0)
var<storage,read_write> the_particle: Particle;

fn particle_velocity_component(p: Particle, i: i32) -> f32 {
  return the_particle.velocity[i]; // i가 0 또는 1일 때 유효 참조
}

6.4.6. 범위 밖 접근

무효 메모리 참조에 접근하는 연산은 범위 밖 접근입니다.

범위 밖 접근은 프로그램 결함입니다. 실제로 실행된다면 일반적으로:

• 변수 외부의 메모리 위치를 읽거나 쓸 수 있고,

• 해당 위치 내용을 잘못된 스토어 타입으로 해석하거나,

• 의도하지 않은 데이터 레이스를 유발할 수 있습니다.

이러한 이유로 구현체는 절대 해당 접근을 그대로 수행하지 않습니다. 범위 밖 접근을 실행하면 동적 오류가 발생합니다.

참고: 잘못된 스토어 타입 해석의 예시는 이전 섹션의 예시를 참고하세요. i가 2일 때 the_particle.velocity[i]의 타입은 ref<storage,f32,read_write>이며, 즉 f32가 스토어 타입인 메모리 뷰입니다. 하지만 실제 메모리 위치는 color_index 멤버에 할당되어 있으므로, 저장된 값은 실제로 i32 타입입니다.

6.4.7. 참조 및 포인터 활용 사례

참조와 포인터는 사용 방식에 따라 구분됩니다:

• 변수의 타입은 참조 타입입니다.

• 주소 연산(단항 &)은 참조 값을 그에 대응하는 포인터 값으로 변환합니다.

• 간접 참조(단항 *)는 포인터 값을 그에 대응하는 참조 값으로 변환합니다.

• let 선언은 포인터 타입일 수 있지만, 참조 타입일 수는 없습니다.

• 형식 매개변수는 포인터 타입일 수 있지만, 참조 타입일 수는 없습니다.

• 단순 할당 문은 참조를 통해 메모리 내용을 갱신하는 쓰기 접근을 수행합니다. 이때:

  • 할당 문의 좌변은 반드시 write 또는 read_write 접근 모드의 참조 타입이어야 합니다.

  • 할당 문의 우변은 반드시 좌변의 스토어 타입으로 평가되어야 합니다.

• 로드 규칙: 함수 내부에서 참조는 타입 규칙을 만족시키기 위해 자동으로 역참조(읽기)됩니다:

  • 함수에서 스토어 타입 T의 참조 표현식 r이 문 또는 표현식에서 사용될 때,

  • r의 접근 모드가 read 또는 read_write이고,

  • 잠재적으로 일치하는 타입 규칙이 r이 타입 T 값을 가져야 하는 경우에만 있다면,

  • 해당 타입 규칙 요구 사항이 만족된 것으로 간주되고,

  • 그 문맥에서 r를 평가한 결과는 r가 참조하는 메모리 위치에서 평가 시점에 저장된 T 타입 값입니다. 즉, 결과 값을 얻기 위해 읽기 접근이 수행됩니다.

이렇게 참조를 정의하면 변수의 간단한 관용적 사용이 가능합니다:

@compute @workgroup_size(1)
fn main() {
  // 'i'의 타입은 ref<function,i32,read_write>
  // 'i'의 메모리 위치는 i32 값 0을 저장
  var i: i32 = 0;

  // 'i + 1'은 'i' 부분 표현식이 i32 타입일 때만 타입 규칙에 일치함.
  // 그래서 'i + 1' 표현식은 i32 타입이고, 평가 시점에 'i' 부분 표현식은
  // 그 시점의 'i' 메모리 위치에 저장된 i32 값으로 평가됨.
  let one: i32 = i + 1;

  // 'i'가 참조하는 위치의 값을 2로 갱신
  i = one + 1;

  // 'i'가 참조하는 위치의 값을 5로 갱신
  // 우변의 평가가 할당 전에 발생함
  i = i + 3;
}

var<private> age: i32;
fn get_age() -> i32 {
  // return 문 표현식의 타입은 반드시 i32여야 하며, 이는 함수 반환 타입과 일치해야 함.
  // 'age' 표현식의 타입은 ref<private,i32,read_write>임.
  // 로드 규칙 적용: 참조의 스토어 타입이 요구된 표현식 타입과 일치하며, 다른 타입 규칙은 없음.
  // 이 문맥에서 'age'의 평가는 return 실행 시점의 age가 참조하는 메모리 위치에서 로드된 i32 값임.
  return age;
}

fn caller() {
  age = 21;
  // copy_age 상수는 i32 값 21을 가짐
  let copy_age: i32 = get_age();
}

이렇게 포인터를 정의하면 두 가지 주요 활용 사례가 가능합니다:

• 포인터 타입의 let 선언을 사용하여 변수 내용의 일부에 대해 짧은 이름을 만듦.

• 함수의 형식 매개변수로 포인터를 사용하여 호출 함수가 접근할 수 있는 변수의 메모리에 직접 접근함.

  • 이런 함수 호출 시 반드시 해당 피연산자에 포인터 값을 전달해야 함. 이를 위해 주소 연산(단항 &)을 사용하여 변수 내용의 포인터를 얻는 경우가 많음.

struct Particle {
  position: vec3<f32>,
  velocity: vec3<f32>
}
struct System {
  active_index: i32,
  timestep: f32,
  particles: array<Particle,100>
}
@group(0) @binding(0)
var<storage,read_write> system: System;

@compute @workgroup_size(1)
fn main() {
  // 스토리지 메모리 내 특정 Particle에 대한 포인터 형성
  let active_particle = &system.particles[system.active_index];

  let delta_position: vec3<f32> = (*active_particle).velocity * system.timestep;
  let current_position: vec3<f32>  = (*active_particle).position;
  (*active_particle).position = delta_position + current_position;
}

fn add_one(x: ptr<function,i32>) {
  /* 'x'가 가리키는 위치에 다음 더 큰 정수값을 저장하거나,
     i32의 가장 작은 음수 값으로 래핑합니다.
     좌변에서 단항 '*'는 포인터를 참조로 변환하여,
     대입이 가능하게 합니다. 기본적으로 read_write 접근 모드를 가집니다.
     /* 우변에서는:
        - 단항 '*'는 포인터를 참조로 변환하며, read_write 접근 모드입니다.
        - 덧셈(+)에 대한 유일한 타입 규칙은 '*x'가 i32 타입이어야 하며,
          이는 '*x'의 store type입니다. 그래서 Load Rule이 적용되어
          평가 시점의 '*x' 메모리의 값을 가져옵니다. 즉, 0의 i32 값입니다.
        - 0에 1을 더하여, 우변의 최종 값은 1이 됩니다. */
     1을 '*x'가 가리키는 메모리에 저장합니다. */
  *x = *x + 1;
}

@compute @workgroup_size(1)
fn main() {
  var i: i32 = 0;

  // 'i'의 값을 1로 변경합니다.
  // 단항 '&'를 사용해 'i'의 포인터 값을 가져옵니다.
  // 호출된 함수가 'i'의 메모리에 접근할 수 있고,
  // 값을 변경할 수 있음을 명확히 나타냅니다.
  add_one(&i);
  let one: i32 = i;  // 'one'의 값은 1.
}

6.4.8. 참조와 포인터 값 형성

참조 값은 다음 방법 중 하나로 형성됩니다:

• 식별자가 해석되어 스코프 내 변수 v를 가리키면, v의 메모리에 대한 참조 값이 된다.

• 포인터에 간접 참조(단항 *) 연산을 사용.

• 메모리 뷰를 복합 타입에 대한 이름 있는 성분 표현식으로 사용:

  • 스토어 타입이 벡터인 메모리 뷰의 경우, 한 글자 벡터 접근 구문을 붙이면 벡터의 해당 성분에 대한 참조가 된다. § 8.5.1.3 벡터 메모리 뷰의 성분 참조 참고.

  • 스토어 타입이 구조체인 메모리 뷰의 경우, 멤버 접근 구문을 붙이면 구조체의 해당 멤버에 대한 참조가 된다. § 8.5.4 구조체 접근 표현식 참고.

• 메모리 뷰를 복합 타입에 대한 인덱싱 표현식으로 사용:

  • 스토어 타입이 벡터인 메모리 뷰의 경우, 배열 인덱스 접근 구문을 붙이면 벡터의 해당 인덱스 성분에 대한 참조가 된다. § 8.5.1.3 벡터 메모리 뷰의 성분 참조 참고.

  • 스토어 타입이 행렬인 메모리 뷰의 경우, 배열 인덱스 접근 구문을 붙이면 행렬의 해당 열 벡터에 대한 참조가 된다. § 8.5.2 행렬 접근 표현식 참고.

  • 스토어 타입이 배열인 메모리 뷰의 경우, 배열 인덱스 접근 구문을 붙이면 배열의 해당 원소에 대한 참조가 된다. § 8.5.3 배열 접근 표현식 참고.

모든 경우에서 결과의 접근 모드는 원래 참조의 접근 모드와 동일합니다.

struct S {
    age: i32,
    weight: f32
}
var<private> person: S;
// 다른 위치에서 'person'은 해당 변수의 메모리에 대한 참조를 나타내며,
// 타입은 ref<private,S,read_write>입니다.

fn f() {
    var uv: vec2<f32>;
    // 이 함수 본문 내에서 'uv'는 해당 변수의 메모리에 대한 참조를 나타내며,
    // 타입은 ref<function,vec2<f32>,read_write>입니다.

    // 대입문의 좌변 평가:
    //   'uv.x'를 평가하여 참조를 얻음:
    //   1. 'uv'를 평가하여 변수 'uv'의 메모리에 대한 참조를 얻음. 결과 타입은 ref<function,vec2<f32>,read_write>임.
    //   2. '.x' 벡터 접근구를 적용하여, 앞 단계에서 얻은 참조가 가리키는 벡터의 첫 번째 성분 메모리에 대한 참조를 얻음.
    //      결과 타입은 ref<function,f32,read_write>임.
    // 대입문의 우변을 평가하면 f32 값 1.0을 얻음.
    // uv.x가 참조하는 저장 메모리에 f32 값 1.0을 저장함.
    uv.x = 1.0;

    // 대입문의 좌변 평가:
    //   'uv[1]'을 평가하여 참조를 얻음:
    //   1. 'uv'를 평가하여 변수 'uv'의 메모리에 대한 참조를 얻음. 결과 타입은 ref<function,vec2<f32>,read_write>임.
    //   2. '[1]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 벡터의 두 번째 성분 메모리에 대한 참조를 얻음.
    //      결과 타입은 ref<function,f32,read_write>임.
    // 대입문의 우변을 평가하면 f32 값 2.0을 얻음.
    // uv[1]이 참조하는 저장 메모리에 f32 값 2.0을 저장함.
    uv[1] = 2.0;

    var m: mat3x2<f32>;
    // 'm[2]' 평가 시:
    // 1. 'm'을 평가하여 변수 'm'의 메모리에 대한 참조를 얻음. 결과 타입은 ref<function,mat3x2<f32>,read_write>임.
    // 2. '[2]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 행렬의 세 번째 열 벡터 메모리에 대한 참조를 얻음.
    //    결과는 ref<function,vec2<f32>,read_write> 타입임.
    // let 선언은 vec2<f32> 타입이므로, 초기화자는 vec2<f32> 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 m[2]가 참조하는 메모리에서 해당 시점의 vec2<f32> 값을 읽어옴.
    let p_m_col2: vec2<f32> = m[2];

    var A: array<i32,5>;
    // 'A[4]' 평가 시
    // 1. 'A'를 평가하여 변수 'A'의 메모리에 대한 참조를 얻음. 결과 타입은 ref<function,array<i32,5>,read_write>임.
    // 2. '[4]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 배열의 다섯 번째 요소 메모리에 대한 참조를 얻음.
    //    결과는 ref<function,i32,read_write> 타입임.
    // let 선언은 i32 타입이므로, 우변도 i32 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 A[4]가 참조하는 메모리에서 해당 시점의 i32 값을 읽어옴.
    let A_4_value: i32 = A[4];

    // 'person.weight' 평가 시
    // 1. 'person'을 평가하여 모듈 스코프에 선언된 변수 'person'의 메모리에 대한 참조를 얻음.
    //    결과 타입은 ref<private,S,read_write>임.
    // 2. '.weight' 멤버 접근구를 적용하여 앞 단계의 참조가 가리키는 메모리의 두 번째 멤버 메모리에 대한 참조를 얻음.
    //    결과 타입은 ref<private,f32,read_write>임.
    // let 선언은 f32 타입이므로, 우변도 f32 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 person.weight가 참조하는 메모리에서 해당 시점의 f32 값을 읽어옴.
    let person_weight: f32 = person.weight;

    // 또는, 동일 문법으로 포인터에서 참조를 생성할 수도 있음.

    let uv_ptr = &uv;
    // 이 함수 본문 내에서 'uv_ptr'은 'uv'의 메모리에 대한 포인터를 나타내며,
    // 타입은 ptr<function,vec2<f32>,read_write>입니다.

    // 대입문의 좌변 평가:
    //   '*uv_ptr'을 평가하여 참조를 얻음:
    //   1. 'uv_ptr'을 평가하여 변수 'uv'의 메모리에 대한 포인터를 얻음. 결과 타입은 ptr<function,vec2<f32>,read_write>임.
    //   2. 간접 참조 연산자를 적용하여 'uv'의 메모리에 대한 참조를 얻음.
    // 대입문의 우변을 평가하면 vec2<f32> 값 (1.0, 2.0)을 얻음.
    // uv가 참조하는 저장 메모리에 (1.0, 2.0) 값을 저장함.
    *uv_ptr = vec2f(1.0, 2.0);

    // 대입문의 좌변 평가:
    //   'uv_ptr.x'를 평가하여 참조를 얻음:
    //   1. 'uv_ptr'을 평가하여 변수 'uv'의 메모리에 대한 포인터를 얻음. 결과 타입은 ptr<function,vec2<f32>,read_write>임.
    //   2. '.x' 벡터 접근구를 적용하여 앞 단계의 참조가 가리키는 벡터의 첫 번째 성분 메모리에 대한 참조를 얻음.
    //      결과 타입은 ref<function,f32,read_write>임.
    // 대입문의 우변을 평가하면 f32 값 1.0을 얻음.
    // uv.x가 참조하는 저장 메모리에 f32 값 1.0을 저장함.
    uv_ptr.x = 1.0;

    // 대입문의 좌변 평가:
    //   'uv_ptr[1]'을 평가하여 참조를 얻음:
    //   1. 'uv_ptr'을 평가하여 변수 'uv'의 메모리에 대한 포인터를 얻음. 결과 타입은 ptr<function,vec2<f32>,read_write>임.
    //   2. '[1]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 벡터의 두 번째 성분 메모리에 대한 참조를 얻음.
    //      결과 타입은 ref<function,f32,read_write>임.
    // 대입문의 우변을 평가하면 f32 값 2.0을 얻음.
    // uv[1]이 참조하는 저장 메모리에 f32 값 2.0을 저장함.
    uv_ptr[1] = 2.0;

    let m_ptr = &m;
    // 'm_ptr[2]' 평가 시:
    // 1. 'm_ptr'을 평가하여 변수 'm'의 메모리에 대한 포인터를 얻음. 결과 타입은 ptr<function,mat3x2<f32>,read_write>임.
    // 2. '[2]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 행렬의 세 번째 열 벡터 메모리에 대한 참조를 얻음.
    //    결과는 ref<function,vec2<f32>,read_write> 타입임.
    // let 선언은 vec2<f32> 타입이므로, 초기화자는 vec2<f32> 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 m[2]가 참조하는 메모리에서 해당 시점의 vec2<f32> 값을 읽어옴.
    let p_m_col2: vec2<f32> = m_ptr[2];

    let A_ptr = &A;
    // 'A[4]' 평가 시
    // 1. 'A'를 평가하여 변수 'A'의 메모리에 대한 포인터를 얻음. 결과 타입은 ptr<function,array<i32,5>,read_write>임.
    // 2. '[4]' 배열 인덱스 구를 적용하여 앞 단계의 참조가 가리키는 배열의 다섯 번째 요소 메모리에 대한 참조를 얻음.
    //    결과는 ref<function,i32,read_write> 타입임.
    // let 선언은 i32 타입이므로, 우변도 i32 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 A[4]가 참조하는 메모리에서 해당 시점의 i32 값을 읽어옴.
    let A_4_value: i32 = A_ptr[4];

    let person_ptr = &person;
    // 'person.weight' 평가 시
    // 1. 'person_ptr'을 평가하여 모듈 스코프에 선언된 변수 'person'의 메모리에 대한 포인터를 얻음.
    //    결과 타입은 ptr<private,S,read_write>임.
    // 2. '.weight' 멤버 접근구를 적용하여 앞 단계의 참조가 가리키는 메모리의 두 번째 멤버 메모리에 대한 참조를 얻음.
    //    결과 타입은 ref<private,f32,read_write>임.
    // let 선언은 f32 타입이므로, 우변도 f32 타입이어야 함.
    // Load Rule이 적용되어, 초기화자는 person.weight가 참조하는 메모리에서 해당 시점의 f32 값을 읽어옴.
    let person_weight: f32 = person_ptr.weight;
}

포인터 값은 다음 방법 중 하나로 형성됩니다:

• 참조에 주소 연산(단항 &)을 사용.

  • 결과가 유효 포인터가 되려면 원래 참조가 유효해야 한다.

  • 유효 결과의 기원 변수는 참조의 기원 변수로 정의됨.

• 함수 형식 매개변수가 포인터 타입이면, 함수가 런타임에 호출될 때 해당 형식 매개변수의 사용은 호출 함수의 호출 지점에서 해당 피연산자에 전달된 포인터 값을 나타낸다.

  • 런타임에서 형식 매개변수가 나타내는 값은 호출 지점의 포인터 값이 유효할 때만 유효 포인터이다.

  • 런타임에서 유효 포인터 형식 매개변수의 기원 변수는 호출 지점의 포인터 피연산자의 기원 변수로 정의된다.

모든 경우에서 결과의 접근 모드는 원래 포인터의 접근 모드와 동일합니다.

// f32 값을 저장하기 위해 private 주소 공간에 변수를 선언합니다.
var<private> x: f32;

fn f() {
    // i32 값을 저장하기 위해 function 주소 공간에 변수를 선언합니다.
    var y: i32;

    // 'x' 이름은 모듈 스코프 변수 'x'로 해석되며,
    // 타입은 ref<private,f32,read_write>입니다.
    // 단항 '&' 연산자를 적용하면 참조가 포인터로 변환됩니다.
    // 접근 모드는 원본 변수의 접근 모드와 동일하므로,
    // 완전히 지정된 타입은 ptr<private,f32,read_write>입니다. 하지만 read_write는
    // function 주소 공간의 기본 접근 모드이므로 이 경우에는 read_write를 명시하지 않아도 됩니다.
    let x_ptr: ptr<private,f32> = &x;

    // 'y' 이름은 함수 스코프 변수 'y'로 해석되며,
    // 타입은 ref<private,i32,read_write>입니다.
    // 단항 '&' 연산자를 적용하면 참조가 포인터로 변환됩니다.
    // 접근 모드는 기본적으로 'read_write'입니다.
    let y_ptr: ptr<function,i32> = &y;

    // 모듈 스코프에서 선언된 변수와 구별되는 새로운 변수입니다.
    var x: u32;

    // 여기서 'x' 이름은 바로 앞에서 선언한 함수 스코프 변수 'x'로 해석되며,
    // 타입은 ref<function,u32,read_write>입니다.
    // 단항 '&' 연산자를 적용하면 참조가 포인터로 변환됩니다.
    // 접근 모드는 기본적으로 'read_write'입니다.
    let inner_x_ptr: ptr<function,u32> = &x;
}

6.4.9. 다른 언어의 참조 및 포인터와의 비교

이 절은 안내용이며, 규범적이지 않습니다.

WGSL의 참조와 포인터는 다른 언어보다 더 제한적입니다. 특히:

• WGSL에서는 참조를 다른 참조나 변수의 별칭(alias)로 직접 선언할 수 없습니다. 변수나 함수 형식 매개변수로서도 불가능합니다.

• WGSL에서 포인터와 참조는 저장 가능이 아닙니다. 즉, WGSL 변수 선언의 내용으로 포인터나 참조를 포함할 수 없습니다.

• WGSL에서는 함수가 포인터 또는 참조를 반환하면 안 됩니다.

• WGSL에서는 정수 값과 포인터 값 사이의 변환 방법이 없습니다.

• WGSL에서는 포인터 값을 강제로 다른 포인터 타입으로 바꾸는 방법이 없습니다.

  • 복합 성분 참조 표현식은 다릅니다: 복합 값에 대한 참조를 받아 그 값 내부 성분이나 원소에 대한 참조를 반환합니다. WGSL에서는 두 참조가 다르다고 간주되며, 구현의 더 낮은 수준에서 머신 주소가 같더라도 구분됩니다.

• WGSL에서는 참조 값을 강제로 다른 참조 타입으로 바꾸는 방법이 없습니다.

• WGSL에서는 포인터나 참조의 접근 모드를 변경하는 방법이 없습니다.

  • 비교하면, C++은 비-const 포인터를 const 포인터로 자동 변환하고, const_cast를 통해 const 값을 비-const 값으로 변환할 수 있습니다.

• WGSL에서는 "힙"에서 새로운 메모리를 할당하는 방법이 없습니다.

• WGSL에서는 변수를 명시적으로 파괴(destroy)할 방법이 없습니다. WGSL 변수의 메모리는 변수가 스코프를 벗어날 때만 접근할 수 없게 됩니다.

참고: 위 규칙에 따라 "댕글링(dangling)" 포인터, 즉 "live" 기원 변수를 참조하지 않는 포인터를 만드는 것은 불가능합니다. 메모리 뷰는 무효 메모리 참조일 수 있지만, 절대 기원 변수 또는 버퍼와 연결되지 않은 메모리 위치를 접근하지 않습니다.

6.5. 텍스처 및 샘플러 타입

텍셀(texel)은 텍스처의 가장 독립적으로 접근 가능한 최소 단위 성분인 스칼라 또는 벡터입니다. texel은 texture element의 줄임말입니다.

텍스처(texture)는 렌더링에 유용한 특수 연산을 지원하는 텍셀 집합입니다. WGSL에서는 이러한 연산을 텍스처 내장 함수(texture builtin functions)를 통해 수행합니다. 전체 목록은 § 17.7 텍스처 내장 함수 참고.

WGSL의 텍스처는 WebGPU GPUTexture에 해당합니다.

텍스처의 주요 특징은 다음과 같습니다:

텍셀 포맷

각 텍셀의 데이터 표현 방식. § 6.5.1 텍셀 포맷 참고.

차원 수(dimensionality)

좌표 격자의 차원 수 및 좌표 해석 방식. 차원 수는 1, 2, 3 중 하나. 대부분의 텍스처는 직교 좌표계를 사용. 큐브 텍스처는 6개의 정사각형 면을 가지며, 3차원 좌표를 원점에서 큐브를 향하는 방향 벡터로 해석해 샘플링함.

WebGPU GPUTextureViewDimension 참고.

크기(size)

각 차원별 격자 좌표의 범위. mip level에 따라 결정.

mip level 수

mip level 수는 샘플드 텍스처와 깊이 텍스처에 대해 최소 1이고, 스토리지 텍스처에 대해 1이다.
MIP level 0은 텍스처의 전체 크기 버전을 포함함. 각 다음 mip level은 이전 mip level의 필터링된 버전을 포함하며, 크기는 절반(반올림 포함)임.
텍스처 샘플링 시 명시적 또는 암시적으로 계산된 level-of-detail을 사용해 읽을 mip level을 선택하고, 필터링을 통해 샘플값을 생성함.

배열 여부(arrayed)

텍스처가 배열인지 여부.

• 비배열(texutre)은 텍셀의 격자(grid).

• 배열 텍스처는 동일한 격자의 배열임.

배열 크기(array size)

텍스처가 배열일 때 격자 개수.

샘플 개수(sample count)

텍스처가 멀티샘플일 때 샘플 개수.