Planteamiento y contexto
Esta pregunta de frontend combina una plataforma de navegador con ingeniería de lanzamientos (release engineering). La aplicación ya cuenta con rutas WebGL o CPU y busca un renderizado más rápido en WebGPU mientras llega a dispositivos que solo exponen un subconjunto restringido de la API. El núcleo es la negociación de capacidades y límites; obtener un adaptador no significa que todos los shaders, formatos o metas de rendimiento estén disponibles.
La especificación de GPUWeb describe el modo de compatibilidad como un subconjunto restringido de WebGPU destinado a mapearse con APIs gráficas más antiguas. Una implementación aún puede rechazar un adaptador, exponer menos funciones o límites, o perder un dispositivo en tiempo de ejecución. La disponibilidad, la corrección y el rendimiento deben medirse por separado.
Qué evalúa el entrevistador
- Construir una matriz de capacidades antes de elegir un adaptador, función o límite.
- Definir rutas de core, compatibilidad, WebGL, CPU y resultados estáticos como un fallback de producto ordenado en lugar de un único booleano.
- Saber que
GPUDevice.lostes una señal de terminación asíncrona y que la recuperación reconstruye los recursos y el estado de renderizado. - Diseñar despliegues en dispositivos reales, controles de calidad (quality gates), telemetría que respete la privacidad y reversiones rápidas.
- Separar “renderiza correctamente”, “cumple con la latencia” y “usa un consumo de energía aceptable”.
Preguntas clarificadoras
- ¿La carga de trabajo es renderizado, cómputo general o inferencia en el navegador? Cada una necesita diferentes capacidades de almacenamiento, texturas y precisión.
- ¿Qué experiencia deben conservar los dispositivos de gama baja? Esto define la ruta mínima de WebGL, CPU o resultado estático.
- ¿Puede la primera carga ejecutar un sondeo breve de capacidades? Sin este, los perfiles históricos de dispositivos pueden estar desactualizados o ser erróneos.
- ¿Se pueden reinicializar el canvas y los recursos tras la pérdida del dispositivo? Si no es así, el estado de la aplicación necesita un límite de interfaz de usuario recuperable.
- ¿El despliegue está segmentado por navegador, GPU, controlador (driver), región o usuario? La segmentación determina cómo se detecta una regresión específica de un controlador.
Respuesta de 30 segundos
“Detectaría WebGPU, el adaptador, las funciones y los límites, y luego definiría core, compatibilidad, WebGL, CPU o salida estática como una escala explícita de capacidades. Cada escalón crea únicamente los shaders, pipelines y recursos que admite, y cuenta con una prueba de corrección y un presupuesto de rendimiento. Escucho device.lost y utilizo un flujo de recuperación de ejecución única (single-flight) para reconstruir el dispositivo, los recursos y el estado del canvas; ante un fallo, se degrada y se registra un motivo. El despliegue se segmenta por navegador, GPU, controlador y versión de la aplicación. Monitoreo la inicialización, la pérdida del dispositivo, los errores de renderizado, el tiempo de fotograma p95 y la finalización de tareas, con un interruptor remoto de apagado que nunca elimina la ruta antigua.”
Solución paso a paso
Paso 1: Convertir la detección de capacidades en un contrato
Confirma un contexto seguro y navigator.gpu, luego solicita un adaptador. Lee sus funciones y límites compatibles; comprobar que el objeto de la API existe no es suficiente. Clasifica el resultado como core, compatibilidad, WebGL o CPU, y usa dimensiones gruesas de navegador, sistema operativo, proveedor de GPU, controlador y versión de la aplicación para la telemetría.
El modo de compatibilidad amplía el conjunto de dispositivos ejecutables pero tiene techos de funciones, límites y rendimiento más conservadores. Escribe los requisitos estrictos de la carga de trabajo como una lista: formatos de textura, diseño de enlaces (binding layout), tamaño de almacenamiento, límite de grupos de trabajo (workgroups) y precisión. Si falta una capacidad requerida, selecciona el siguiente escalón en lugar de esperar a que falle la creación del shader.
Paso 2: Construir recursos para el escalón de capacidad
Asigna a cada escalón sus propias variantes de shaders, descripciones de pipeline y presupuesto de recursos. Comienza con un triángulo minúsculo o una prueba de humo pequeña de inferencia, valida el envío de comandos y la salida, y solo entonces entra a la escena completa. No asumas que un grupo de enlaces o formato de textura creado para core sea aceptado en el modo de compatibilidad.
Ante un fallo de creación de recursos, registra un error estructurado y libera los objetos de ese escalón. Una imagen estática, un canvas WebGL o un resultado de CPU deben compartir el modelo de estado del producto para que el usuario pueda completar la tarea. Un fallback no debe implicar una tasa de fotogramas o precisión idénticas.
Paso 3: Manejar la pérdida de dispositivo y las condiciones de carrera en la recuperación
GPUDevice.lost se resuelve cuando finaliza el tiempo de vida del dispositivo. Entra en estado de recuperación: deja de enviar trabajo nuevo, cancela o marca los fotogramas antiguos, solicita un nuevo adaptador y dispositivo, reconstruye shaders, pipelines, búferes, texturas y grupos de enlaces para el escalón de capacidad, y luego reanuda el bucle de renderizado. Un token de generación o una promesa de ejecución única evita que dos intentos de recuperación sobrescriban el nuevo dispositivo.
Si el motivo de la pérdida sugiere presión de recursos o un problema del controlador, limita los reintentos y su intervalo. Los fallos repetidos cambian a WebGL o CPU e indican a la interfaz de usuario que la funcionalidad está degradada. La pregunta clásica de pérdida de dispositivo se centra en la mecánica de recuperación; esta se centra en matrices de capacidad de compatibilidad y control de versiones, así que mantén los alcances separados.
Paso 4: Diseñar despliegue escalonado y reversión
Comienza con una matriz de dispositivos interna y luego amplíala por versión de navegador, proveedor de GPU, controlador, sistema operativo y región. El flag debe poder deshabilitarse de forma remota, pero la entrega de la configuración no puede ser un punto único de falla para la corrección; el cliente mantiene un valor predeterminado seguro.
Rastrea fallos en la solicitud del adaptador, fallos en la creación del dispositivo, tiempo hasta la primera interacción, tiempo de fotograma o latencia de inferencia p50/p95, errores de shaders y pipelines, tasa de pérdida de dispositivo, éxito de la recuperación, tasa de fallback y finalización de tareas. La segmentación de hardware expone regresiones en los controladores. Mantén la telemetría en etiquetas y versiones de dispositivos genéricas en lugar de una huella digital (fingerprint) completa.
Paso 5: Validar corrección, rendimiento y consumo de energía
Compara las salidas de WebGPU, compatibilidad, WebGL y CPU con tolerancias para píxeles, límites geométricos, colores de textura y resultados de inferencia. Fija la escena, la resolución y el tamaño de lote (batch size) para las pruebas de rendimiento y reporta p50/p95; el promedio de un dispositivo de gama alta no es una garantía. Prueba la tasa de envío de comandos, la memoria y un indicador indirecto (proxy) de la temperatura del dispositivo en escenarios en segundo plano y con batería baja.
Establece controles por escalón: la compatibilidad necesita la tasa mínima de fotogramas y el margen de error de salida del producto, no el presupuesto de core. Si el error, la energía o el tiempo de recuperación cruzan un umbral, deshabilita ese escalón, preserva la salida de WebGL/CPU y recopila detalles del controlador con una reproducción mínima.
Compensaciones de diseño y límites
#### Sondeo de API vs. perfil de dispositivo
Un sondeo en vivo es preciso pero cuesta tiempo en la primera carga; un perfil de dispositivo es rápido pero puede estar desactualizado o ser invasivo para la privacidad. Usa un sondeo corto para capacidades estrictas y perfiles solo para ordenamiento y despliegue, nunca para eludir límites reales.
#### Modo de compatibilidad vs. WebGL
El modo de compatibilidad preserva una mayor parte del modelo de recursos y comandos de WebGPU, lo que permite compartir arquitectura. WebGL puede tener una cobertura madura más amplia, pero su modelo de shaders, sincronización y rendimiento difiere. Elige según la capacidad requerida, el costo de migración de corrección y la tarea del usuario, no por la novedad de la API.
#### Recuperación automática vs. fallback inmediato
Una recuperación acotada maneja la presión transitoria de recursos; los reintentos infinitos convierten una falla del controlador en tirones (jank) y amplificación del consumo energético. Después de que falle la recuperación o que las pérdidas repetidas crucen un umbral, cambia de inmediato y emite un único evento de diagnóstico.
Respuesta modelo
“Dividiría el despliegue de WebGPU en una matriz de capacidades, construcción de recursos, una máquina de estados de recuperación y control escalonado. Verifico el contexto seguro, solicito un adaptador, leo las funciones y los límites, y ordeno core, compatibilidad, WebGL y CPU como una escala de capacidades; cada escalón crea únicamente los shaders y recursos admitidos. Tras device.lost, detengo el envío de comandos y uso un token de generación para que un único flujo de recuperación reconstruya el dispositivo y cada objeto de GPU, recurriendo al fallback en caso de fallo. El despliegue se segmenta por navegador, GPU, controlador y versión, con métricas de inicialización, tiempo de fotograma, errores, pérdida, recuperación y finalización de tareas, además de un interruptor remoto de apagado. El modo de compatibilidad amplía la cobertura, no las garantías de rendimiento, por lo que la corrección, la latencia y la energía tienen controles separados.”
Errores comunes
- Verificar únicamente
navigator.gpu→ La creación del adaptador o del dispositivo aún puede fallar, y las funciones o límites pueden ser insuficientes → Construye y verifica una matriz de capacidades. - Tratar el modo de compatibilidad como un core de gama baja → Los shaders, formatos y límites pueden diferir → Otorga a cada escalón sus propios requisitos y prueba de humo.
- Volver a llamar a la función de renderizado tras la pérdida → Los recursos pertenecen al dispositivo inactivo → Reconstruye cada recurso mediante un flujo de recuperación de ejecución única.
- Reintentar la creación del dispositivo indefinidamente → Una falla del controlador se convierte en tirones y mayor consumo de energía → Limita los intentos y los intervalos, luego aplica fallback.
- Observar únicamente la tasa promedio de fotogramas → Una pequeña cohorte de GPU o controladores puede fallar por completo → Segmenta el p95 y la finalización de tareas por navegador, GPU y controlador.
Preguntas de seguimiento y respuestas
¿Cómo decides si una carga de trabajo se ajusta a los límites de compatibilidad?
Escribe los requisitos estrictos para funciones, formatos de textura, almacenamiento, tamaño de grupos de trabajo y precisión, luego compáralos con los límites del adaptador. Entra al escalón solo cuando la lista se cumpla por completo; de lo contrario, elige WebGL, CPU o salida estática y registra la capacidad faltante.
¿Se puede recargar la página cuando un usuario está editando y se pierde el dispositivo?
No por defecto. Persiste el estado de edición en la capa de la aplicación, pausa el trabajo de la GPU e intenta una reconstrucción acotada. Si falla, cambia de renderizador mientras preservas el estado y explica la degradación visual. Recarga únicamente cuando la migración del estado no sea segura, proporcionando un punto de entrada para la recuperación.
Una cohorte de controladores tiene repentinamente una alta tasa de pérdidas. ¿Cómo realizas la reversión?
Confirma la anomalía por GPU, controlador, navegador y versión de la aplicación, luego deshabilita el despliegue de compatibilidad para esa combinación mientras dejas habilitadas las demás cohortes. Inspecciona la inicialización, los shaders, la presión de recursos y los motivos de pérdida; reproduce de forma mínima y reinicia desde la matriz interna después de solucionarlo.
¿Cómo demuestras que el fallback de WebGL preserva los resultados del negocio?
Crea un conjunto de referencia (golden set) entre backends para entradas idénticas, compara tolerancias de píxeles o salidas de inferencia e incluye casos vacíos, de límites y de alta carga. Establece controles separados para la finalización de tareas, la corrección de resultados y la latencia; la similitud visual no demuestra una equivalencia numérica o de interacción.