Vulkan (I)

Vulkan, más conocido antes como GLNext es la contrapartida de Direct3D 12 por un lado y sucesor de OpenGL por otro, su particularidad es que no parte de versiones anteriores de OpenGL sino que su desarrollo deriva de la API Mantle creada por AMD y EA DICE. Dicho de otra manera, Vulkan es “Mantle” modificado para funcionar con todo tipo de hardware. Mantle es una API diseñada alrededor de la arquitectura GCN 1.1 de AMD. ¿Como trasladarla a otras arquitecturas? Existen dos posibilidades:

  • A través del famoso controlador intermedio, lo que convertiría la API en una API de alto nivel y por tanto rompería la magía de lo que era Mantle.
  • Utilizando otro método que permita a compatibilidad de varias arquitecturas.

La solución a la que han llegado es la creación de un lenguaje bytecode al que han llamado SPIR-V. La definición de lo que es bytecode es la siguiente:

El bytecode es un código intermedio más abstracto que el código máquina. Habitualmente es tratado como un archivo binario que contiene un programa ejecutable similar a un módulo objeto, que es un archivo binario producido por el compilador cuyo contenido es el código objeto o código máquina .

El bytecode recibe su nombre porque usualmente cada código de operación tiene una longitud de un byte, si bien la longitud del código de las instrucciones varía. Cada instrucción tiene un código de operación entre 0 y 255 seguido de parámetros tales como los registros o las direcciones de memoria. Esta sería la descripción de un caso típico, si bien la especificación del bytecode depende ampliamente del lenguaje..

Los programas en bytecode SUELEN ser interpretados por un intérprete de bytecode (en general llamado máquina virtual, dado que es análogo a un ordenador).

Cuando se realiza un juego utilizando la API Vulkan lo que se genera no es un binario para un hardware concreto sino que lo que hace es generar el bytecode que se puede utilizar en múltiples arquitecturas.

Ahora bien, el hecho de que exista un lenguaje intermedio no significa que haya un controlador. ¿Cual es la tarea tradicional de un controlador? Pues gestionar los accesos al hardware para la aplicación, aquí la gestión es realizada directamente por la propia aplicación, pensad que lo único que hace el interprete es traducir a tiempo real, no gestiona absolutamente nada y si habéis pensado en que hablamos de algo como Java dejad que os saque del error. En Java la máquina virtual realiza ciertas gestiones, en este caso las gestiones son hechas desde la propia aplicación, o sea desde el juego y por tanto estamos hablando del paso de OpenGL que es una API de alto nivel a una API de más bajo nivel.

Vulkan3

La enorme ventaja de esto es que convierte el código de los motores gráficos generados con Vulkan en completamente agnósticos de plataforma. Esto significa que entramos en un paradigma donde los desarrolladores se podrán olvidar por completo del hardware a la hora de entender un sistema y por tanto evita que los fabricantes de un hardware en concreto acaben utilizando elementos exóticos para dificultar la portabilidad de los juegos, ya sean piezas de hardware únicas como APIs únicas.

Ahora mirad las compañías que están trabajando en el proyecto:

Vulkan

No solo tenemos los grandes fabricantes de hardware gráfico tanto a nivel de ordenador como de dispositivos derivados de los smartphones. También tenemos creadores de motores gráficos como Epic Games (Unreal Engine), Unity y Valve (Source 2). En el último caso y en medio de la presentación de Vulkan anunciaron que Source 2 esta siendo realizado utilizando Vulkan, lo que permitirá que los juegos que se realicen bajo ese motor vayan a funcionar en “cualquier” plataforma.

¿Otras compañías a destacar? Tanto Apple como Google, ¿es posible que en smartphones en un futuro los juegos se vuelvan completamente agnósticos de plataforma y se llegue a un punto donde no se tendrá que pensar en una plataforma en concreto? Hay que tener en cuenta que tanto Apple como Google y en especial Apple tienen el monopolio de la lógistica de distribución y cobran de los peajes que es por donde ganan el dinero. En el caso de las consolas tenemos a Sony, siendo el único fabricante que se encuentra dentro del panel, Microsoft no esta por motivos obvios y lo más sangrante es la no presencia de Nintendo, pero lo de Nintendo es normal si tenemos en cuenta que el hardware mínimo que pide la API es OpenGL 4.1 y la API más avanzada de Nintendo esta al nivel OpenGL 3.3.

¿Ventajas en cuanto al rendimiento? Hay que tener en cuenta que la ventaja más visible que tienen Mantle, las APIs de bajo nivel para consola y el futuro Direct3D 12 es el hecho de permitir que las listas de comandos no solo sean gestionadas por un solo procesador sino por varios:

Vulkan2

Hay que tener en cuenta que el mayor cuello de botella existente en PC se encuentra durante la etapa donde se generan las listas de comandos a la GPU y son enviadas a esta. Hace unos meses para explicar este problema que compartían tanto Direct3D 11 como OpenGL hice una entrada donde hice un simil con un cine, os recomiendo leerlo para que veías porque esto es tan importante. Aunque no puedo hablar de más desde el momento en que por motivos obvios no estuve en la presentación.

Ahora bien, a la que beneficia más esto es a Valve y sus Steam Machines. Sí todos los juegos desarrollados bajo Source 2, Unity y Unreal Engine acaban por funcionar bajo Vulkan y con eso hacerlos agnósticos de plataforma entonces lo único que faltaría sería la firma de varios de los grandes editores para acabar de cerrar el círculo. En el panel vemos a Electronic Arts, no en vano ellos fueron los desarrolladores de Mantle en colaboración de AMD y Vulkan deriva de Mantle, pero sobretodo porque EA parece interesada en un paradigma donde ningún fabricante tenga ventaja sobre los otros, donde el desarrollo de un juego derive en que se puede jugar en cualquier plataforma independientemente de la marca que tenga esta.

Espero ampliar información en una segunda entrada, pero como he dicho antes esto será de aquí a unas semanas.

Anuncios