Hacia una era sin necesidad de APIs gráficas

• En la última década, las APIs gráficas de bajo nivel como DirectX 12, Vulkan y Metal impulsaron el rendimiento de la GPU, pero su complejidad y costo de mantenimiento aumentaron drásticamente
• Las GPU modernas ya soportan jerarquías de caché completas, punteros de 64 bits y recursos bindless, por lo que los modelos tradicionales de objetos de estado y bindings se han vuelto innecesarios
• El diseño propuesto simplifica de forma radical el pipeline de renderizado usando acceso a memoria basado en punteros de C/C++ y un único puntero raíz de 64 bits
• Elimina la explosión de PSO, las barreras de recursos y las APIs complejas de binding, y propone una estructura que conecta directamente la memoria de la GPU con el lenguaje de shaders
• Este enfoque plantea una API de nueva generación optimizada para arquitecturas GPU modernas, y apunta a la dirección que deberían tomar DirectX 13 o Vulkan 2.0

---

Cambios en las APIs gráficas de bajo nivel

• En 2013, la arquitectura AMD GCN de Xbox One y PS4 se convirtió en el estándar para el desarrollo de juegos AAA, y aparecieron APIs de bajo nivel como Mantle, DirectX 12, Vulkan y Metal
  • Es decir, fueron diseñadas tomando como referencia las arquitecturas GPU de alrededor de 2013
• Las antiguas DirectX 11/OpenGL tenían limitaciones por el renderizado en un solo hilo y la alta sobrecarga del driver
• Estas APIs redujeron el costo de los draw calls mediante objetos de pipeline precompilados (PSO), pero como no encajaban con la estructura de los engines, aumentaron la complejidad
• Como resultado, dentro del engine surgió otra “capa de driver de bajo nivel”, y el rol del programador gráfico se volvió más especializado

Contexto histórico: por qué se volvió tan complejo

• Las primeras GPU tenían memoria separada y una arquitectura centrada en pipelines de función fija
• OpenGL y DirectX adoptaron diseños basados en estado y objetos para abstraer la diversidad del hardware
• Incluso hasta DirectX 11, las texturas y buffers se manejaban como descriptores opacos
• Ese diseño luego se arrastró por inercia a las APIs posteriores

Desajuste entre las GPU modernas y las APIs

• Las GPU actuales soportan jerarquías de caché coherentes, PCIe ReBAR, punteros de 64 bits y texturas bindless
• Ya es posible una estructura en la que la CPU escribe directamente en la memoria GPU y la GPU la lee de inmediato
• En este entorno, estructuras como PSO, descriptor sets y tablas de binding resultan innecesarias
• El problema del crecimiento explosivo del caché de PSO requiere cientos de GB de caché, lo que provoca demoras de carga y stuttering
• Una nueva API puede eliminar estas estructuras obsoletas y pasar a un acceso simple basado en punteros

Simplificación de la gestión de memoria GPU

• En Vulkan y DirectX 12, el enfoque actual exige consultar la compatibilidad del heap después de crear recursos, lo que es ineficiente
• El método propuesto asigna memoria GPU directamente con una API simple del tipo gpuMalloc/gpuFree
  • La CPU puede mapear directamente la memoria GPU para inicializarla
  • Los datos de gran tamaño se transfieren con comandos de copia para realizar compresión DCC y procesamiento swizzle
• Se distinguen la dirección mapeada por la CPU y la dirección GPU, y se convierten con gpuHostToDevicePointer

Modernización de los datos y del lenguaje de shaders

• Usa un lenguaje de shaders basado en punteros de C/C++, como CUDA, Metal u OpenCL
• Permite acceso eficiente a memoria con wide loads a nivel de struct (128 bits o más)
• ByteAddressBuffer y los texel buffers de DirectX ya no son la mejor opción
• Como GLSL y HLSL no soportan punteros, no existe un ecosistema de bibliotecas de shaders reutilizables; en cambio, CUDA sí evolucionó con bibliotecas ricas

Argumentos raíz y estructuras de datos

• El kernel GPU recibe un único puntero de 64 bits como entrada y lo castea a una estructura
• La CPU y la GPU comparten los mismos headers de C/C++, garantizando coherencia en las estructuras de datos
• Las palabras clave const/restrict guían la optimización del compilador y eliminan la separación innecesaria entre UBO y SSBO
• Se aprovechan la precarga en registros escalares y la optimización dinámica de uniforms de las GPU modernas

Simplificación del binding de texturas

