Vulkan ha llegado para quedarse

Ver el tema anterior Ver el tema siguiente Ir abajo

Vulkan ha llegado para quedarse

Mensaje por shiba87 el Miér Feb 17, 2016 2:46 am


Finalmente ha ocurrido. Tras algunos retrasos y mucha información por parte de desarrolladores y fabricantes que no podían contener sus ansias por echarle mano a la nueva API gráfica abierta y multiplataforma gestada en el seno del grupo Khronos, por fin hoy, es el día en el que las especificaciones de Vulkan  1.0 y su SDK, desarrollado por LunarG, han sido publicadas oficialmente.

Vulkan es el resultado de 18 meses de intenso trabajo por parte de todos los miembros del grupo Khronos, una API disponible para multitud de plataformas, un estándar abierto que sentará las bases de la industria de los gráficos renderizados por ordenador en el futuro próximo.

La cantidad de material abierto sobre Vulkan ha alcanzado cotas sin precedentes, incluyendo especificaciones, tests, SDKs, herramientas y una fuerte comunidad creada para la participación activa de todos para asegurar el desarrollo consistente de la API y la evolución de un ecosistema de desarrollo alrededor ésta.

Vulkan llega para eliminar la sobrecarga sobre los controladores gráficos que ejercían las APIs de antaño, aumentando el rendimiento y ofreciendo un control más directo de las capacidades de la GPU que tanto demandan los motores gráficos de nueva generación, de manera simple y predecible, permitiendo además desarrollar drivers que ofrezcan rendimiento, funcionalidad y portabilidad, sin mucho esfuerzo .
Otra enorme ventaja de Vulkan es su capacidad para hacer trabajar en paralelo a la GPU con tantas núcleos de CPU que haya disponibles, eliminado el cuello de botella que existía hasta ahora en este sentido.

Con Vulkan se ha pensado también en la transición y, si bien su objetivo a largo plazo es llevar a la industria a un nuevo modelo de desarrollo más moderno, no dejará, de momento, de apoyar a los existentes desarrollos basados en OpenGL y OpenGL ES, complementándolos y/o potenciándolos, haciendo que evolucionen en paralelo junto a la nueva API.

SPIR-V será el intermediario que consiga habilitar front-ends de lenguajes de alto nivel que emitan programas en una forma estandarizada para ser asimilada por Vulkan. Eliminando así la necesidad de desarrollar lenguajes de compilación de alto nivel, reduciendo significativamente la complejidad de los controladores gráficos y permitiendo la dicersidad de front-ends para distintos lenguajes.

https://www.khronos.org/assets/uploads/developers/library/overview/Vk_201602_Overview_Feb16.pdf

Por supuesto, al tratarse de un estándar desarrollado por los pesos pesados de la industria, y al contrario que otras APIs que han apostado por un enfoque similar, la retrocompatibilidad y la compatibilidad son una de las piedras angulares en las que se asienta Vulkan, permitiendo sacar partido de la API en casi cualquier dispositivo, ya sea un equipo de escritorio, consola, terminal móvil pequeños dispositivos...
y permitiendo a usuario con hardware no tan moderno poder disfrutar también de las bondades que ofrece el nuevo estándar. Cualquier hardware capaz de lidiar con OpenGL 4 u OpenGL 3.1 podrá lidiar con Vulkan sin ningún problema, lo que para los usuarios de escritorio significa, cualquier gráfica Nvidia soportada por los controladores oficiales actuales (GTX 400 en adelante), las gráficas integradas Intel (HD 4000 en adelante).
En el caso de AMD, la cosa no está tan clara y con el reciente cambio de estrategia llevado a cabo con sus nuevos controladores AMDGPU, el soporte para Vulkan se hará de rogar un poco más. EN principio sólo las GPUs Tonga y las que salgan a continuación tendrán soporte ofrecido por blobs privativos, para, en un futuro sin fecha concreta, tratar de ofrecer una alternativa abierta.

Aunque para no dejarnos con las manos vacías, desde AMD sí que nos traen una pequeña muestra de lo que nos espera con Vulkan



Los controladores gráficos ya están disponibles para los usuarios de gráficas Nvidia e Intel, así como para dispositivos con hardware Qualcomm e Imagination, tal como podemos ver en la página oficial del grupo
Al tiempo que contamos con ejemplos y demos para que probemos por nosotros mismos las capacidades de la nueva API.
Los controladores para GPU's AMD, como mencioné antes, no llegarán a GNU/LInux, al menos no de momento. Y para Windows tampoco tenemos controladores funcionales para Vulkan.

https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf

Ya sabíamos que el próximo GDC de Marzo será el escaparate perfecto para que todos los grandes desarrollos y futuros proyectos encandilen al público y el lanzamiento oficial de la API no podía hacerse realizado en mejor momento.
Además, El seminario virtual que dará el grupo Khronos este jueves 18 de Febrero será la guinda que corone el pastel

¡Salve VULKAN!¡Larga vida y prosperidad!

