EDICIóN GENERAL
177 meneos
1301 clics
AMD abre el código Vulkan de AMDGPU-PRO

AMD abre el código Vulkan de AMDGPU-PRO

Una de las mayores demandas de los usuarios que utilizan GPU AMD bajo Linux era la liberación del código de la implementación de Vulkan incluida en AMDGPU-PRO, la cual es privativa. Como respuesta a esta situación, se creó RADV, una implementación de la misma API pero Open Source y atado a Mesa.

| etiquetas: amd , vulkan , opensource , open
La buena noticia del día. :-)
¿esto puede correr en mi Lubuntu? {0x1f610}
#2. Apuesto a que puede correr en tu Lubuntu y en el mio. :-)
Han cumplido lo que prometieron, bien por ellos!
Mesa 17.3 starts to outperform AMDGPU-PRO

¿Tendrá algo que ver? :roll:

Parece que por fin hasta los más reticentes se van dando cuenta de que el open source es el camino.
#5 AMD dijo hace cerca de un año que las features nuevas van a llegar primero a los drivers cerrados, y que cuando sean lo bastante estables, se liberan. De hecho pusieron esta feature como ejemplo al decirlo.

Reticentes... No mucho. Llevan 10 años haciendo drivers open source.
#6 No. AMD (antes ATI) hacía drivers propietarios que eran malos. Y luego había el driver libre (Radeon), que estaba hecho con ingeniería inversa y con las especificaciones que ATI liberaba de vez en cuando, más lentos. Hace no relativamente mucho que AMD enterró los drivers propietarios y se volcó en hacer unos nuevos libres (AMDGPU) y unos nuevos propietarios que trabajan encima de los libres (AMDGPU-PRO).
#5 ¿Que tal van los drivers Mesa esos tan buenos y que marcan el camino con el Asynchronous Reprojection de SteamVR para el Vive?
#5 En AMD soportan a grandes empresas y corporaciones. De ahí unos drivers cerrados y que cumplen ciertos requisitos de estabilidad y funcionamiento. El rendimiento no es exactamente lo que buscan. Y aparte, apoyan los drivers libres (AMD trabaja activamente con la comunidad en su desarrollo), con lo cual no es un "oh, sorpesa, el rendimiento EN JUEGOS es mayor con el driver libre", es un trabajo bien hecho y que beneficia a ambos drivers (dado que los cerrados comparten actualmente…   » ver todo el comentario
Esto aproxima más Linux al escritorio... :troll:
Antes de emocionarnos, extraigo del propio artículo. Sí, ya sé que es del último párrafo y a veces da pereza llegar tan lejos:
«Se nos presenta un panorama algo incierto debido a las aparentes dificultades para mezclar ambos drivers, por lo que todo apunta a una posible duplicación de esfuerzos que veremos en qué y cómo impactará en la experiencia de usuario, aunque aparentemente nada impide que ambas implementaciones de Vulkan puedan convivir en una misma instalación del sistema.»
#9 No hay duplicación de esfuerzos en el sentido de que darán soporte y apoyarán a los drivers libres. Los privativos son para entornos corporativos (y estos pagan por dicho soporte, no es tanto "esfuerzo" o al menos se compensa).
Joer, al final este mundo en Linux "me consta" que ha avanzado, pero es un jaleo tan tremendo que es un traba importante para muchos...

- Mesa exactamente que es, drivers? Luego tienes drivers Intel, NVIDIA y AMD que tienen a la vez abiertos y privados? Tenemos 5 colecciones de drivers? Qué se instala entonces y cómo para tenerlo "bien"?
- Wine? Gallium Nine? Qué es DX9 nativo o algo así? Eso avanza, se usa?
- Entonces... DX10 o más? Y qué se hace, sólo lo compatible con…   » ver todo el comentario
#10 directX es de windows. OpenGL y Vulkan son interfaces abiertas multi-sistema.
#10 Mesa es el paraguas en el que están Gallium, Radeon y el resto de drivers libres de Intel, AMD, Nvidia, S3, ...
Wine es la reimplementación de las librerías de Windows en Linux (como MinGW pero en sentido contrario)
Gallium Nine es Gallium adaptado a DX9 (no es exactamente esto pero se acerca) para que no haya bajada de rendimiento al correr juegos DX9 en Wine.
PlayOnLinux, Wine y CrossOver son lo mismo básicamente (Wine con interfaz, Wine a pelo, Wine de pago).
Vulkan es el sucesor de OpenGL.

Así que no, no hay 5 colecciones de drivers. Hay drivers libres y luego los privados de AMD y NVidia.
#10 Te lo resumo breve por empresas:

Intel: Normalmente contribuye al proyecto Mesa, su driver es i915, soporta todas las gráficas integradas de Intel, en las últimas versiones han incluido blobs (de skylake para adelante). No hay driver privativo como tal.

NVIDIA: Tienen un driver privativo que ofrece un buen rendimiento, se instala correctamente y no suele dar problemas (suelen soportar el último kernel o casi que esté disponible en kernel.org). Su driver libre es nouveau, que es un…   » ver todo el comentario
#13 Te actualizo algunos puntos:

- NVIDIA: Su driver libre es prácticamente inusable con las nuevas tarjetas gráficas (GeForce 900 en adelante). El privativo, si bien ofrece un buen rendimiento, te impide usar distribuciones rolling release que hagan frecuentes actualizaciones del kernel. Mi opinión es que el liderazgo de nVidia en Linux está por morir.

- AMD: En cuanto a OpenGL, RadeonSI (el driver libre para las gráficas modernas) supera ampliamente en prácticamente todos los benchmarks al…   » ver todo el comentario
#14 mis dieces, salvo por lo de que el liderazgo de nvidia en linux esta por morir. Entre los talibanes de la licencia, si, se va a ir al carajo, pero si te da igual la licencia y lo que quieres es eficiencia, pones el driver propietario y va como la seda. No me refiero a los juegos, que no si siquiera si hay juegos para linux homologables a los de windows, si no a la gente que quiere hacer cositas con CUDA porque desarrolla aplciaciones de bigdata o IA. A esos lo que les importa es el…   » ver todo el comentario
#17 las distros meten nouveau por defecto (...) y al taliban que lo ha puesto por defecto

No es una cuestión de talibanismo. Sencillamente, las distribuciones no pueden incluir el controlador propietario precisamente por cuestión de licencia. Y eso es, en mi opinión, lo que poco a poco hará morir al controlador de nVidia. La integración se vuelve infumable cuando tienes que instalar un blob privativo que no se actualiza al mismo tiempo que hay una actualización del kernel.

Luego…   » ver todo el comentario
#18 claro que pueden meter el driver propietario porque los señores de Nvidia no se enfadan. De hecho, debe ser de los pocos programas que tiene "instalador". No es un instalador grafico, pero no esta mal. Lo que pasa es que si lo meten no pueden poner "nuestra distro es completamente libre", asi que lo que hacen es poner un repositorio separado y un programa para instalarlo dando "siguiente-siguiente", junto a los drivers del wifi o el firmware del kernel.

Lo de…   » ver todo el comentario
#19 #16 AMD lleva mucho tiempo aportando herramientas libres, el problema es que hasta hace poco el soporte en cuanto a drivers y a linux dejaba que desear. Pero creo que este año que viene por fin estará todo en su sitio (y me refiero no sólo a drivers en si, sino soporte a HSA, OpenCL, etc). Entre eso y las herramientas libres que ya existen (toda la iniciativa "Open") será una plataforma de desarrollo de un nivel importante (que siempre habrá que pulir, pero los desarrolladores por fin tendrán todo a su disposición, libre, con documentación y soporte).
#24 a ver, lo que queria decir es que lo de "open" o lo de "libre", al que de verdad trabaja con esas cosas, se la pela. Si tu estas haciendo cosas para redes neuronales y te dicen "tal tarjeta tiene 2000 nucleos" te la refanflinfla que lo que lo mueve todo sea propietario o no. Vamos, que si el barbas se pone triste te da igual. Tu instalas el driver que tengas que instalar porque lo que quieres son los 2000 nucleos, y si quieres 2000 nucleos y linux te lo pone…   » ver todo el comentario
#27 Pues no debería. No es lo mismo CUDA (que cuando nvidia se vaya al carajo o deje de dar soporte vía drivers en tarjetas más nuevas todo lo que hayas invertido en programas que lo usen se quedará estancado, no pudiendo aprovecharlo en el futuro) que OpenCL. De hecho, hay mucho interés puesto en conversores CUDA -> OpenCL.

Linux no te lo pone difícil, quien te lo pone difícil son las empresas que desarrollan para una plataforma en mente y se olvidan de los estándares. Haciendo software…   » ver todo el comentario
#30 pero no confundas "estandar" con "libre". C++ es un estandar y despues tu usas el compilador que te de la gana. Pues con esto igual. Tu puedes usar CUDA que te ata a nvidia u OpenCL que, en teoria, te permitira hacer lo mismo con la misma eficiencia en cualquier hardware. Mejor OpenCL entonces, si, pero tambien con el compilador que yo quiera, el driver que yo quiera y el SO que yo quiera, que pueden seguir el estandar mas o menos y tener una licencia mas o menos libre…   » ver todo el comentario
#34 No basta con que sea abierto. .NET es abierto, pero MS puede cambiarlo cuando quiera. Java como implementación de lenguaje es abierto, pero lo controla ORACLE.