• Todas las texturas se gestionan como un arreglo (heap) de descriptores de 256 bits, editable directamente por CPU y GPU
• El acceso basado en índices de 32 bits permite muestreo de texturas no uniforme (non-uniform)
• Es más simple que el descriptor heap de DirectX 12 SM 6.6 y similar a Vulkan VK_EXT_descriptor_buffer
• La creación, subida y muestreo de texturas se unifican por completo sobre punteros de memoria GPU

Pipeline de shaders y constantes

• Crear un pipeline se reduce a cargar el IR del shader y llamar a gpuCreatePipeline
• No se necesitan root signatures, descriptor sets ni definiciones de binding
• Las constantes estáticas (basadas en struct) reemplazan las constantes de especialización del shader y mitigan el problema de la explosión combinatoria de PSO
• La estructura de constantes puede incluir punteros GPU, lo que permite hardcodear direcciones de tiempo de ejecución directamente

Simplificación de barreras y sincronización

• Las listas de barreras por recurso de las APIs actuales no encajan con la arquitectura de las GPU modernas
• El modelo propuesto usa solo flags tipo bitfield por cola/etapa
• Se simplifica a una forma gpuBarrier(before, after, hazard), sin necesidad de rastrear recursos
• Los comandos gpuSignalAfter / gpuWaitBefore implementan sincronización GPU→GPU similar a los timeline semaphores

Command buffers y renderizado

• Solo se usan command buffers de un solo uso (transient), eliminando el complejo modelo de reutilización de Vulkan
• gpuBeginRenderPass / gpuEndRenderPass configuran los render targets y realizan el clear
• No hay barreras automáticas entre render passes, lo que permite optimizar el renderizado paralelo y el depth pre-pass

Simplificación del pipeline de rasterización

• Los vertex/pixel shaders acceden a los datos mediante punteros, eliminando la API de bindings
• GpuDepthStencilState y GpuBlendState se separan del PSO para reducir la cantidad de combinaciones
• Las GPU móviles permiten blending programable con framebuffer fetch intrinsics
• El PSO solo incluye el estado mínimo necesario, como topología, formatos y cantidad de samples

Draw indirecto y renderizado impulsado por la GPU

• Todos los argumentos (data, arguments) se pasan como punteros GPU
• gpuDrawIndexedInstancedIndirectMulti habilita el soporte de multi-draw
• La propia GPU puede generar directamente los datos raíz y los argumentos de draw, logrando un renderizado completamente GPU-driven

Herramientas y compatibilidad

• La estructura basada en punteros puede rastrearse mediante información de símbolos, como en los depuradores de CUDA/Metal
• Está protegida por memoria virtual, por lo que no hay problemas de seguridad; los accesos inválidos generan page faults
• Como muestran MoltenVK y Proton, las APIs existentes DirectX/Vulkan/Metal pueden mantenerse mediante capas de traducción

Requisitos mínimos y conclusión

• Nvidia Turing (2018), AMD RDNA1 (2019), Intel Xe1 (2022) y Apple M1 (2020) ya soportan todas las funciones propuestas
• Las GPU actuales ya adoptaron arquitecturas de bindless, punteros de 64 bits y caché coherente
• Solo la API sigue atada a abstracciones del pasado
• Una nueva API sería más simple que DirectX 11, más rápida que Vulkan y más flexible que Metal
• La próxima generación de Vulkan 2.0 / DirectX 13 debería avanzar hacia este diseño completamente bindless e impulsar un ecosistema más amplio con lenguajes de shaders basados en punteros de C/C++ en lugar de HLSL/GLSL

[GN⁺]

Comentarios en Hacker News

• Este artículo muestra muy bien las partes innecesarias de Vulkan y DX12
  Hoy en día DX12 da la impresión de estar prácticamente abandonado, al punto de que ni siquiera soporta punteros a buffers, y Vulkan tampoco se ha ordenado en una versión 2.0, así que hay muchos drivers donde las extensiones no están bien implementadas
  Si existiera una API nueva como esta, se podría emular OpenGL mucho más rápido encima de ella, y cosas como SDL3 GPU podrían obtener mejoras de rendimiento de 3 a 4 veces

  • El estado actual de la documentación de DirectX es muy malo
    El libro de Frank Luna tampoco cubre todas las funciones recientes, así que hay que rebuscar entre el sitio Learn, los ejemplos de GitHub y la documentación de referencia
    Vulkan es igual de complejo y, aunque saliera una versión 2.0, sigue siendo dudoso cómo podría usarse realmente en plataformas clave como Android
  • Creo que todo esto quizá se debe al requisito de PCI Resizable BAR
    Salvo Intel Arc, la mayoría de las GPU funcionan incluso sin reBAR, pero parece que Microsoft o Intel tendrían que imponerlo desde UEFI para poder usar de forma estable funciones como bindless texture
    Sin embargo, eso pondría un piso mínimo al hardware compatible, y en placas base anteriores a 2020 el soporte es bastante irregular

