Hace 6 años | Por vickop a muylinux.com
Publicado hace 6 años por vickop a muylinux.com

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.

Comentarios

Zeioth

Han cumplido lo que prometieron, bien por ellos!

ofuquillo

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.»

meneandro

#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).

D

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.

p

#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).

D

#5 ¿Que tal van los drivers Mesa esos tan buenos y que marcan el camino con el Asynchronous Reprojection de SteamVR para el Vive?

meneandro

#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 el espacio en el kernel y parte de infraestructura con los abiertos).

El caso de vulkan es parecido, usan los módulos de kernel que comparten con los drivers libres y ha sido creado para dar soporte a empresas y entornos con otros requisitos, pero apoyan al driver libre. La idea era liberar su driver privativo de vulkan antes, pero los lanzamientos de hardware y la cantidad y capacidad de la mano de obra es limitada (no sólo es liberar esto, están trabajando muy duro para incorporar al kernel ciertas partes clave de sus drivers para dar soporte a cosas como freesync, aún les queda mucho trabajo para incorporar ciertos componentes necesarios para el soporte de su pila de computación heterogenea y openCL, etc), así que se ha ido posponiendo.

Yo antes que decir que lo han hecho porque los drivers libres le hayan comido la tostada (en JUEGOS) diría que lo han hecho aprovechando el lanzamiento de su nueva generación de drivers en windows, por tener cosas que anunciar en la plataforma de linux.

x

#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 wayland, ni idea. He visto el paquete para instalarlo pero hasta que no ande mas estable no lo voy a probar, pero supongo que estara al menos una capa por encima del driver, asi que no creo que sea mucho problema para los de nvidia hacer que funcione.

Y si, a mi me encanta que los de AMD metan presion a los demas, porque eso significa que tendre cosas mejores para usar y sobre todo, mas baratas.

meneandro

#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).

x

#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 dificil, usas windows y te quedas tan agusto. Si te los da nvidia por 600 euros, bien, y si te los da AMD por 400, mejor, como mcuho puedes dividir los nucleos entre los euros para ver cual te merece mas la pena, pero desde luego la licencia es lo ultimo que miras.

La preocupacion por la licencia es cosa de Stallman y de talibanes.

meneandro

#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 portable usando los estándares existentes puedes cambiar de plataforma y no atarte a ningún fabricante concreto. Ciertas empresas te lo ponen fácil y crean estándares de facto, pero cuando tienen el mercado se cierran y te atan al mismo (al precio que pongan, porque no hay competencia... por culpa de los propios usuarios, esos que piensan como tú dices, malgastando el dinero y recursos de otros porque total, se la repanpinfla). Luego hay compañías como amd (la actual amd, he de decir), que sacan toda una serie de herramientas libres y abiertas para hacer las mismas cosas, para crear un ecosistema completo y potente que se desarrolle de forma sana (al fin y al cabo les conviene que la gente use sus herramientas y su hardware), pero donde cualquiera se pueda sumar. El beneficio al final es para todos, a AMD porque la comunidad y otras compañías lo expandirán, pulirán sus herramientas, añadirán mejoras, sacarán jugo a su hardware añadiendo nuevas posibilidades e ideas que ellos no ofrecen (porque están más enfocados a otras indústrias o entornos), etc.

x

#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 porque "estandar" y "libre" son cosas diferentes, aunque siempre se describan de forma comercial con la palabra "open".

Si tu programas con OpenCL usando una tarjeta nvidia, que puedes, lo logico es que uses el driver propietario (lo de "privativo" es una gilipollez) porque te va a ir mucho mejor. En ese caso estaras usando un estandar con software propietario, tu programa sera portable* pero Stallman se pondra triste e intentara convercerte de que eres una mala persona por no usar nouveau.

No nos liemos con la palabra "open" que la usa todo el mundo...

* bueno, tan portable como son los programas que usan estandares...

meneandro

#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 que permita su modificación por cualquiera, están atados a compañías o a organizaciones que controlan y velan por su desarrollo.

Si programas OpenCL con nvidia lo haces con el propietario si o si. Noveau no está lo suficientemente maduro para hacer openCL (porque es un esfuerzo altruísta y de ingeniería inversa brutal, bastante tienen con dar soporte a la aceleración 3D), así que es la única forma.

