Una breve descripción de la API de Vulkan

Entonces, ¿cuál es el problema con esta nueva API de Vulkan y por qué debería importarnos?

Aquí está la API de Vulkan en cien palabras o menos: es una API de baja sobrecarga y casi metálica para gráficos 3D y aplicaciones informáticas. Vulkan es básicamente una continuación de OpenGL. Originalmente se la denominó la "iniciativa OpenGL de próxima generación" e incluye algunas partes de la API Mantle de AMD. Se supone que Vulkan brinda numerosas ventajas sobre otras API de GPU, lo que permite un soporte multiplataforma superior, un mejor soporte para procesadores de subprocesos múltiples, una menor carga de CPU y una pizca de agnosticismo del sistema operativo. También debería facilitar el desarrollo de controladores y permitir la compilación previa de controladores, incluido el uso de sombreadores escritos en varios idiomas.

Son 93 palabras, por lo que si no está interesado, puede omitir las siguientes 3500. Si, por otro lado, desea obtener más información sobre la próxima API de gráficos que estará con nosotros durante los próximos años, comenzaré con lo básico.

Cómo surgió la API de Vulkan

Vulkan fue anunciado originalmente por el Grupo Khronos en marzo de 2015, con una fecha de lanzamiento tentativa fijada para fines de 2015. En caso de que no esté familiarizado con Khronos, es un consorcio industrial sin fines de lucro fundado hace quince años por algunos de los nombres más importantes en el industria gráfica, incluyendo ATI (ahora parte de AMD), Nvidia, Intel, Silicon Graphics, Discrete y Sun Microsystems. Incluso si no ha oído hablar de Khronos, probablemente haya oído hablar de algunos de sus estándares, como: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA y glTF.

A estas alturas, probablemente estés pensando "Ah, son esos tipos", así que puedo saltarme el resto de la introducción y concentrarme en la API en sí.

A diferencia de su predecesor o predecesores, Vulkan está diseñado desde cero para ejecutarse en diversas plataformas, desde móviles y tabletas hasta consolas de juegos y computadoras de escritorio de alta gama. El diseño subyacente de la API tiene capas, o deberíamos decir modular, por lo que permite la creación de una arquitectura común pero extensible para la validación, depuración y creación de perfiles de código, sin afectar el rendimiento. Krhonos afirma que el enfoque en capas brindará mucha más flexibilidad, catalizará una fuerte innovación en las herramientas de GPU de todos los proveedores y proporcionará un control de GPU más directo que exigen los motores de juegos sofisticados.

Ahora, entiendo que muchos tecnófilos tienen sus reservas sobre términos de marketing como "flexible", "extensible" y "modular", pero esta vez estamos tratando con el verdadero McCoy. De hecho, esa es la idea básica detrás de Vulkan: se concibe como una API para las masas, desde niños que juegan en teléfonos inteligentes hasta sus padres que diseñan edificios y juegos en estaciones de trabajo.

En teoría, Vulkan podría usarse en hardware de cómputo paralelo, para controlar decenas de miles de millones de núcleos de GPU, en pequeños dispositivos portátiles y drones de juguete, en impresoras 3D, automóviles, kits de realidad virtual y casi cualquier otra cosa con una GPU compatible en su interior.

Para obtener más detalles, le sugiero que eche un vistazo a la descripción general oficial de Vulkan en PDF.

ADN del manto AMD

Si el enfoque cercano al metal le suena inquietantemente familiar, es posible que haya estado siguiendo los anuncios de GPU de AMD durante los últimos dos años más o menos. AMD sorprendió a los observadores de la industria cuando anunció su API Mantle en 2013, y los sorprendió una vez más cuando decidió desconectar la API y anunció en marzo de 2015 que no lanzaría Mantle 1.0 como un SDK público. En pocas palabras, Mantle prometió ofrecer mejoras significativas en el rendimiento y la eficiencia en algunas situaciones, especialmente en el frente de la CPU, ya que reduciría la sobrecarga de procesamiento. Parecía una buena idea, ya que los jugadores podían armar PC personalizadas con procesadores algo más lentos e invertir más dinero en tarjetas gráficas de primer nivel. También sonaba muy conveniente para AMD, porque la compañía no ha tenido una CPU de gama alta competitiva en años, aunque todavía tiene buenos productos de GPU.