• Falta la motivación central del artículo
  Según el índice del blog, la idea es que “en la última década la complejidad de las API gráficas y de los lenguajes de shaders ha aumentado drásticamente, y ahora hace falta simplificar la capa de abstracción para mejorar la eficiencia de desarrollo y el rendimiento, además de prepararse para futuras cargas de trabajo de GPU”

  • Esto se parece a por qué apareció NVMe
    Al principio los SSD reutilizaban interfaces IDE/SATA, pero para obtener un rendimiento real había que abandonar la premisa de los discos giratorios y crear un método de transferencia nuevo
    Parece una comparación para decir que ya es hora de que las API gráficas también abandonen esas restricciones heredadas

• Puede que esté sesgado porque llevo mucho tiempo siguiendo el trabajo de Sebastian Aaltonen, pero este artículo me pareció excelente
  Creo que la dirección futura es un regreso al renderizado por software
  La diferencia es que esta vez esos algoritmos y estructuras de datos recibirán aceleración por hardware
  En la industria de VFX esta tendencia ya está en marcha, y un ejemplo fue cuando OTOY portó OctaneRender sobre CUDA hace unos 5 años

  • Dentro de la GPU hay mucho hardware de función fija, y si se elimina, el rendimiento caerá bastante
    Los tipos de shader cumplen el papel de conectar esas etapas del pipeline, así que una softwareización completa no es realista
  • En realidad, parte de ese cambio ya está ocurriendo
    Por ejemplo, Nanite de Unreal Engine usa un rasterizador por software que corre en compute shader de la GPU al procesar triángulos pequeños

• Me impresionó el nivel de detalle del artículo
  Solo entendí una parte, pero parece que será una futura obra de referencia para el diseño de API gráficas
  Para la mayoría de los gamers, Vulkan/DX12 no trajeron grandes beneficios, y muchos juegos sufrieron por problemas de PSO
  Aunque Vulkan está mejorando, WebGPU heredó tal cual las limitaciones del diseño inicial de Vulkan
  Con el hardware evolucionando tan rápido, quizá fue un error irse por una API tan de bajo nivel
  Tal vez un enfoque centrado en cómputo general como CUDA sea un mejor camino

• Me hace pensar que extraño Mantle
  Tenía desventajas, pero daba la sensación de manejar el hardware directamente, y la época de desarrollo para Xbox 360 fue la más divertida para mí

  • La API gráfica de Switch también es excelente en ese sentido
    La diseñaron Nvidia y Nintendo, y me parece la API más intuitiva entre las consolas

• Después de leer esto, siento que estoy presenciando un momento histórico

• Esto me hizo pensar en Google Toucan, que parece ser un proyecto relacionado

• Este artículo me trajo muchos recuerdos
  Entre los factores adicionales que consideran los diseñadores de API están

  • Virtualización de GPU — una función que permite que varias aplicaciones compartan recursos de GPU (por ejemplo, la D3D residency API)
  • Comportamiento indefinido (Undefined Behavior) — si una aplicación depende de eso sin querer, migrarla a una API nueva se vuelve difícil

• Me pregunto por qué Microsoft no saca una nueva versión de DirectX
  DirectX Ultimate y 12.2 en realidad son prácticamente lo mismo que DX12
  ¿Será que, por la influencia de middleware como Unreal Engine, la importancia de su propia API ha disminuido, o quizá EPIC debería proponer una API nueva?

  • Este tipo de discusión suele estar activa sobre todo en la comunidad FOSS
    Los desarrolladores de juegos reales crean una RHI (Rendering Hardware Interface) y se concentran en hacer juegos
    Ray tracing y mesh shaders fueron las innovaciones más grandes, pero todavía se usan poco, así que parece que no se avanza más allá de eso
  • Hasta cierto punto, ambas cosas son ciertas
    Con la centralización de motores como Unreal y Unity, bajó el interés por innovar en APIs, y el progreso sigue solo del lado de la GPU
    La API del CPU sigue siendo básicamente un simple mapeo de buffers
    Como cuando aparecieron los tessellation shaders en el pasado, probablemente hará falta otro cambio nuevo de hardware para que haya avances

• Me pregunto si Valve podría llegar a crear su propia API gráfica para SteamOS

  • En realidad, Valve también tiene bastante responsabilidad en la complejidad de Vulkan
    Escuché que Valve fue uno de los actores principales en las primeras etapas del desarrollo de Vulkan