j

#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 Profiler), los drivers de AMD ya sí compiten con los de nVidia, AMD ha liberado código super-útil como el Vulkan Memory Allocator (nVidia también ha hecho cosillas, como Vulkan-Hpp, pero no es lo mismo), en cuanto a ejemplos y tal ninguno tienen muchos, pero tampoco es que hagan falta gracias a Sascha Willems...

Al final me compraré una AMD y todo

meneandro

#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...

j

#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).

D

¿esto puede correr en mi Lubuntu? 😐

frankiegth

#2. Apuesto a que puede correr en tu Lubuntu y en el mio.

j

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!

j

(NVidia, F.... you )

meneandro

#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 ha lanzado, con todos los riesgos que ello conlleva). La única opción para un usuario común es esperar, en Abril junto con las versiones gordas de ciertas distros (fedora 28 y ubuntu 18.04 y derivados) ya debería estar todo en su sitio y de manera más pulida y estable. Antes de eso existirán backports a distros actuales casi con total seguridad, las betas de las anteriores y el siempre útil proceso de compilarte tú mismo lo que necesites. O utilizar el driver privativo hasta ese entonces.

** Los drivers por lo demás están listos. Todo este "retraso" viene por el hecho de que amd está compartiendo cada vez más código entre los desarrollos de windows demás sistemas operativos, y buena parte de algunas funcionalidades necesarias para que todo funcione está tratándose de integrar en el kernel. Para que te hagas una idea, llevan al menos año y medio puliendo cosas para que esto sea posible, dado que desde el kernel de linux les rechazaron la petición original porque el código que querían integrar chocaba contra muchas de las políticas de desarrollo, mantenibilidad y de calidad que se exigen (si todo el mundo pusiera lo que quisiera y como quisiera dentro del kernel, se convertiría en un infierno inmanejable e inauditable). Entre otras cosas, en lugar de usar las facilidades dadas por el kernel para muchas cosas añadían las suyas propias (compartir código hace que todo sea menos dado a contener errores y es mucho más limpio que si todo el mundo mete código para hacer lo mismo), el código necesitaba una limpieza a profundidad (mucho código escrito para plataformas más viejas, en desuso, o sin uso), una auditoría de seguridad hecha por la gente del kernel encontró bastantes agujeros, etc. Sin el retraso que les ha supuesto revisar, refactorizar, etc. todo el código, sería plug & play tal y como tú dices. Y dentro de unos meses, como dije antes, así será.

PD: El soporte a futuras tarjetas gráficas será directo y a la par que el lanzamiento porque ya todo el trabajo "duro" de todos estos años para ponerse al día estará hecho. De hecho, los portátiles con la nueva apu basada en ryzen y vega está casi listo (como en el caso de las vega, llegará en el próximo kernel y luego tardará tanto en implantarse como lo que tarden las distros en ofrecerlo).

SiCk

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 Steam o cualquier juego? Y para cualquier juego, qué se hace, usar PlayOnLinux o eso ya no se usa?
- Y el rollo Vulkan, OpenGL, etc... en qué afecta?
- Y eso de CrossOver de CodeWeaver que decían que permitía DX10?
- ¿Y cómo rinde todo esto y a qué nivel de compatibilidad con un juego que salga "hoy" está esto?

No sé veo un jodido jaleo... Luego buscas info y tampoco se explica en ningún sitio, está inconexo todo. Estas cosas deberían explicarse medianamente claras porque si no...

c

#10 directX es de windows. OpenGL y Vulkan son interfaces abiertas multi-sistema.

D

#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 esfuerzo de la comunidad por tener un driver libre que dé soporte a las gráficas de esta compañía.

AMD: Tiene drivers propietarios que ofrecen un rendimiento similar a los que hay abiertos. En mi experiencia previa (hace años ya) solían dar problemas al compilar y era bastante lioso. El driver libre en general funciona suficientemente bien en comparación con el privativo.

Luego hay algunos proyectos nuevos para rehacer drivers/APIs como Gallium3d y alguno más de AMD. Por ahora están en una fase bastante temprana, no los consideraría estables todavía.

Luego en APIs hay varias: para 3D: OpenGL, Vulkan. Para aceleración gráfica de vídeo: VA-API, VDPAU, NVDEC, CUDA.