Mientras los llorosos fanáticos de AMD se reunían para llorar la muerte de su salvador, Mantle resucitó milagrosamente. La buena noticia llegó en forma de una publicación de blog, escrita por el vicepresidente de computación visual y perceptiva de AMD, Raja Koduri. Coincidentemente, de acuerdo con el tema religioso, en una ocasión Koduri dio un sermón en una montura, durante el evento de lanzamiento de AMD en Hawái en 2013, pero estoy divagando.

Bromas aparte, el equipo de Koduri hizo un buen trabajo. Si bien Mantle no se convirtió en un nuevo estándar de la industria, se convirtió en la base de Vulkan. La mayor diferencia es que Vulkan no estará restringido al hardware AMD GCN; funcionará en muchas más GPU de diferentes proveedores. Probablemente puedas ver a dónde voy con esto; es un poco mejor tener una sola API de gráficos de bajo costo que funcione en diferentes sistemas operativos y plataformas de hardware que tener API propietarias para diferentes arquitecturas de GPU, sistemas operativos, etc.

La API de Vulkan simplemente toma una buena parte del pastel de Mantle y lo comparte con todos, independientemente del sistema operativo, el hardware, la raza o la religión.

Ah, y hay una cosa más: Mantle finalmente obligó a Microsoft y Khronos a hacer algo con respecto a DirectX y OpenGL y su ineficiencia. Fue una patada suave y amistosa en la parte posterior, o "badonkadonk", como le gusta decir a un compañero de Toptaler.

¿Cómo se compara Vulkan con OpenGL?

Obviamente, necesito resumir las diferencias básicas entre Vulkan y OpenGL. A Khronos se le ocurrió una ilustración simple que mostraba cuánto exceso de controladores se podía eliminar con la nueva API.

Vulkan permite que las aplicaciones se acerquen más al metal, eliminando así la necesidad de mucha memoria y gestión de errores, así como una gran cantidad de fuente de lenguaje de sombreado. Los conductores serán más ligeros, más delgados y más malos. Vulkan solo se basará en el lenguaje intermedio SPIR-V, y dado que tiene una API unificada para los mercados de dispositivos móviles, computadoras de escritorio y consolas, también debería recibir una atención más tierna y amorosa por parte de los desarrolladores.

Pero espera, ¿no significa esto simplemente descargar más trabajo a los desarrolladores de juegos? Claro, podrán usar el hardware de manera más eficiente, pero ¿qué pasa con sus propias horas de trabajo? Aquí es donde entra en juego el enfoque del ecosistema en capas.

Los desarrolladores podrán elegir tres niveles o niveles diferentes del ecosistema Vulkan.

• Utilice Vulkan directamente para obtener la máxima flexibilidad y control.
• Utilice bibliotecas y capas de Vulkan para acelerar el desarrollo.
• Utilice Vulkan a través de motores de juegos listos para usar totalmente optimizados con la nueva API.

La primera opción claramente no será para todos, pero sospecho que sería un buen software de evaluación comparativa. Khronos espera que la segunda opción sea un "área rica en innovación" porque muchas utilidades y capas estarán en código abierto y facilitarán la transición desde OpenGL. Si un editor tiene algunos títulos de OpenGL que necesitan ajustarse y actualizarse, esto es lo que usarían.

La última opción es, quizás, la más tentadora porque el trabajo pesado lo han hecho pesos pesados ​​de la industria como Unity, Oxide, Blizzard, Epic, EA, Valve y otros.