OPENCL es abierto, si, pero no está atado a una empresa, sino a toda la industria (o a todos los que quieran, el grupo khronos está abierto a recibir nuevos miembros, peticiones, etc. para mejorar sus estándares. Y si, hay varias implementaciones del estándar.

Y digo abierto porque ninguno es libre. No están atados a una licencia…   » ver todo el comentario
#24 Sí, sí, definitivamente. Pero antes nVidia estaba más al nivel. En cuanto a herramientas, Nsight hacía frente a CodeXL. En cuanto a divulgación, los ejemplos (samples) de nVidia tenían incluso más nivel que los de AMD. En cuanto a rendimiento de drivers nVidia estaban en otra liga, directamente, etc. Pero en lo que a Vulkan se refiere, AMD evoluciona rápido y bien y nVidia no le sigue el ritmo pero por mucho, además.

Con nVidia no hay profiler para Vulkan todavía (AMD tiene Radeon GPU…   » ver todo el comentario
#33 Digamos que aún vulkan no es nada. OpenGL es el estándar de facto aún, y en empresas gordas, de esas que llenan granjas con tarjetas nvidia para render, procesado de datos o lo que sea, tiran de OpenGL y CUDA. ¿Dónde va a poner la pasta nvidia? que se estén disparando un tiro en el pie el tiempo dirá.

Por otro lado, nvidia no es tonta, las herramientas que ha liberado AMD son libres y abiertas. Esto es, funcionan en la competencia (al contrario que las de nvidia, que suelen funcionar sólo en su hardware). Si los de enfrente te hacen el trabajo...
#36 Ciertamente, buen análisis. A ver si hay suerte y Vulkan se come a OpenGL y CUDA. Tener un API multiplataforma que unifica render y compute es extremadamente cómodo... (aunque si OpenCL no ha podido con CUDA difícil veo que Vulkan pueda).
#10 Mesa es una implementación libre de OpenGL. Los drivers libres soportan mesa y mesa da una serie de infraestructuras que facilitan y ayudan a la creación de nuevos drivers (o sea, se trata de enganchar tu hardware a las partes de mesa que se comunican con el SO y las aplicaciones para dar soporte a las funciones OpenGL que estas últimas usan; los drivers privativos tienen que montarlo todo completo).

Wine no es un emulador. Son unas librerías que se encargan de sustituír las dlls de…   » ver todo el comentario
No sé qué me sorprende más, si lo bien que se está portando AMD con Vulkan (soporte; información, herramientas y código para desarrollo) o lo atrás que se está quedando nvidia al respecto. En cualquier caso, ¡bien por AMD!
me quedo con Intel. AMD/ATI lleva años prometiendo drivers libres para linux, con NVidia tienes que andar instalando su software propietario mientras que con las gráficas de Intel no tienes que hacer nada, instalas la distribución y listo
#20 Hace años que hay drivers libres. Pero AMD no tiene la cantidad de gente que tiene intel para ponerse al día de un día para otro. Y aún así van sacando una cantidad de trabajo impresionante adelante. A partir del kernel 3.16 (o mediados del próximo año), aparte de funcionar y funcionar bien y con buen rendimento, estarán prácticamente a la par que sus equivalentes en windows (y me refiero a funcionalidades, no sólo en cuanto a rendimiento, que en cuanto a eso ya lo están).
#25 no, si incluso los drivers de nVidia están bien considerando funcionalidades y rendimiento. pero la clave sigue siendo si funciona tal cual, plug&play o si tienes que averiguar donde y como descargar, instalar y configurar el software. que me parece genial que exista ese software, incluso el privativo de nVidia, pero yo me quedo con las tarjetas Intel que funcionan tal cual sin hacer nada. no se si entre tanto ocurre lo mismo con las ATI
#26 No hace falta hacer nada*, el soporte está integrado en el kernel y los drivers vienen con el SO**.

* Salvo en el caso de que tengas una vega, donde hay soporte limitado debido a que aunque desde el lanzamiento el driver completo es opensource y está disponible para cualquiera, aún están ciertas partes integrándose en el kernel. Aún así, siendo valiente todavía puedes instalar todo lo necesario desde repositorios de terceros (salvo que quieras compilarte tú el último kernel que aún no se…   » ver todo el comentario
yo no guardo buenas experiencias usando gnu/linux con AMD...
comentarios cerrados

menéame