https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification
https://www.khronos.org/registry/vulkan/specs/1.0/apispec.html
https://www.khronos.org/vulkan/
 


EDITO

Intel se pronuncia acerca de los controladores Open Source, que tienen soporte para Vulkan desde el mismo día del lanzamiento.

http://blogs.intel.com/evangelists/2016/02/16/intel-open-source-graphics-drivers-now-support-vulkan/
https://01.org/linuxgraphics

Nvidia, por supuesto, ha hecho lo mismo y, además, ha liberado una API C++ para Vulkan de su propia cosecha y disponible para todo aquel que quiera utilizarla.
En este caso, el controlador está basado en una serie BETA Intermedia (355.00), que al parecer no cuenta con soporte para la última versión de Linux, 3.4 y la aún en desarrollo 3.5 y tampoco ofrece soporte para gráficas Fermi (series Gtx 400 y Gtx 500), que tal y como han dicho anteriormente, sí que serían soportada por la versión estable del controlador.

http://blogs.nvidia.com/blog/2016/02/16/vulkan-graphics-api/
https://github.com/nvpro-pipeline/vkcpp

AMD, por su parte nos ha dejado con las ganas, ya que AMDGPU no está listo y tampoco ofrecerá soporte para gráficas anteriores a 2015.
Pero es que además, según parece, tampoco han ofrecido drivers funcionales para ninguna otra plataforma y lo que hay disponible ahora mismo para M$ Windows es sólo un esbozo que no pasa de ninguna manera los test de conformidad de Vulkan.



EDITO2

Uno de los desarrolladores de Croteam, el primer estudio que ha lanzado uno de sus títulos con soporte para Vulkan, nos explica un poco por encima, cuáles son los 3 pasos clave que se necesitan para pasar de OpenGL a Vulkan en lo referente a su motor gráfico
 
El diseño para Vulkan consiste básicamente en tres pasos principales:

1) El port. hacer un port lo más rápidamente posible simplemente utilizando wrappers alrededor de Vulkan sobre el diseño actual del motor. Avitando inconvenientes y cuellos de botella. Éste es el paso en el que se encuentra el primer parche lanzado en la beta a bierta de Talos Principle.

2) Utilizar Vulkan para el renderizado multi-threaded. El motor gráfico Serious Engine ha sido diseñado realmente bien para el renderizado multihilo, pero por ahora sólo hay un wrapper en medio, las llamadas a la API gráfica (como Vulkan) no son multijilo. De momento.
Este es el próximo paso que realizaremos. Y probablemente lanzaremos un parche con ese cometido también para Talos. En su día se intentó llevar a cabo un proceso similar con Direct 3D 11 y resulto un horror con apenas o más bien ningún beneficio. Por esta razón hemos decidido mantener una actitud más conservadora en lo que se refiere al renderizado multihilo :/

3) Rediseñar el motor completo para Vulkan. Éste es el paso de mayor envergadura y se puede dividir en dos:

3a) Precachear todos los estados de renderizado (que a grandes rasgos significa materiales en el juego) al frente. Esto hará las llamadas de renderizado mucho más simples y rápidas. Así que, en vez de decidir en tiempo de renderizado, qué es necesario para un material para ser renderizado vía Vulkan, hacemos esto en tiempo de carga y entonces, cuando los materiales necesitan ser renderizados simplemente se lo dejamos a Vulkan, con sólo una o dos simples llamada.

3b) Precachear toda la geometría, materiales, texturas, todo lo que es necesario para renderizar un objeto. Esto básicamente crea un buffer de comandos de llamada listo para Vulkan, y no es necesarion ningún otro extra necesita ser seteado o creado en tiempo de renderizado.

La tercera parte es, obviamente, la más compleja del port, y tomará más tiempo modificar el diseño del motor para conseguirlo, paso a paso.

Espero haberme explicado bien [img=http://www.phoronix.com/forums/core/images/smilies/smile.png]
DEN


EDITO4

Qt se suma a Vulkan

Qt company se une al grupo khronos con la única intención de impulsar Vulkan.
Esperan que la APÎ gane rápidamente importancia y apoyos, así como los controladores gráficos mejoren notablemente, para así poder trabajar con la comunidad, el grupo Khronos y el resto de colaboradores, en un Qt totalmente compatible con Vulkan.

http://blog.qt.io/blog/2016/02/16/the-qt-company-joins-khronos-group-and-promotes-vulkan/?utm_content=28774110



EDITO5

AMD no ofrece controladores, pero sí que nos deja detalles e información muy interesante:

Tiling GPU drivers can use this information to determine when to bring data on and off chip, whether or not to flush data out to memory or discard the content of tile buffers and even to do things like size memory allocations used for binning and other internal operations. This is a feature that Mantle did not have, and is not part of Direct3D® 12 either.

http://gpuopen.com/vulkan-renderpasses/?sf20978991=1
avatar
shiba87
Squire
Squire

Mensajes : 306
Fecha de inscripción : 12/07/2012
Localización : /home/shiba

http://gnulinuxvagos.es

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.