Aquí hay una tabla rápida de OpenGL vs. Vulkan:

Para ser honesto, no creo que sea justo comparar los dos. Vulkan es un derivado de Mantle, mientras que OpenGL es un mastodonte con 20 años de experiencia. Se supone que Vulkan se deshace de muchas cosas heredadas; ese es todo el punto. Se supone que Vulkan simplificará las pruebas y la implementación, hará que los controladores sean más eficientes y mejore la portabilidad del programa de sombreado a través del lenguaje intermedio SPIR-V.

Esto nos lleva a la siguiente pregunta. ¿Qué significa realmente Vulkan para los desarrolladores?

Se espera que SPIR-V transforme el ecosistema lingüístico

Entonces, ¿dónde entra en juego SPIR-V y qué sucede con el viejo GLSL?

GSLS seguirá vivo por ahora y será el primer lenguaje de sombreado admitido por Vulkan. Un traductor de GLSL a SPIR-V hará el trabajo pesado y ¡listo!, tendrá SPIR-V listo para alimentar el hambriento tiempo de ejecución de Vulkan. Los desarrolladores de juegos podrán usar los back-end de SPIR-V y Vulkan, probablemente confiando en los front-end del compilador de código abierto. Además de GLSL, Vulkan puede admitir kernels C de OpenCL, mientras avanza el trabajo para agregar compatibilidad con C++. Los futuros lenguajes, marcos y herramientas específicos de dominio son otra opción. Khronos incluso menciona la posibilidad de desarrollar nuevos lenguajes experimentales.

Independientemente de lo que decidan hacer los desarrolladores, todos los caminos conducen a Vulkan, a través de SPIR-V, y luego a una multitud de dispositivos diferentes.

Se supone que SPIR-V mejora la portabilidad de tres maneras:

• herramientas compartidas
• Conjunto de herramientas único para un único ISV
• Sencillez

Dado que no será necesario que todas las plataformas de hardware presenten un traductor de idiomas de alto nivel, los desarrolladores tendrán que lidiar con menos de ellos.

Un ISV individual puede generar SPIR-V utilizando un solo conjunto de herramientas, eliminando así los problemas de portabilidad del lenguaje de alto nivel.

SPIR-V es más simple que un lenguaje de alto nivel típico, lo que facilita la implementación y el procesamiento.

El rendimiento se mejorará de varias maneras, dependiendo de cómo se implemente Vulkan:

• No más front-end del compilador, se puede realizar una gran cantidad de procesamiento sin conexión
• Los pases de optimización pueden establecerse más rápido, las optimizaciones se ejecutan fuera de línea
• Los sombreadores de múltiples fuentes se reducen al mismo flujo de instrucción de idioma intermedio

Khronos no especifica ningún número de rendimiento y señala que "el kilometraje definitivamente variará". Todo dependerá de cómo se use Vulkan. Si desea ver los detalles arenosos, asegúrese de consultar el informe técnico de SPIR-V.

Vulkan parece prometedor desde la perspectiva de un desarrollador

He esbozado una serie de características que deberían hacer que Vulkan y SPIR-V sean populares en la comunidad de desarrolladores, y Khronos también desea transmitir este punto. La perspectiva de usar las mismas herramientas y habilidades para desarrollar para múltiples plataformas parece intrigante, especialmente ahora que la brecha de rendimiento entre varias plataformas se está cerrando.

Por supuesto, el desarrollo de un juego AAA de gran presupuesto para PC seguirá siendo un proceso extremadamente complejo y lento, que implicará montones de dinero y recursos humanos, pero las plataformas móviles y las GPU integradas empleadas en los últimos procesadores Intel y AMD ya ofrecen una gran cantidad de Rendimiento de GPU para el jugador casual. Además, es más probable que los pequeños desarrolladores independientes o autónomos trabajen en juegos casuales multiplataforma que en títulos AAA producidos por las principales editoriales.

Khronos describe las siguientes ventajas posibles gracias a SPIR-V:

