Degradar a WebGL2 sin engañarte

“Si no hay WebGPU, caemos a WebGL2” es la frase que más veces se dice y menos veces se cumple. No porque sea imposible, sino porque quien la dice suele imaginar una capa fina de traducción, y lo que hay debajo son dos modelos de máquina distintos cuya intersección es exactamente el conjunto de cosas por las que no habrías elegido WebGPU. La decisión honesta no es si degradar, sino qué degradar: la API, o la experiencia.

Qué se traduce y qué no

WebGL2 es, a día de hoy, la base más segura que existe en la web para gráficos acelerados: está en los cuatro motores desde 2021 y llega a dispositivos donde WebGPU no llegará nunca porque el hardware o el driver no dan para más. Esa es la razón por la que el enfoque correcto es la mejora progresiva y no la sustitución.

Ahora la parte incómoda. Esto es lo que se traduce y lo que no:

Las seis filas en negrita son el problema entero, y no es casualidad que sean exactamente las que motivaron WebGPU. WebGL2 nunca tuvo compute: hubo una especificación de WebGL 2.0 Compute que se abandonó precisamente porque el esfuerzo se redirigió a WebGPU. Lo más parecido que queda es el transform feedback, que permite capturar la salida de un vertex shader en un buffer y por tanto hacer una simulación de partículas por elemento. Sirve para eso y para poco más: no hay escritura en direcciones arbitrarias, no hay comunicación entre invocaciones, no hay atómicos y el orden de salida es el de entrada. Un sistema de partículas independientes se traduce; un solucionador de fluidos con búsqueda de vecinos, una reducción, un scan, un culling en GPU o cualquier cosa que necesite que dos hilos se hablen, no.

La conclusión operativa es dura y conviene tenerla clara antes de empezar: si tu motor usa compute para algo que no sea decorativo, no tienes una ruta de reserva a WebGL2; tienes un segundo motor.

Las tres estrategias

La primera es la abstracción propia. Defines una interfaz que cubre lo que tu motor necesita y la implementas dos veces. Es la que más control da y la que más cuesta, porque la interfaz acaba siendo el mínimo común denominador, es decir WebGL2 con nombres de WebGPU. Merece la pena en un caso concreto y solo en ese: cuando el grueso de tu render es rasterización clásica y lo que usas de WebGPU es la organización (pipelines inmutables, bind groups, validación previa) y no las capacidades nuevas. Ahí la ganancia de WebGPU es de coste de CPU y de mantenibilidad, y ese modelo sí se puede emular por encima de WebGL2.

export interface Backend {
  readonly tipo: 'webgpu' | 'webgl2';
  crearMalla(datos: DatosMalla): Malla;
  crearMaterial(desc: DescMaterial): Material;
  render(escena: Escena, camara: Camara): void;
  destruir(): void;
}

Lo que hace o rompe esta estrategia es dónde pones la costura. Si la interfaz habla de buffers, pipelines y bind groups, has escrito WebGPU otra vez y la implementación de WebGL2 será un infierno. Si habla de mallas, materiales y pasadas, las dos implementaciones son razonables. La regla: abstrae por encima del vocabulario de la API, nunca al nivel del vocabulario de la API.

La segunda es delegar en una librería. El WebGPURenderer de Three.js cae automáticamente a WebGL cuando no hay WebGPU, y TSL compila un mismo grafo de nodos a WGSL y a GLSL, así que un material escrito una vez funciona en las dos rutas. Es, con diferencia, la mejor relación entre esfuerzo y cobertura si tu proyecto encaja en un motor de escena. Tiene su letra pequeña: la ruta GLSL es la del backend WebGL2 de WebGPURenderer y no la del WebGLRenderer clásico, y los nodos de cómputo no tienen a dónde caer, así que lo que hagas con computeAsync sigue necesitando WebGPU.

La tercera es degradar la experiencia, no la API. Es la que más se desprecia y la que más veces es correcta. En lugar de reimplementar tu renderizador, defines dos productos: la versión completa en WebGPU y una versión sencilla que no intenta parecerse. Un visor de producto puede ser un modelo con iluminación básica en WebGL2 en vez de un path tracer progresivo. Una visualización de datos puede ser SVG o Canvas 2D con menos puntos. Una escena de fondo puede ser un vídeo o una imagen. La ventaja no es el ahorro: es que la ruta de reserva es tan sencilla que no se rompe, mientras que una segunda implementación completa se pudre en cuanto nadie la prueba durante tres meses.