vickop

#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 driver privativo. RADV (la implementación de Vulkan libre y comunitaria) está casi al nivel del driver privativo (ahora libre). En algunos juegos va mejor RADV y en otros la implementación oficial. Puedes ver los benchmarks en phoronix:
https://www.phoronix.com/scan.php?page=article&item=amdgpu-1750-open&num=1

Me da la impresión de que esto va a servir sobretodo para que RADV mejore, y probablemente acabe siendo la implementación preferida (ya lo es ahora) para la mayoría de situaciones.

Ahora queda que mejore el soporte OpenCL.

x

#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 rendimiento bruto y la licencia se la pela, y ahi gana Nvidia. Al menos, hasta ahora, a ver que pasa con los Ryzen, Vulkan y todo esto, que parece que AMD se esta poniendo las pilas.

En realidad el problema de Nvidia en Linux viene precisamente porque las distros meten nouveau por defecto y si tienes una tarjeta medio modernilla te encuentras con que tu linux arranca con una pantalla negra y te cagas en todo. Y despues lo de instalar el driver propietario y mandar a tomar por culo nouveau y al taliban que lo ha puesto por defecto no esta del todo conseguido en todas las distros, asi que te vuelves a cagar en todo.

vickop

#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 está la otra parte de por qué opino que el liderazgo de nVidia en Linux acabará muriendo. Su soporte a Wayland, que es hoy día el futuro del stack gráfico de Linux. Si has seguido las discusiones en torno a EGLStreams vs GBM, verás que la mayoría de la comunidad está dando la espalda a nVidia con Wayland en Linux.

El panorama está muy muy interesante para los próximos años. AMD ha tardado, pero está demostrando que la estrategia opensource que inició hace algunos años, está dando sus frutos.

meneandro

#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 windows de manera que sean compatibles con las originales y el software que las use funcione en otros entornos que no sean windows. De hecho, otros proyectos como react os (que esto es un SO windows compatible escrito desde cero) las usan.

Gallium Nine es una reimplementación de DX9 para hacerlo funcionar sobre las infraestructuras gráficas de linux. Puede verse como wine, reescribir las dlls necesarias para que cualquier aplicación escrita para usar DX9 pueda ser portada o usada sin tener que reprogramar las partes gráficas en OpenGL o Vulkan para poder ser usadas en linux u otros SO (siempre habría que reprogramar todo lo que tenga que ver con el SO, claro, por eso se usa desde wine, porque es más rápido y eficiente usar nativamente DX9 que una capa que traduzca cada llamada a una función DX9 por una o más funciones OpenGL que hagan el trabajo equivalente).

DX10 o más aún no tienen un equivalente a Gallium Nine.

El rollo opengl, vulkan... no sé a qué te refieres. OpenGL es una api gráfica de semialto nivel (en su origen era de alto nivel, a partir de la llegada de los shaders cada vez se han ido introduciendo más y más elementos para poder usarla a bajo; al ser de alto nivel, hay muchas funciones muy complejas que tienen que ser añadidas vía drivers, lo que los hace muy pesados y complejos y gordunflos), Vulkan es una API gráfica de bajo nivel (en la que todo el trabajo gordo y sucio lo hacen los programadores de aplicaciones -o más bien los de frameworks que se usan para desarrollar aplicaciones y facilitarle la vida a los programadores-, así que los drivers son más sencillos y eficientes, aparte de que su diseño es más moderno y está adaptado a la época actual: paralelismo, virtualización, acceso y uso de múltiples y distintos recursos gráficos de hardware instalados directamente desde la aplicación y no desde drivers, etc).

CrossOver/CodeWeaver son marcas que explotan Wine comercialmente. Desarrollan wine, lo parchean para las aplicaciones específicas que se les demandan y ofrecen soluciones más profesionales y con soporte. O sea, básicamente son wine enfocados al entorno empresarial (donde no quieres que una actualización te rompa una aplicación que en la anterior te funcionaba).

Todo eso rinde... pues depende lol

Espero haberte aclarado el jaleo un poco.

keylogger

Esto aproxima más Linux al escritorio...

D

yo no guardo buenas experiencias usando gnu/linux con AMD...

D

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

meneandro

#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).

D

#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