• Los desarrolladores pueden usar el mismo compilador front-end en varias plataformas para eliminar los problemas de portabilidad entre proveedores.
• El tiempo de ejecución del shader/kernel se reducirá ya que el controlador solo tiene que procesar SPIR-V
• Los desarrolladores no tienen que distribuir código fuente de shader/kernel, por lo que disfrutan de un nivel adicional de protección IP
• Los controladores son más simples y confiables ya que no es necesario incluir compiladores front-end
• Los desarrolladores tienen una mejor idea de la asignación de memoria y pueden modificar su enfoque de asignación de memoria en consecuencia.

Estoy seguro de que estará de acuerdo en que esto suena bien, pero aún queda un largo camino por recorrer.

Vulkan: funciona, pero es un trabajo en progreso

Como dije, Vulkan es todavía un trabajo en progreso, y deberíamos tener la especificación completa para fin de año. Sin embargo, por lo que hemos visto hasta ahora, la nueva API puede desbloquear mucho rendimiento incluso con el hardware de la generación actual.

La mejor ilustración de Vulkan que he visto hasta ahora proviene de Imagination Technologies, uno de los principales equipos de GPU móviles que existen. La GPU IP de Imagination Technologies se utiliza en todos los dispositivos iOS, junto con muchos otros diseños de sistema en chip basados ​​en ARM, e incluso en algunos chips Intel x86 de bajo voltaje.

La semana pasada, Imagination publicó una publicación de blog que detalla las ganancias de rendimiento que Vulkan hizo posible. Su elección de hardware fue algo inusual: un Google Nexus Player, basado en un procesador Intel de cuatro núcleos poco utilizado con GPU PowerVR G6430. El dispositivo se probó con el último controlador API de Vulkan para GPU PowerVR, mientras que la ejecución de referencia se realizó en OpenGL ES 3.0. La brecha de rendimiento fue nada menos que asombrosa.

La escena incluye un total de 400.000 objetos, con diferentes niveles de detalle, que van desde los 13.000 hasta los 300 vértices. El plano general muestra aproximadamente un millón de triángulos, algunos alfa en las plantas y unas diez texturas diferentes para los gnomos y las plantas. Cada tipo de objeto usa un sombreador diferente y los gnomos no están instanciados, cada llamada de dibujo podría ser un objeto completamente diferente, con diferentes materiales, pero el resultado final sería similar.

Aún así, hay una gran advertencia: este no es el tipo de aumento de rendimiento que puede esperar en la vida real. El equipo de Imagination Technologies usó un escenario exagerado para resaltar la superioridad de Vulkan, para llevarlo al límite, y en este escenario en particular, el límite está a favor de Vulkan frente a OpenGL ES. Además, tenga en cuenta que esta prueba está vinculada a la GPU , pero sigue siendo una buena ilustración de la utilización superior de la CPU de Vulkan.

¿Cómo reduce Vulkan la utilización de la CPU?

¿Recuerdas la tabla OpenGL vs. Vulkan que teníamos antes, o para ser más específicos, ese bit de representación en mosaico ? Probablemente no, así que aquí está, en pocas palabras: la imaginación usó Vulkan para dibujar por lotes llamadas en mosaicos y representar un mosaico a la vez. Dependiendo de dónde se encuentre el mosaico en el momento en que se represente el marco, puede aparecer o desaparecer, cambiar su nivel de detalle, etc. En OpenGL ES, todas las llamadas de sorteo son dinámicas, se envían con cada cuadro, de acuerdo con lo que está en el campo de visión. Las llamadas de sorteo que ya se han ejecutado no se pueden almacenar en caché.

Como resultado, OpenGL ES necesita muchas llamadas al modo kernel para cambiar el estado del controlador y validarlo. Vulkan no lo hace porque se basa en comandos generados previamente (búferes de comandos) para reducir la sobrecarga de la CPU y eliminar la necesidad de validar o compilar durante el ciclo de procesamiento. El equipo de Imagination describió la capacidad de reutilizar los búferes de comandos como "útil en algunas circunstancias" y posible de usar "en gran medida" en muchos juegos y aplicaciones.

