Las override constants: una constante que se decide al crear el pipeline

Entre lo que se conoce al escribir el shader y lo que cambia cada fotograma hay un tercer momento que ningún lenguaje de shading tenía bien resuelto: lo que se decide al arrancar la aplicación y ya no cambia. WGSL le da un nombre y una sintaxis, y con ellos elimina la razón de ser del preprocesador sin traer sus problemas.

La declaración

override NUM_LUCES : u32 = 4u;         // con valor por defecto
override CALIDAD_SOMBRA : u32;         // sin el, hay que darlo al crear el pipeline
override USA_NIEBLA : bool = false;
override EXPOSICION : f32 = 1.0;

@id(100) override ESCALA : f32 = 1.0;  // con identificador numerico

Solo se declaran a nivel de módulo, nunca dentro de una función. Y solo admiten tipos escalares: bool, i32, u32, f32 y f16 si la extensión está activa. No hay override de tipo vector, ni de struct, ni de array.

La restricción a escalares no es arbitraria: el valor viaja desde JavaScript como un número suelto en un diccionario, y admitir tipos compuestos obligaría a definir un formato de serialización y sus reglas de alineación. Si necesitas un vector configurable, o son tres override escalares o es una uniform.

Un override sin valor por defecto es obligatorio: si no lo especificas al crear el pipeline, la creación falla con un error de validación. Uno con valor por defecto es opcional. La forma sin defecto es útil precisamente porque convierte un olvido en un error temprano en vez de en un comportamiento silencioso.

El valor por defecto puede ser una expresión que use const y otras override:

override TAM_TESELA : u32 = 16u;
override INVOCACIONES : u32 = TAM_TESELA * TAM_TESELA;

@id y lo que desacopla

Sin @id, la clave con la que se especifica el valor desde JavaScript es el nombre de la variable. Con @id(n), la clave es ese número.

@id(0) override NUM_LUCES : u32 = 4u;
@id(1) override USA_NIEBLA : bool = false;

constants: { 0: 8, 1: 1 },     // por identificador numerico

Los identificadores tienen que ser únicos en el módulo. La ventaja de usarlos es que renombrar la variable en el WGSL deja de romper el código de JavaScript, lo cual importa cuando el shader y el código que lo configura los mantiene gente distinta o cuando el WGSL se genera.

La desventaja es de legibilidad: un diccionario con claves numéricas no dice nada al leerlo. El punto medio que funciona es declarar los identificadores en una constante de JavaScript con nombres:

const OVR = { NUM_LUCES: 0, USA_NIEBLA: 1 };
const constants = { [OVR.NUM_LUCES]: 8, [OVR.USA_NIEBLA]: 1 };

Dónde vale una expresión override

Aquí está la parte que hay que saber de memoria, porque el compilador la aplica sin piedad. Una expresión override no es una expresión de tiempo de compilación, y por tanto no vale en los sitios que exigen una.

Sí vale:

• En cualquier expresión de tiempo de ejecución del cuerpo de una función.
• En @workgroup_size, en las tres dimensiones.
• Como número de elementos de un array en el espacio de direcciones workgroup.
• Como valor por defecto de otra override.

No vale:

• Como tamaño de un array en cualquier otro espacio de direcciones.
• En @location, @binding, @group, @align, @size ni @id.
• Como valor de un case de un switch.
• En el inicializador de una const.
• En un const_assert.

override TAM : u32 = 64u;

var<workgroup> parciales : array<f32, TAM>;      // legal: espacio workgroup
// var<private> tabla : array<f32, TAM>;         // ERROR: espacio private

@compute @workgroup_size(TAM)                    // legal
fn cs(@builtin(local_invocation_index) li : u32) {
  if li < TAM { parciales[li] = 0.0; }           // legal: expresion de ejecucion
}

La combinación de las dos cosas legales —el tamaño de grupo y el array de grupo— es exactamente lo que se necesita para escribir un kernel de reducción cuyo tamaño de bloque se decida al arrancar según lo que el dispositivo prefiera.

El siguiente paso es dárselos al pipeline: especificar constants al crear el pipeline.