El coste de crear un pipeline y cómo no pagarlo en mitad del frame

Crear un render pipeline compila los shaders al lenguaje intermedio de la plataforma, y en muchos backends también al código máquina de la GPU concreta, con todo el estado gráfico como entrada de la compilación. Eso cuesta entre unos milisegundos y varias decenas por pipeline. Si ocurre en mitad del bucle de dibujado, produce el tirón más característico y más evitable de las aplicaciones gráficas en la web.

Qué pasa por dentro

createRenderPipeline hace cuatro cosas. Valida el descriptor entero contra el pipeline layout y contra los módulos. Traduce el WGSL al lenguaje intermedio del backend —SPIR-V en Vulkan, MSL en Metal, HLSL o DXIL en D3D12—. Especializa esa traducción con el estado gráfico: los formatos de los targets, el estado de mezcla, la topología, los override constants. Y en muchos backends invoca al compilador del driver para generar el código máquina definitivo.

Esa última etapa es la cara, y es la que hace que el coste no sea predecible: depende del driver, del tamaño del shader y de si el driver tiene una caché en disco de compilaciones anteriores. Un shader PBR completo puede tardar de 5 a 50 ms la primera vez y menos de 1 ms cuando la caché del driver ya lo tiene.

Lo importante es que el coste se paga por combinación de estado, no por shader. El mismo módulo compilado con dos formatos de target distintos son dos compilaciones. Con dos valores de override constants, dos compilaciones. Con blending y sin blending, dos compilaciones. La explosión combinatoria de variantes es real y es el motivo por el que los motores grandes tienen sistemas de gestión de variantes.

La versión asíncrona

createRenderPipelineAsync devuelve una promesa que resuelve cuando el pipeline está listo para usarse sin bloqueos adicionales:

const pipeline = await device.createRenderPipelineAsync({
  label: 'opaco-pbr',
  layout: pipelineLayout,
  vertex: { module, entryPoint: 'vs', buffers },
  fragment: { module, entryPoint: 'fs', targets },
});

La diferencia no es que sea más rápida: es que no bloquea el hilo de JavaScript mientras el driver compila. Con la versión síncrona, esos 30 ms son 30 ms de hilo principal congelado, con la animación parada y los eventos de entrada en cola. Con la asíncrona, el trabajo va a un hilo del navegador y tu bucle sigue corriendo.

La promesa se rechaza con un GPUPipelineError si la creación falla, en vez de producir un objeto inválido con un error de validación. Es un modo de error más manejable:

try {
  const p = await device.createRenderPipelineAsync(descriptor);
} catch (e) {
  // e es un GPUPipelineError con e.reason: 'validation' o 'internal'
  console.error('pipeline fallido:', e.reason, e.message);
}

Existe la equivalente createComputePipelineAsync con la misma semántica.

La regla práctica es clara: usa siempre la versión asíncrona salvo durante el arranque, donde el bloqueo no molesta y el código secuencial es más simple. Nunca uses la síncrona dentro del bucle de dibujado.

La caché por descriptor

Como el pipeline es una función determinista de su descriptor, una caché por contenido elimina las creaciones duplicadas. La clave se construye serializando los campos relevantes:

function crearCacheDePipelines(device) {
  const cache = new Map();
  const idsLayout = new WeakMap();
  let siguienteId = 0;

  // Los layouts se identifican por objeto, no por contenido:
  // dos layouts estructuralmente iguales NO son intercambiables.
  function idDeLayout(layout) {
    if (layout === 'auto') return 'auto';
    let id = idsLayout.get(layout);
    if (id === undefined) { id = `pl${siguienteId++}`; idsLayout.set(layout, id); }
    return id;
  }

  function clave(d) {
    return JSON.stringify({
      layout: idDeLayout(d.layout),
      vs: [d.vertex.module.label, d.vertex.entryPoint, d.vertex.constants,
           d.vertex.buffers],
      fs: d.fragment && [d.fragment.module.label, d.fragment.entryPoint,
                         d.fragment.constants, d.fragment.targets],
      primitive: d.primitive, depthStencil: d.depthStencil,
      multisample: d.multisample,
    });
  }

  return async function obtener(descriptor) {
    const k = clave(descriptor);
    let p = cache.get(k);
    if (!p) {
      p = device.createRenderPipelineAsync(descriptor);   // guardamos la promesa
      cache.set(k, p);
    }
    return p;
  };
}

Dos detalles hacen que esta caché funcione y no la mayoría de las que se escriben a mano.

El primero es guardar la promesa, no el pipeline resuelto. Si dos partes del código piden el mismo pipeline antes de que la primera termine, ambas esperan la misma compilación en vez de lanzar dos.

El segundo es la identificación de layouts por objeto. Dos GPUPipelineLayout con la misma estructura producen pipelines cuyos bind groups no son intercambiables, como vimos en la lección de compatibilidad. Una caché que los tratara como iguales devolvería el pipeline equivocado y produciría errores de validación imposibles de rastrear.

Los módulos se identifican por su label, lo que obliga a etiquetarlos de forma única. La alternativa —usar el código fuente como clave— funciona pero produce claves enormes; un WeakMap de módulos a identificadores, como el de los layouts, es la versión limpia.

El precalentamiento

Aunque los pipelines se creen en la carga, algunas implementaciones difieren trabajo hasta el primer draw. La técnica que lo elimina es dibujar una vez cada pipeline contra un target diminuto antes de mostrar nada:

async function precalentar(device, pipelines, formatos) {
  const dummy = device.createTexture({
    size: [1, 1], format: formatos.color,
    usage: GPUTextureUsage.RENDER_ATTACHMENT,
  });
  const dummyDepth = device.createTexture({
    size: [1, 1], format: formatos.profundidad,
    usage: GPUTextureUsage.RENDER_ATTACHMENT,
  });

  const encoder = device.createCommandEncoder({ label: 'precalentado' });
  const pass = encoder.beginRenderPass({
    colorAttachments: [{ view: dummy.createView(),
      loadOp: 'clear', storeOp: 'discard', clearValue: [0, 0, 0, 0] }],
    depthStencilAttachment: { view: dummyDepth.createView(),
      depthLoadOp: 'clear', depthStoreOp: 'discard', depthClearValue: 1 },
  });

  for (const { pipeline, grupos } of pipelines) {
    pass.setPipeline(pipeline);
    grupos.forEach((g, i) => pass.setBindGroup(i, g));
    pass.draw(3);          // un triángulo que no cubre nada útil
  }
  pass.end();
  device.queue.submit([encoder.finish()]);
  await device.queue.onSubmittedWorkDone();

  dummy.destroy();
  dummyDepth.destroy();
}

El target de 1×1 hace que el coste de rasterizado sea despreciable, y storeOp: 'discard' evita incluso escribirlo. Lo único que importa es que cada pipeline pase por un draw real.

onSubmittedWorkDone() espera a que la GPU termine, de modo que puedas mostrar la pantalla de carga hasta que todo esté listo de verdad.