Comprobar las features antes de pedirlas

Una feature de WebGPU es una capacidad opcional que el adaptador puede tener o no, y que tienes que pedir explícitamente para poder usarla. Suena trivial hasta que descubres las tres asimetrías: pedir una que no existe no degrada nada, revienta la creación del dispositivo; tener la feature en el adaptador no basta si no la pides; y la especificación define muchas más de las que cualquier navegador implementa hoy.

El catálogo y cómo se consulta

adapter.features y device.features son objetos de tipo conjunto de solo lectura: tienen size, has(), values(), keys(), entries() y forEach(), y se pueden recorrer con for...of. No son arrays, así que no tienen includes ni filter; si necesitas manipularlos, conviértelos con Array.from(adapter.features).

const adapter = await navigator.gpu?.requestAdapter();
if (!adapter) throw new Error('Sin adaptador WebGPU');

console.log('features del adaptador:', [...adapter.features].sort());
console.log('¿f16?', adapter.features.has('shader-f16'));

Los nombres son cadenas exactas y en minúsculas con guiones. Este es el catálogo que define la especificación, agrupado por para qué sirve cada uno:

Dos avisos que ahorran horas. El primero: que una feature esté en la especificación no significa que ningún navegador la implemente, y menos aún que tu GPU la tenga; la lista de arriba es lo que puede existir, no lo que vas a encontrar. El segundo: las tres familias de compresión de textura se reparten el mundo, con texture-compression-bc en escritorio, texture-compression-etc2 en Android y texture-compression-astc en móviles modernos y bastante escritorio reciente, así que si distribuyes texturas comprimidas necesitas los tres juegos de assets o aceptas volver a formatos sin comprimir.

Pedir sin que reviente

La regla es simple y las consecuencias de saltársela no lo son: si requiredFeatures contiene una feature que el adaptador no tiene, requestDevice() rechaza con un TypeError. No te da un dispositivo degradado ni ignora la petición. Se cae.

Por eso el array se construye filtrando, nunca a mano:

/** Pide solo las features que el adaptador ofrece de verdad. */
function negociarFeatures(
  adapter: GPUAdapter,
  deseadas: GPUFeatureName[],
): GPUFeatureName[] {
  return deseadas.filter((f) => adapter.features.has(f));
}

const deseadas: GPUFeatureName[] = [
  'timestamp-query',
  'shader-f16',
  'float32-filterable',
  'texture-compression-bc',
  'texture-compression-astc',
];

const device = await adapter.requestDevice({
  label: 'dispositivo-principal',
  requiredFeatures: negociarFeatures(adapter, deseadas),
});

Y a partir de ahí la fuente de verdad es device.features, no adapter.features. El adaptador te dice lo que podrías haber pedido; el dispositivo, lo que puedes usar. Consultar el adaptador después de crear el dispositivo es el error que produce el fallo más difícil de leer: la feature aparece disponible, la usas, y el error de validación te dice que no está habilitada.

Lo natural es congelar esa negociación en un objeto de capacidades que se calcula una vez y se consulta en todas partes:

export interface Capacidades {
  perfilado: boolean;
  mediaPrecision: boolean;
  hdrFiltrable: boolean;
  compresion: 'bc' | 'astc' | 'etc2' | 'ninguna';
}

export function leerCapacidades(device: GPUDevice): Capacidades {
  const f = device.features;
  return {
    perfilado: f.has('timestamp-query'),
    mediaPrecision: f.has('shader-f16'),
    hdrFiltrable: f.has('float32-filterable'),
    compresion: f.has('texture-compression-bc') ? 'bc'
      : f.has('texture-compression-astc') ? 'astc'
      : f.has('texture-compression-etc2') ? 'etc2'
      : 'ninguna',
  };
}

Ese objeto es el que decide qué shader se compila, qué formato se pide y qué assets se descargan. La alternativa (comprobar has() esparcido por el código) garantiza que un día una comprobación se olvide.

De la feature al shader

Varias features no se activan solo pidiéndolas: además hay que declarar la extensión correspondiente en el WGSL con una directiva enable al principio del módulo, antes de cualquier declaración. El caso más frecuente es la media precisión:

enable f16;

@group(0) @binding(0) var<storage, read_write> pesos: array<f16>;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) gid: vec3u) {
  let i = gid.x;
  if (i >= arrayLength(&pesos)) { return; }
  pesos[i] = pesos[i] * f16(0.5);
}

Si el dispositivo no tiene shader-f16, ese módulo ni siquiera compila, así que la variante en f16 y la variante en f32 tienen que ser dos fuentes distintas o una sola con la directiva y las declaraciones inyectadas por concatenación. La forma limpia es una función que devuelve el fuente según las capacidades:

function fuenteDelKernel(cap: Capacidades): string {
  const escalar = cap.mediaPrecision ? 'f16' : 'f32';
  const cabecera = cap.mediaPrecision ? 'enable f16;\n' : '';
  return `${cabecera}
@group(0) @binding(0) var<storage, read_write> pesos: array<${escalar}>;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) gid: vec3u) {
  let i = gid.x;
  if (i >= arrayLength(&pesos)) { return; }
  pesos[i] = pesos[i] * ${escalar}(0.5);
}`;
}

Fíjate en que el cambio no es solo de tipo: también cambia el tamaño del buffer que subes desde JavaScript, porque f16 ocupa dos bytes y f32 cuatro. Una feature nunca es un interruptor aislado; arrastra el formato de los datos con ella.

Hay un tercer plano, distinto de las features, que conviene no confundir: las características del lenguaje WGSL, que se consultan en navigator.gpu.wgslLanguageFeatures, otro objeto de tipo conjunto con has(). Son cosas que la implementación del compilador soporta o no, independientes del hardware y sin necesidad de pedirlas al crear el dispositivo. Si escribes WGSL generado o usas construcciones recientes del lenguaje, comprobar ahí antes de compilar te ahorra un error de compilación en el navegador equivocado.

console.log('lenguaje WGSL:', [...navigator.gpu.wgslLanguageFeatures]);