El segundo punto de inflexión es la generación de búfer en paralelo , que permite a Vulkan aprovechar la potencia de todos los núcleos de la CPU. OpenGL ES se diseñó antes de la llegada de los chips móviles multinúcleo, pero en los últimos tres años, la industria ha pasado de dos, cuatro, ocho y diez núcleos de CPU, con los SoC de la serie A de Apple y Nvidia Tegra con sede en Denver. chips como las únicas excepciones notables. Hablé sobre las tendencias de SoC móviles en uno de mis artículos de blog anteriores, que cubría el próximo compilador Optimización de Android, por lo que puede consultarlo para obtener información adicional.

Intentemos una analogía: si Vulkan fuera un motor de combustión interna, estaría almacenando y reutilizando parte de su energía, de la misma manera que lo harían un turbocompresor y un intercooler (búferes de comando), y podría usar cuatro, seis, ocho o incluso diez cilindros sin pérdida de eficiencia (generación de búfer en paralelo). Comparar Vulkan con OpenGL ES suena un poco como comparar un nuevo motor turbo reducido con un viejo motor monocilíndrico en el Triumph Trophy de tu abuelo.

Bueno, al menos el abuelo era un verdadero rockero, no un mod.

El resultado final es un entorno mucho más eficiente, capaz de hacer un buen uso de todo el hardware disponible, a diferencia de OpenGL ES, que está vinculado a la CPU en la mayoría de los escenarios. Esto significa que Vulkan puede ofrecer niveles similares de rendimiento mientras mantiene la CPU en relojes más bajos, lo que reduce el consumo de energía y la aceleración.

Posibles desventajas de la API de Vulkan (alerta de spoiler: no hay tantas)

No estoy quisquilloso; Creo que también es importante enumerar los pros y los contras de la API de Vulkan. Afortunadamente, no hay tantas desventajas aparte de algunas menores y, potencialmente, una o dos grandes. Si cree que Vulkan es lo mejor desde el pan rebanado y está ansioso por probarlo en su próximo proyecto, es posible que desee considerar algunos de estos puntos:

• Complejidad de código agregada en ciertos escenarios
• Hora de comprar
• Nivel de apoyo de la industria
• Vulkan puede no ser tan relevante o efectivo en algunas plataformas (escritorios)
• Convencer a los desarrolladores de usar Vulkan en algunas plataformas
• Compatibilidad limitada con hardware heredado

Si un desarrollador quiere implementar algunas de las características interesantes descritas en esta publicación, implicará una buena cantidad de trabajo. Cada uno deberá implementarse en el código, pero la buena noticia es que los líderes de la industria facilitarán el proceso con nuevas actualizaciones de controladores.

El tiempo de comercialización es otra preocupación, al igual que la implementación de Vulkan en aplicaciones y juegos más antiguos. Vulkan sigue siendo una vista previa técnica; Las especificaciones e implementaciones iniciales se esperan para fines de 2015, por lo que, siendo realistas, probablemente no veremos muchas aplicaciones del mundo real antes de mediados de 2016.

El apoyo de la industria no debería ser un problema; Después de todo, este es un estándar de Khronos, pero puede llevar un tiempo. Esa es una de las razones por las que enfoqué esta publicación en el segmento móvil; El software y el hardware móviles evolucionan más rápidamente, y pueden pasar algunos trimestres más antes de que veamos que Vulkan tiene un impacto en las plataformas de escritorio. Así es como funciona la industria, hay muchas más cosas de las que preocuparse en el nicho de escritorio: soporte para aplicaciones profesionales, hordas de jugadores que empuñan horcas que se vuelven locos con cada marco roto, y así sucesivamente. Sin embargo, el hecho de que Vulkan se derive de Mantle de AMD es alentador.