El arranque que decide

La detección tiene tres pasos y todos pueden fallar. navigator.gpu puede no existir; requestAdapter() puede devolver null aunque navigator.gpu exista (pasa cuando el navegador ha puesto la GPU en su lista negra o cuando no hay ningún adaptador utilizable); y requestDevice() puede rechazar o devolver un dispositivo que ya está perdido.

type Eleccion =
  | { backend: 'webgpu'; device: GPUDevice; adapter: GPUAdapter }
  | { backend: 'webgl2'; gl: WebGL2RenderingContext }
  | { backend: 'ninguno'; motivo: string };

export async function elegirBackend(canvas: HTMLCanvasElement): Promise<Eleccion> {
  // Permite forzar la ruta de reserva para poder probarla.
  const forzado = new URLSearchParams(location.search).get('gfx');

  if (forzado !== 'webgl2' && 'gpu' in navigator) {
    try {
      const adapter = await navigator.gpu.requestAdapter();
      if (adapter) {
        const device = await adapter.requestDevice({ label: 'principal' });
        // Un dispositivo puede nacer perdido: comprobamos sin bloquear.
        let vivo = true;
        device.lost.then(() => { vivo = false; });
        await Promise.resolve();
        if (vivo) return { backend: 'webgpu', device, adapter };
      }
    } catch (e) {
      console.warn('WebGPU no utilizable, se degrada:', e);
    }
  }

  const gl = canvas.getContext('webgl2');
  if (gl) return { backend: 'webgl2', gl };

  return { backend: 'ninguno', motivo: 'ni WebGPU ni WebGL2' };
}

Tres detalles que importan más de lo que parecen. El parámetro gfx=webgl2 en la URL no es un lujo: es la única forma barata de ejecutar la ruta de reserva en tu propia máquina, y una ruta que no ejecutas no funciona. El try alrededor de todo el bloque cubre que requestDevice() rechace por un TypeError o un OperationError, que es exactamente lo que pasa si en algún punto del código pediste una feature sin filtrar. Y el catch no debe tragarse el error en silencio: si tu telemetría no distingue “no hay WebGPU en este dispositivo” de “hay WebGPU y mi código lo pidió mal”, vas a leer los mismos números durante meses sin entender nada.

El otro detalle, de rendimiento: la detección es asíncrona y el usuario está mirando una pantalla en blanco mientras ocurre. Pinta algo primero (el fondo, un esqueleto, la primera imagen) y arranca el backend después, porque requestAdapter puede tardar decenas de milisegundos, y en un dispositivo lento bastante más.

Cuándo no merece la pena

Escribir una ruta de reserva completa cuesta entre un tercio y la mitad de lo que costó el motor, y hay que mantenerla para siempre. Antes de empezar, responde a estas cuatro preguntas con números y no con intuiciones.

¿Qué fracción de tus usuarios reales no tiene WebGPU? No de los usuarios de internet: de los tuyos. Si tu producto es una herramienta interna para un equipo con portátiles recientes, la respuesta puede ser cero. Si es una web pública con tráfico móvil masivo, es una fracción grande. Mídelo antes: publica una sonda que solo compruebe navigator.gpu y requestAdapter() y registre el resultado, y toma la decisión con datos.

¿Qué pasa si un usuario sin WebGPU no ve tu escena? Si tu escena es la aplicación entera, necesitas reserva. Si es un adorno de la portada, necesitas una imagen.

¿Usas compute para algo estructural? Si la respuesta es sí, deja de llamarlo reserva y llámalo por su nombre: un segundo producto con otro alcance.

¿Puedes probar la reserva en cada cambio? Si no puedes ejecutarla en tu máquina y en integración continua con un interruptor, se va a romper. Una ruta de reserva rota es peor que no tenerla, porque falla delante del usuario en vez de fallar en el arranque con un mensaje claro.