Conecta con nosotros

Hola, ¿qué estás buscando?

Actualidad

¿Merece la pena seguir portando DirectX 11 a OpenGL?

¿Merece la pena seguir portando DirectX 11 a OpenGL?

¿Merece la pena seguir portando DirectX 11 a OpenGL?

¿Merece la pena continuar con OpenGL tras el lanzamiento de Vulkan?, ¿se debería portar DirectX 11 directamente a Vulkan en lugar de a OpenGL? Esas son dos preguntas que me estoy haciendo desde principios de año y creo que sobran motivos para plantearlas.

A día de hoy es bien conocido que OpenGL es una API obsoleta que no responde a las demandas de muchos desarrolladores de gráficos 3D actuales. La falta de multithreading (o por lo menos una implementación real), unido a otras carencias, provoca que no sea capaz de realizar fácilmente cosas que son sencillas con DirectX.

Esto ha tenido mucho que ver a la hora de recibir un buen puñado de cutreports. A pesar de que los juegos de Firaxis suelen salir bastante bien parados, otros títulos como Borderlands 2, Tomb Raider reboot y The Witcher 2 acusan en exceso la conversión a OpenGL, perdiendo mucho a nivel de rendimiento. Mientras que con una GTX 650 puedo jugar a Borderlands 2 con las configuraciones gráficas al máximo, 1080p y 60fps casi constantes sobre Windows, sobre GNU/Linux y con una GTX 1050 me veo obligado a jugar con los gráficos en calidad media si quiero tener una tasa de frames medianamente estable.

OpenGL frente a Vulkan, perdiendo por el terreno ganado

La ventaja teórica que tiene OpenGL frente a Vulkan es la compatibilidad con una mayor cantidad de GPU, algo que podría motivar el seguir usando esta API en lugar de su sucesora.

Sin embargo, debido a lo explicado en el apartado anterior, OpenGL necesita de mucho más trabajo para terminar haciendo lo mismo que DirectX, por lo que al final esto suele provocar una disminución del rendimiento y un aumento de los requisitos frente a las versiones de Windows. Esta situación convierte el desarrollo con la vieja API en un sinsentido, porque si necesitas de un ordenador más potente para ejecutar juegos con el mismo rendimiento, al final terminas usando una GPU que soporta Vulkan, por lo que el factor de mayor compatibilidad termina perdiéndose.

Vulkan, por su parte, sí implementa muchas de las características presentes en DirectX. Esto aumenta su atractivo para portar juegos a GNU/Linux no solo desde DirectX 12, API con la cual comparte mucho porque ambas están basadas en Mantle, sino desde el mismo DirectX 11, perdiendo en teoría menos rendimiento que con el obsoleto OpenGL.

Abandonar OpenGL en favor de Vulkan es algo que se tiene que plantear

Parece que el plantearse portar DirectX 11 directamente a Vulkan sin pasar por OpenGL no es ni mucho menos una idea descabellada. Feral Interactive, compañía especializada en portar juegos a GNU/Linux, tiene en fase beta una implementación de Vulkan para Mad Max. Lo bueno es que para realizar este trabajo no han cogido la conversión a OpenGL, algo que podría degenerar mucho al hacer un port de otro port, sino que han cogido como base la versión de Windows, que utiliza DirectX 11.

Tanto Phoronix como GamingOnLinux han realizado benchmarks comparando el rendimiento de las implementaciones de Vulkan y OpenGL de Mad Max sobre GPU NVIDIA. Por parte de ambos se puede concluir que cuanto mejor sea la gráfica, mayor es la ventaja de Vulkan sobre OpenGL.

Como es costumbre en Michael Larabel, tenemos a nuestra disposición una gran cantidad de gráficos derivados del uso de distintas configuraciones gráficas, tanto a nivel de calidad como de resolución. Con el fin de hacer un poco más justa la comparativa con GamingOnLinux, vamos a centrarnos solo en la configuración en muy alta (very high) sobre 1080p.

Advertencia, desplázate para continuar leyendo

En los gráficos se puede comprobar que Phoronix ha utilizado 4 modelos de gráficas NVIDIA: GTX 1050ti de 4GB de VRAM, GTX 1060 de 6GB de VRAM, GTX 1070 de 8GB de VRAM y la reciente GTX 1080ti de 11GB de VRAM. Sobre el resto de las características del ordenador empleado, tenemos una placa base MSI Z270-A PRO, una CPU Intel Core i7-7700K a 4,5GHz, 16GB de RAM, el driver de NVIDIA 378.13, Xorg 1.18 y Ubuntu 16.10 como sistema operativo con el kernel Linux 4.8.

Por su parte, en GamingOnLinux han utilizado una configuración diferente. Aquí no tenemos el modelo de la placa base utilizada ni la cantidad de RAM, sin embargo, tenemos datos como el uso de 1080p como resolución, una CPU Intel Core i7 5960x (de 3GHz según la documentación de Intel) y una GPU NVIDIA GTX 980ti. Aunque no se trate de un ordenador de última generación, su GPU se puede considerar de gama alta en los tiempos actuales. Sobre el driver, sabiendo que Antergos se nutre directamente de los repositorios de Arch Linux, con casi toda probabilidad se habrá empleado el mismo que en Ubuntu por parte de Phoronix, el 378.13. El resto de componentes de software tendrían que ser los provenientes de Arch Linux.