Si bien Vulkan puede hacer maravillas en una configuración vinculada a la CPU, especialmente con SoC móviles de múltiples núcleos, estas ganancias de rendimiento estarán limitadas en las plataformas de escritorio. Las computadoras de escritorio manejan procesadores multinúcleo con un mayor nivel de eficiencia, y la mayoría de las aplicaciones gráficamente exigentes están vinculadas a GPU.

Hasta que todas las piezas del rompecabezas encajen en su lugar, algunos desarrolladores pueden ser reacios a dar el paso y jugar con Vulkan. Muchas personas simplemente no tienen tiempo para experimentar y aprenden nuevas habilidades solo cuando es absolutamente necesario. Quemar una gran cantidad de dinero y desperdiciar horas de trabajo para modificar los juegos móviles existentes para usar Vulkan en esta etapa temprana no será una opción para muchos desarrolladores y editores.

La compatibilidad con hardware antiguo podría ser otra fuente de preocupación. Vulkan necesitará hardware OpenGL ES 3.1 u OpenGL 4.1, acompañado de nuevos controladores. Por ejemplo, las GPU PowerVR serie 6 de Imagination Technologies pueden admitirlo, pero la serie 5 no. La serie Adreno 400 de Qualcomm es compatible con OpenGL ES 3.1, pero la serie 300 no. Las series Mali T600 y T700 de ARM son compatibles con OpenGL ES 3.1, pero falta compatibilidad con los diseños anteriores de la serie T400. Afortunadamente, para cuando Vulkan se vuelva relevante, la mayoría de los dispositivos con GPU no compatibles estarán fuera de escena. Estos incluyen el iPhone 5/5C, iPad de cuarta generación y dispositivos Samsung basados ​​en ciertos chips Exynos de la serie 5000. Es posible que los dispositivos basados ​​en Qualcomm no sean tan afortunados, ya que las GPU de la serie Adreno 300 se utilizan en diseños relativamente recientes y prolíficos, como Snapdragon 410, Snapdragon 600, Snapdragon 800 y 801. Sin embargo, sospecho que la mayoría de ellos ya no estarán. Vulkan se vuelve verdaderamente relevante.

Vive mucho y rinde

Todavía es demasiado pronto para decir si Vulkan cambiará o no las reglas del juego, pero creo que estarán de acuerdo en que tiene mucho potencial. Creo que será un gran problema, y ​​baso esa suposición en una década de experiencia cubriendo la industria de GPU. Sin embargo, tomará tiempo y sospecho que Vulkan hará sentir su presencia en los dispositivos móviles antes de que comience a cambiar el panorama de las computadoras de escritorio.

Aproximadamente al mismo tiempo, los controladores, los motores de juegos y los juegos optimizados para Vulkan, obtendremos nuevo hardware con el que jugar, y no me refiero solo a pequeños ajustes de hardware. El desarrollo de SoC móvil se ha estancado por varias razones que no mencionaré ahora, pero 2016 será un gran año para la industria, ya que los nodos FinFET de 14/16nm estarán disponibles para más fabricantes y se volverán económicamente viables para el hardware principal en lugar de fichas insignia.

Los desarrolladores tendrán un hardware mucho más potente y eficiente con el que jugar, y una nueva API de gráficos de bajo costo será la guinda del pastel. Espero sinceramente que los proveedores de hardware dejen de usar la resolución de pantalla como un truco de marketing, ya que las resoluciones altas sin sentido no hacen nada por la calidad visual, pero siguen desperdiciando energía. Desafortunadamente, dado que el consumidor promedio no entiende esto y quiere ver números más grandes en la caja, sospecho que esto no sucederá pronto. Tengo la intención de examinar este problema extraño en una de mis próximas publicaciones, así que si está molesto por eso, permanezca atento y siéntase libre de desahogarse en la sección de comentarios.