Como se puede apreciar si se compara los resultados obtenidos con la configuración gráfica en muy alta, vemos que Phoronix se impone gracias a su hardware más reciente (y posiblemente también al uso de Ubuntu), aunque por parte de ambos se observa una clara mejora en el rendimiento con Vulkan. Por otro lado, sería más justo comparar los resultados de la GTX 980ti con los de la GTX 1070.

Es importante recalcar que esta implementación de Vulkan por parte de Feral Interactive está todavía en fase beta y puede considerarse como un experimento, por lo que podría haber margen de mejora todavía.

Sin embargo, en AMD todo se desluce por completo

Las grandes expectativas despertadas con el uso del driver privativo de NVIDIA se desvanecen por completo cuando la comparativa se realiza con una GPU AMD utilizando los drivers libres.

Aquí solo disponemos de los resultados arrojados por Phoronix y, siendo sinceros, son muy decepcionantes, hasta el extremo de que en la mayoría de los contextos el rendimiento de OpenGL resulta superior al de Vulkan. Aquí se puede apreciar como a RADV, la implementación libre de Vulkan para gráficas AMD, le queda muchísimo por recorrer, y todo esto sin contar los impresionantes resultados arrojados por Doom sobre Windows (usando una implementación privativa).

Veremos qué puede conseguir Valve a través de la mejora de RADV, algo para lo cual ya ha movido ficha contratando a expertos en drivers de GPU Open Source. Por otro lado, estos decepcionantes resultados han vuelto a despertar las peticiones para que AMD libere la implementación privativa de Vulkan incorporada en AMDGPU-PRO.

Tras saberse esto, a los linuxgamers no nos queda otra que seguir apostando por NVIDIA, su driver privativo y sus problemas de intengración, ofreciéndonos un panorama no del todo idóneo según nuestras costumbres.

Poco a poco, Vulkan va sumando apoyos

Hay que tener en cuenta que a Vulkan todavía le queda mucho camino para poder reemplazar a OpenGL en todos los contextos. Sin embargo, la API de última generación está sumando apoyos poco a poco, habiéndose añadido recientemente su soporte en Unity 5.6 (no nos referimos al ya difunto entorno de Ubuntu, sino al motor de videojuegos Unity3D).

Y no solo en GNU/Linux se justifica el salto a Vulkan, ya que ARM ha publicado un vídeo en el que se compara el consumo energético de esta API con OpenGL a través de Unity3D, mostrando una disminución muy notable gracias a la capacidad de trabajar a más bajo nivel de Vulkan. Esto abre la puerta a la posibilidad de portar juegos más potentes a Android, además de ayudar a la autonomía cuando se realiza un uso intensivo de un dispositivo móvil para jugar.

Nouveau, ¿el gran sacrificado?

Intel ya tiene soporte para Vulkan, AMD lo tiene tanto en versión privativa (a través de AMDGPU-PRO) como libre (a través de RADV), mientras que NVIDIA solo ofrece soporte a través de su driver privativo.

Uno de los propósitos de Vulkan es reducir la dependencia del driver al ofrecer un uso más directo del hardware, esto significa que, de haber una buena implementación de la API para Nouveau, a NVIDIA se le podría desmoronar al menos parte de su negocio. Viendo esto, será difícil que la compañía colabore en su desarrollo, ya sea de forma directa o indirecta.

Tanto Qt como GTK ya tienen planes para soportar Vulkan, y posiblemente en unos años se convierta en la API principal de GNU/Linux gracias a su mayor rendimiento con menor consumo energético. Esto ayudaría en un aspecto en el que nuestro sistema favorito nunca ha sido brillante, la autonomía de los portátiles. La adopción de la API tanto por parte de GNOME como de KDE puede ser determinante para el futuro de dos entornos etiquetados como “pesados”.

Ante esta situación, si Nouveau no obtiene el debido soporte, posiblemente acabe descontinuado cuando Vulkan se consolide como la API estándar y se abandone el desarrollo con OpenGL.

[Actualización]

Pedimos disculpas por no haber comprobado mejor los datos, ya que al parecer los datos tan dispares entre OpenGL y Vulkan eran por culpa de una regresión hallada en el renderizador de OpenGL correspondiente a la implementación de la beta Vulkan incluida en Mad Max para GNU/Linux. Dicho de otra manera, había un fallo en el OpenGL incluido en la beta de Vulkan.

Después de corregir la regresión, las diferencias entre Vulkan y OpenGL se han acortado mucho, dejando la mejora en apenas un 15%, siendo de aproximadamente un 20% en el mejor de los casos. A pesar de todo, hay que tener en cuenta que todavía se trata de una beta, por lo que puede haber margen de mejora.

66 Comentarios
Advertencia
Advertencia

Te recomendamos

Actualidad

Red Hat ha anunciado a través de las listas de correo del kernel Linux la creación de Nova, un nuevo driver dirigido a las...

Actualidad

Collabora ha anunciado que NVK, el driver de Vulkan de código abierto para Nouveau y que forma parte de Mesa, ya está listo para...

Actualidad

Slimbook no para: aquí llegan los nuevos Slimbook Excalibur y KDE Slimbook, dos enfoques para un mismo hardware cuyo denominador común reside en el tradicional...

Actualidad

NVIDIA ejerce un fuerte dominio en el sector de la computación de propósito general sobre la unidad de procesamiento de gráficos (GPGPU) con CUDA,...