Re: [opensuse-es] KDE Plasma 5 es un entorno de escritorio ligero
El día 12 de septiembre de 2016, 22:37, Luciano Gaston Pendino Pedetti
Primero que nada, maestro se lo extraña por autoblog. Ahora bien vamos por partes.
El sept. 12, 2016 7:41 PM, "Juan Erbes"
escribió: El día 12 de septiembre de 2016, 13:49, Luciano Gaston Pendino Pedetti
escribió: Buenas. En realidad KDE 5, consume lo mismo que 4, osea si el 4 funcionaba bien, el 5 también. Lo que si hay que tener es un vídeo que este bien soportado por linux y al día de hoy yo diría que solo intel y NVIDIA, AMD parece que va a sacar el soporte para linux (otra vez y van ya), así que ahí esta el secreto el vídeo y que tan buenos o no sean los drivers. En lo personal con NVIDIA y los drivers cerrados nunca tuve un problema, no así con ati y drivers tanto libres como los propietarios de ahí.
El sept. 11, 2016 8:43 PM, "Juan Erbes"
escribió: Personalmente, mi apreciación, es exactamente lo opuesto a lo que dices con respecto a Nvidia e intel, porque justamente ambos son los mas problemáticos, por lo que se puede ver en Factory, cada vez que sale un kernel nuevo y el rendimineto grafico de intel, tambien es pobre,
Veamos el rendimiento de intel es lo que es ya que a ellos no les importan las GPU y sus procesadores de vídeo son básicos ya que su negocio esta en otro lado. Segundo yo tengo los tres NVIDIA, intel y AMD en mis maquinas y el único GPU que me dio dolores de cabeza fue el AMD (tengo dos apu, un c50 y un a6 3670k, en el a6 lo solucione con una GT 440, en el c50 hasta el día de hoy reniego, ya sea con los drivers libres como con los cerrados).
y hoy en dia con el incremento del uso de los APUs, Nvidia
queda fuera de la competencia, salvo que se compre una tarjeta especificamente de esa marca, y los unicos APUs con un rendimiento de video decente, son los de AMD.
Así es los apus son de AMD porque ellos los crearon y NVIDIA vende VGA discretas, además de soc arm, así que como va a integrar su vídeo en la plataforma de la competencia, es mas ya ni hace chipsets, salvo para proyectos como tesla.
AMD hace mucho que liberó el codigo fuente (cosa que Nvidia nunca hizo) y el driver "de codigo abierto" para Nvidia, es basado en ingenieria inversa, y su funcionamiento deja mucho que desear.
El código que libero amd/ati es de sus primeros GPU de hace mas de 15 años, de los actuales nada y los drivers abiertos que hay se basan en esos. Los drivers libres para NVIDIA están basados en los viejos tnt y riva los cuales NVIDIA abrió en su momento, pero la única forma de que funcionen bien es con el driver cerrado tanto de NVIDIA como de AMD
No tengo la fecha exacta de a que versión del codigo cerrado de ATI/AMD correspondia el codigo fuente que liberaron, pero la realidad es que las comparativas de los 3 chipsets graficos, usando drivers de codigo abierto, las tarjetas y chips Radeon rinden el triple que los intel y Nvidia: http://www.phoronix.com/scan.php?page=article&item=linux_2014_opengpu&num=6 The open-source Radeon Linux graphics support is now in great shape now that the RadeonSI Gallium3D is starting to stabilize, Dynamic Power Management is enabled by default, and there's been a host of other optimizations and improvements made. The performance, OpenGL feature set, and other features still don't meet Catalyst, but the open-source driver is definitely moving in the right direction and pleasing many open-source fans. Incluso hay tests realizados hace 1 año, comparando las mismas tarjetas Radeon con el driver de codigo abierto Radeon, versus el Catalyst de codigo cerrado, y las diferencias en rendimiento, no son demasiado grandes: http://www.phoronix.com/scan.php?page=article&item=amd-157-open&num=3 "Overall these results today were quite positive for the open-source AMD Linux driver with this code continuing to become more competitive with Catalyst, as far as OpenGL 2~3 test-cases are concerned until OpenGL 4.x support finishes up in Mesa and the OpenCL support in Clover Gallium3D advances further" Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien". De todas formas, hay un repositorio con el driver propietario de AMD, que hasta ahora me ha dado muy buen resultado: Version: 42.1http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_Leap_42.1/ Version: 13.2http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_13.2/ Version: 13.1http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_13.1/ Version: 12.3http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.3/ Version: 12.2http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.2/ Version: 12.1http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.1/ Version: 11.4http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_11.4/ Version: 11.3http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_11.3/ Version: 11.2http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_11.2/ Con respecto a las consolas de juegos, la mayoría de las consolas de juegos de primeras marcas, están utilizando los APUs de AMD, como la Xbox® One, Nintendo Wii®U, Sony PlayStation®4 y algunas de las basadas en Linux como las Steam. http://www.amd.com/en-us/solutions/semi-custom/gaming-console Aunque uno mismo se puede armar algo equivalente: http://wccftech.com/steam-machine-faster-cheaper-ps4-xbox/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2016-09-13 a las 08:54 -0300, Juan Erbes escribió:
El día 12 de septiembre de 2016, 22:37, Luciano Gaston Pendino Pedetti
escribió:
Luciano, acuerdate de responder SÓLO a la lista. Los demás no estamos viendo tus respuestas, sólo Juan. Cuando el destinatario está usando gmail debeis tener especial cuidado con responderles sólo la la lista, nunca a los dos, porque sólo va a recibir la respuesta privada; nunca verá la respuesta a la lista porque gmail la borra. Por tanto cuando él a su vez responde, lo hace creyendo que responde a un correo privado, y los demás nos quedamos a dos velas. - -- Saludos Carlos E. R. (desde 13.1 x86_64 "Bottle" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlfYB8MACgkQtTMYHG2NR9VfrwCfS4f8iftFG6zUbddgiCKbIlmf +KgAn1LGkFfb23Bnz7OcwF0XqdevpPVu =ePOX -----END PGP SIGNATURE-----
Hola :)
2016-09-13 14:54 GMT+03:00 Juan Erbes
Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien".
No me extraña que te contestasen eso. El "cliente profesional" (nótense las ") mayoritariamente utiliza NVIDIA (he escrito "mayoritariamente", no he escrito "exclusivamente" ya que hay de todo). Con "cliente profesional" me refiero a gente que usa estaciones de trabajo potentes, sistemas de visualización (walls 3D, CAVEs, ...), 3D remoto, HPC (GPGPU). No es muy común/habitual ver ese tipo de cliente utilizando AMD, por desgracia. Razones hay muchas: - CUDA da mejor rendimiento que OpenCL - NVIDIA se ha encargado de adelantarse a AMD para firmar acuerdos con ISVs - CUDA tiene algunas características muy interesantes - los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA* (NOTA más abajo) - ... Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar * Dicho por una empresa de desarrollo de visualización 3D remota cuando les pregunté por AMD. Curiosamente, AMD, por ejemplo, tiene tarjetas con más memoria y tiene tarjetas que dan mejor rendimiento en Simple Precision (útil para cierto SW de prospección petrolífero, render, ...). Pero AMD no ha sabido llegar al cliente :( ¿Mal marketing? Posiblemente. Puede que AMD haya enfocado su tiro en otro mercado: embedded y sistemas de bajo consumo (como menciona Juan en su correo anterior con respecto a las consolas y a los sistemas de videowall. Otra cosa en la que ha flaqueado AMD es que carecía de herramientas de desarrollo y optimización de código como las que tienen Intel y NVIDIA. Una buena noticia es que parece ser que están intentado cambiar todo eso y tienen la iniciativa GPUOPEN (http://gpuopen.com/). La idea es ofrecer herramientas a "usuarios profesionales": debuggers, librerías matemáticas, compiladores, motores de render, ... Espero que tengan éxito :) Yo sigo comprando AMD para mi casa, tengo una APU y soy muy feliz corriendo KDE (Tumbleweed con el último KDE ;) ya que responde bien, no consume muchos recursos y es estable. Ando ansioso para ver cómo quedan Polaris y Zen :)" BTW: AMD tiene lo que llaman AMDGPU, que son drivers oficiales de AMD para GPUs AMD y es código abierto. NO son los drivers radeon. AMDGPU ha sido desarrollado por AMD. En su web pone que soportan Ubuntu ... a ver qué ocurre en el futuro. Espero que SUSE esté soportada. Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 13 de septiembre de 2016, 18:51, Rafa Griman
Hola :)
2016-09-13 14:54 GMT+03:00 Juan Erbes
: [...]
Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien".
No me extraña que te contestasen eso. El "cliente profesional" (nótense las ") mayoritariamente utiliza NVIDIA (he escrito "mayoritariamente", no he escrito "exclusivamente" ya que hay de todo). Con "cliente profesional" me refiero a gente que usa estaciones de trabajo potentes, sistemas de visualización (walls 3D, CAVEs, ...), 3D remoto, HPC (GPGPU). No es muy común/habitual ver ese tipo de cliente utilizando AMD, por desgracia. Razones hay muchas: - CUDA da mejor rendimiento que OpenCL - NVIDIA se ha encargado de adelantarse a AMD para firmar acuerdos con ISVs - CUDA tiene algunas características muy interesantes - los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA* (NOTA más abajo) - ...
Con respecto a "los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA" Entonces porque Linus Torvalds dijo: “Nvidia, fuck you” https://www.wired.com/2012/06/torvalds-nvidia-linux/ Creo que si no fuera por el esfuerzo de los desarrolladores de las distintas distribuciones, en ajustar el kernel y generar parches para hacer funcionar los drivers propietarios Nvidia, muchos equipos con esas gráficas, quedarían inutilizables bajo Linux, ya que los drivers de codigo abierto para Nvidia, son pésimos. Pero a pesar de eso, algunas empresas insisten en utilizar solamente Cuda bajo Linux como Lightworks, en lugar de poner librerías para Cuda y OpenCl, para que la aplicación utiliza mejor el hardware.
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
* Dicho por una empresa de desarrollo de visualización 3D remota cuando les pregunté por AMD.
Curiosamente, AMD, por ejemplo, tiene tarjetas con más memoria y tiene tarjetas que dan mejor rendimiento en Simple Precision (útil para cierto SW de prospección petrolífero, render, ...). Pero AMD no ha sabido llegar al cliente :( ¿Mal marketing? Posiblemente. Puede que AMD haya enfocado su tiro en otro mercado: embedded y sistemas de bajo consumo (como menciona Juan en su correo anterior con respecto a las consolas y a los sistemas de videowall. Otra cosa en la que ha flaqueado AMD es que carecía de herramientas de desarrollo y optimización de código como las que tienen Intel y NVIDIA.
Una buena noticia es que parece ser que están intentado cambiar todo eso y tienen la iniciativa GPUOPEN (http://gpuopen.com/). La idea es ofrecer herramientas a "usuarios profesionales": debuggers, librerías matemáticas, compiladores, motores de render, ... Espero que tengan éxito :)
Yo sigo comprando AMD para mi casa, tengo una APU y soy muy feliz corriendo KDE (Tumbleweed con el último KDE ;) ya que responde bien, no consume muchos recursos y es estable. Ando ansioso para ver cómo quedan Polaris y Zen :)"
BTW: AMD tiene lo que llaman AMDGPU, que son drivers oficiales de AMD para GPUs AMD y es código abierto. NO son los drivers radeon. AMDGPU ha sido desarrollado por AMD. En su web pone que soportan Ubuntu ... a ver qué ocurre en el futuro. Espero que SUSE esté soportada.
Muy buen resumen! Acabo de ver lo de AMDGPU: http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-GPU-PRO-Linux-Beta... Interesantes características: Provides support for Radeon™ RX 480, Radeon™ RX 470 and Radeon™ RX 460 series products Supported APIs: OpenGL 4.5 and GLX 1.4 OpenCL 1.2 Vulkan 1.0 VDPAU Vulkan support for DOTA2 Basic display features Basic power management features KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support GPL compliant kernel module Install script and Debian packages for Ubuntu 16.04 Y Opensuse, para cuando? De todas formas, no creo que el kernel difiera demasiado, será cuestión de probar cuando esté un poco mas madura, si uno tiene una tarjeta grafica compatible. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 13 de septiembre de 2016, 19:31, Pinguino Patagonico
El día 13 de septiembre de 2016, 18:51, Rafa Griman
escribió: Hola :)
2016-09-13 14:54 GMT+03:00 Juan Erbes
: [...]
Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien".
No me extraña que te contestasen eso. El "cliente profesional" (nótense las ") mayoritariamente utiliza NVIDIA (he escrito "mayoritariamente", no he escrito "exclusivamente" ya que hay de todo). Con "cliente profesional" me refiero a gente que usa estaciones de trabajo potentes, sistemas de visualización (walls 3D, CAVEs, ...), 3D remoto, HPC (GPGPU). No es muy común/habitual ver ese tipo de cliente utilizando AMD, por desgracia. Razones hay muchas: - CUDA da mejor rendimiento que OpenCL - NVIDIA se ha encargado de adelantarse a AMD para firmar acuerdos con ISVs - CUDA tiene algunas características muy interesantes - los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA* (NOTA más abajo) - ...
Con respecto a "los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA"
Entonces porque Linus Torvalds dijo: “Nvidia, fuck you” https://www.wired.com/2012/06/torvalds-nvidia-linux/
Creo que si no fuera por el esfuerzo de los desarrolladores de las distintas distribuciones, en ajustar el kernel y generar parches para hacer funcionar los drivers propietarios Nvidia, muchos equipos con esas gráficas, quedarían inutilizables bajo Linux, ya que los drivers de codigo abierto para Nvidia, son pésimos.
Pero a pesar de eso, algunas empresas insisten en utilizar solamente Cuda bajo Linux como Lightworks, en lugar de poner librerías para Cuda y OpenCl, para que la aplicación utiliza mejor el hardware.
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
* Dicho por una empresa de desarrollo de visualización 3D remota cuando les pregunté por AMD.
Curiosamente, AMD, por ejemplo, tiene tarjetas con más memoria y tiene tarjetas que dan mejor rendimiento en Simple Precision (útil para cierto SW de prospección petrolífero, render, ...). Pero AMD no ha sabido llegar al cliente :( ¿Mal marketing? Posiblemente. Puede que AMD haya enfocado su tiro en otro mercado: embedded y sistemas de bajo consumo (como menciona Juan en su correo anterior con respecto a las consolas y a los sistemas de videowall. Otra cosa en la que ha flaqueado AMD es que carecía de herramientas de desarrollo y optimización de código como las que tienen Intel y NVIDIA.
Una buena noticia es que parece ser que están intentado cambiar todo eso y tienen la iniciativa GPUOPEN (http://gpuopen.com/). La idea es ofrecer herramientas a "usuarios profesionales": debuggers, librerías matemáticas, compiladores, motores de render, ... Espero que tengan éxito :)
Yo sigo comprando AMD para mi casa, tengo una APU y soy muy feliz corriendo KDE (Tumbleweed con el último KDE ;) ya que responde bien, no consume muchos recursos y es estable. Ando ansioso para ver cómo quedan Polaris y Zen :)"
BTW: AMD tiene lo que llaman AMDGPU, que son drivers oficiales de AMD para GPUs AMD y es código abierto. NO son los drivers radeon. AMDGPU ha sido desarrollado por AMD. En su web pone que soportan Ubuntu ... a ver qué ocurre en el futuro. Espero que SUSE esté soportada.
Muy buen resumen!
Acabo de ver lo de AMDGPU: http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-GPU-PRO-Linux-Beta...
Interesantes características:
Provides support for Radeon™ RX 480, Radeon™ RX 470 and Radeon™ RX 460 series products Supported APIs:
OpenGL 4.5 and GLX 1.4 OpenCL 1.2 Vulkan 1.0 VDPAU Vulkan support for DOTA2
Basic display features Basic power management features KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support GPL compliant kernel module Install script and Debian packages for Ubuntu 16.04
Interesante! Viendo lo de: "KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support GPL compliant kernel module" En teoría, se debería incorporar como un modulo mas al kernel, una vez que sea estable! Y de paso, se evitan tener que parchear el driver cada vez que cambia la versión del kernel! -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :)
2016-09-14 1:31 GMT+03:00 Pinguino Patagonico
El día 13 de septiembre de 2016, 18:51, Rafa Griman
escribió: Hola :)
2016-09-13 14:54 GMT+03:00 Juan Erbes
: [...]
Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien".
No me extraña que te contestasen eso. El "cliente profesional" (nótense las ") mayoritariamente utiliza NVIDIA (he escrito "mayoritariamente", no he escrito "exclusivamente" ya que hay de todo). Con "cliente profesional" me refiero a gente que usa estaciones de trabajo potentes, sistemas de visualización (walls 3D, CAVEs, ...), 3D remoto, HPC (GPGPU). No es muy común/habitual ver ese tipo de cliente utilizando AMD, por desgracia. Razones hay muchas: - CUDA da mejor rendimiento que OpenCL - NVIDIA se ha encargado de adelantarse a AMD para firmar acuerdos con ISVs - CUDA tiene algunas características muy interesantes - los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA* (NOTA más abajo) - ...
Con respecto a "los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA"
Entonces porque Linus Torvalds dijo: “Nvidia, fuck you” https://www.wired.com/2012/06/torvalds-nvidia-linux/
Porque la colaboración con la Comunidad de código abierto por parte de NVIDIA roza (tiende a, como dirían los matemáticos) 0 (número cero). Por ejemplo, échale un vistazo a lo que está ocurriendo con Wayland y NVIDIA ...
Creo que si no fuera por el esfuerzo de los desarrolladores de las distintas distribuciones, en ajustar el kernel y generar parches para hacer funcionar los drivers propietarios Nvidia, muchos equipos con esas gráficas, quedarían inutilizables bajo Linux, ya que los drivers de codigo abierto para Nvidia, son pésimos.
Pero a pesar de eso, algunas empresas insisten en utilizar solamente Cuda bajo Linux como Lightworks, en lugar de poner librerías para Cuda y OpenCl, para que la aplicación utiliza mejor el hardware.
Como decía más abajo, NVIDIA se ha adelantado a firmar acuerdos con ISVs, cosa que AMD no hizo a tiempo :(
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
* Dicho por una empresa de desarrollo de visualización 3D remota cuando les pregunté por AMD.
Otro ejemplo de esto es el soporte de Cycles (motor de render de Blender) que le dan a AMD. Si echas un vistazo a las notas, verás que funciona mejor con NVIDIA y que con AMD han tenido muchos problemas. Ahora AMD parece que está destinando más recursos (se han comprometido con Ton a pagar el sueldo de una persona durante un año). Como decía, parece que AMD está haciendo más cosas. Espero que vea su fruto y gane cuota d emercado.
Curiosamente, AMD, por ejemplo, tiene tarjetas con más memoria y tiene tarjetas que dan mejor rendimiento en Simple Precision (útil para cierto SW de prospección petrolífero, render, ...). Pero AMD no ha sabido llegar al cliente :( ¿Mal marketing? Posiblemente. Puede que AMD haya enfocado su tiro en otro mercado: embedded y sistemas de bajo consumo (como menciona Juan en su correo anterior con respecto a las consolas y a los sistemas de videowall. Otra cosa en la que ha flaqueado AMD es que carecía de herramientas de desarrollo y optimización de código como las que tienen Intel y NVIDIA.
Una buena noticia es que parece ser que están intentado cambiar todo eso y tienen la iniciativa GPUOPEN (http://gpuopen.com/). La idea es ofrecer herramientas a "usuarios profesionales": debuggers, librerías matemáticas, compiladores, motores de render, ... Espero que tengan éxito :)
Yo sigo comprando AMD para mi casa, tengo una APU y soy muy feliz corriendo KDE (Tumbleweed con el último KDE ;) ya que responde bien, no consume muchos recursos y es estable. Ando ansioso para ver cómo quedan Polaris y Zen :)"
BTW: AMD tiene lo que llaman AMDGPU, que son drivers oficiales de AMD para GPUs AMD y es código abierto. NO son los drivers radeon. AMDGPU ha sido desarrollado por AMD. En su web pone que soportan Ubuntu ... a ver qué ocurre en el futuro. Espero que SUSE esté soportada.
Muy buen resumen!
Gracias :) Sinceramente tengo bastantes esperanzas con lo que está haciendo AMD, espero que "el mercado" responda favorablemente.
Acabo de ver lo de AMDGPU: http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-GPU-PRO-Linux-Beta...
Interesantes características:
Provides support for Radeon™ RX 480, Radeon™ RX 470 and Radeon™ RX 460 series products Supported APIs:
OpenGL 4.5 and GLX 1.4 OpenCL 1.2 Vulkan 1.0 VDPAU Vulkan support for DOTA2
Basic display features Basic power management features KMS (Kernel Mode Setting) and ADF (Atomic Display Framework) support GPL compliant kernel module Install script and Debian packages for Ubuntu 16.04
Y Opensuse, para cuando?
Esa es la cuestión ... Al ser código abierto, no creo que haya mucho problema. También es sabido que SUSE ha colaborado bastante más estrechamente con AMD que Red Hat.
De todas formas, no creo que el kernel difiera demasiado, será cuestión de probar cuando esté un poco mas madura, si uno tiene una tarjeta grafica compatible.
Mi APU no es compatible :( Es una A4-500, pero con radeon funciona muy bien :) BTW, me he instalado readeon-top, muy útil (MHO). Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2016-09-13 16:51 GMT-05:00 Rafa Griman
Hola :)
2016-09-13 14:54 GMT+03:00 Juan Erbes
: [...]
Algo que yo le he reclamado a los desarrolladores de Opensuse, es que ponen mucho esfuerzo en hacer funcionar los drivers de codigo cerrado Nvidia, mientras que de los drivers Catalyst, casi ni se ocupan, y cuando les pregunté porque no se ocupaban de Catalyst, la respuesta fue "porque está el driver de codigo abierto Radeon que funciona muy bien".
No me extraña que te contestasen eso. El "cliente profesional" (nótense las ") mayoritariamente utiliza NVIDIA (he escrito "mayoritariamente", no he escrito "exclusivamente" ya que hay de todo). Con "cliente profesional" me refiero a gente que usa estaciones de trabajo potentes, sistemas de visualización (walls 3D, CAVEs, ...), 3D remoto, HPC (GPGPU). No es muy común/habitual ver ese tipo de cliente utilizando AMD, por desgracia. Razones hay muchas: - CUDA da mejor rendimiento que OpenCL - NVIDIA se ha encargado de adelantarse a AMD para firmar acuerdos con ISVs - CUDA tiene algunas características muy interesantes - los drivers cerrados de AMD no están del todo optimizados ni son tan estables como los de NVIDIA* (NOTA más abajo) - ...
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
* Dicho por una empresa de desarrollo de visualización 3D remota cuando les pregunté por AMD.
Curiosamente, AMD, por ejemplo, tiene tarjetas con más memoria y tiene tarjetas que dan mejor rendimiento en Simple Precision (útil para cierto SW de prospección petrolífero, render, ...). Pero AMD no ha sabido llegar al cliente :( ¿Mal marketing? Posiblemente. Puede que AMD haya enfocado su tiro en otro mercado: embedded y sistemas de bajo consumo (como menciona Juan en su correo anterior con respecto a las consolas y a los sistemas de videowall. Otra cosa en la que ha flaqueado AMD es que carecía de herramientas de desarrollo y optimización de código como las que tienen Intel y NVIDIA.
Una buena noticia es que parece ser que están intentado cambiar todo eso y tienen la iniciativa GPUOPEN (http://gpuopen.com/). La idea es ofrecer herramientas a "usuarios profesionales": debuggers, librerías matemáticas, compiladores, motores de render, ... Espero que tengan éxito :)
Yo sigo comprando AMD para mi casa, tengo una APU y soy muy feliz corriendo KDE (Tumbleweed con el último KDE ;) ya que responde bien, no consume muchos recursos y es estable. Ando ansioso para ver cómo quedan Polaris y Zen :)"
BTW: AMD tiene lo que llaman AMDGPU, que son drivers oficiales de AMD para GPUs AMD y es código abierto. NO son los drivers radeon. AMDGPU ha sido desarrollado por AMD. En su web pone que soportan Ubuntu ... a ver qué ocurre en el futuro. Espero que SUSE esté soportada.
Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Saludos haciendo un poco de off-topic. Justo escuche CUDA en un proyecto de investigación sobre Deep Learning acerca de música. =| Pero primero lo primero, lo escuché en este podcast [Software Engineering Daily - Music Deep Learning with Feynman Liang](http://softwareengineeringdaily.com/2016/09/02/music-deep-learning-with-feyn...) el repositorio de su proyecto [GIT - Bach Bot](https://github.com/feynmanliang/bachbot) y la web de su proyecto [Bach Bot Challenge](http://bachbot.com/#/?_k=smfllq) En el repositorio incluyen la imagen docker para CUDA 7.5 =| Si lo están usando, algo de bueno habrá de tener. Y nada más. =D Suerte. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Wenas :)
2016-09-14 6:47 GMT+03:00 Carlos Ayala
2016-09-13 16:51 GMT-05:00 Rafa Griman
:
[...]
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
[...]
haciendo un poco de off-topic. Justo escuche CUDA en un proyecto de investigación sobre Deep Learning acerca de música. =|
Es lo más "in"/"trending"/"you name it" del momento. Ahora todo el mundo hace Deep Learning (salvo el Ser Humano >;) Se usa para todo y en todos los campos ... o eso quieren. Ya sabes: "cuando tienes un martillo en la mano ... todo son clavos". Con eso no quiero decir que Deep Learning no sea útil, sino que es la última moda y todo el mundo quiere (o dice) que usan/hacen Deep Learning.
Pero primero lo primero, lo escuché en este podcast [Software Engineering Daily - Music Deep Learning with Feynman Liang](http://softwareengineeringdaily.com/2016/09/02/music-deep-learning-with-feyn...) el repositorio de su proyecto [GIT - Bach Bot](https://github.com/feynmanliang/bachbot) y la web de su proyecto [Bach Bot Challenge](http://bachbot.com/#/?_k=smfllq)
En el repositorio incluyen la imagen docker para CUDA 7.5 =| Si lo están usando, algo de bueno habrá de tener.
Como decía más arriba, CUDA no es malo. Lo que ocurre es que tiene algunas cosas a tener en cuenta (ver más arriba). Lo cierto es que CUDA ofrece mejor rendimiento que OpenCL, OpenACC y/o las Intel Phi y eso es lo que ha llevado a la gente a CUDA. CUDA fue el primero en salir y tienes muchas herramientas d edesarrollo, muchas librerías, soporte para muchos lenguajes de desarrollo, ... En segundo lugar está Intel con sus Phi ya que tiene muchas herramientas, es compatible con x86 (en teoría basta con recompilar ... la realidad es que tienes que paralelizar el código si quieres realmente mejorar el rendimiento, igual que con CUDA), pero el rendimiento es menor. En último lugar está AMD porque carecía de las herramientas de desarrollo ... hasta ahora que ha sacado lo de GPUOPEN. Tengo los dedos cruzados esperando que ganen algo de terreno/mercado. Hay mucho SW de terceros ya migrado a CUDA y ya sabes: da pereza cambiar/migrar/soportar OpenCL, es costoso económicamente mantener ambas opciones, si el rendimiento es peor ... el cliente no lo usará y es mala prensa, han firmado acuerdos que tendrán cláusulas determinadas, ... Por último, el cliente oye CUDA y NVIDIA en Internet, AMD casi no se oye ... ¿qué va a pedir el cliente? Lo que se oye. Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 14 de septiembre de 2016, 5:22, Rafa Griman
Wenas :)
2016-09-14 6:47 GMT+03:00 Carlos Ayala
: 2016-09-13 16:51 GMT-05:00 Rafa Griman
: [...]
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
[...]
haciendo un poco de off-topic. Justo escuche CUDA en un proyecto de investigación sobre Deep Learning acerca de música. =|
Es lo más "in"/"trending"/"you name it" del momento. Ahora todo el mundo hace Deep Learning (salvo el Ser Humano >;)
Se usa para todo y en todos los campos ... o eso quieren. Ya sabes: "cuando tienes un martillo en la mano ... todo son clavos". Con eso no quiero decir que Deep Learning no sea útil, sino que es la última moda y todo el mundo quiere (o dice) que usan/hacen Deep Learning.
Pero primero lo primero, lo escuché en este podcast [Software Engineering Daily - Music Deep Learning with Feynman Liang](http://softwareengineeringdaily.com/2016/09/02/music-deep-learning-with-feyn...) el repositorio de su proyecto [GIT - Bach Bot](https://github.com/feynmanliang/bachbot) y la web de su proyecto [Bach Bot Challenge](http://bachbot.com/#/?_k=smfllq)
En el repositorio incluyen la imagen docker para CUDA 7.5 =| Si lo están usando, algo de bueno habrá de tener.
Como decía más arriba, CUDA no es malo. Lo que ocurre es que tiene algunas cosas a tener en cuenta (ver más arriba). Lo cierto es que CUDA ofrece mejor rendimiento que OpenCL, OpenACC y/o las Intel Phi y eso es lo que ha llevado a la gente a CUDA. CUDA fue el primero en salir y tienes muchas herramientas d edesarrollo, muchas librerías, soporte para muchos lenguajes de desarrollo, ... En segundo lugar está Intel con sus Phi ya que tiene muchas herramientas, es compatible con x86 (en teoría basta con recompilar ... la realidad es que tienes que paralelizar el código si quieres realmente mejorar el rendimiento, igual que con CUDA), pero el rendimiento es menor. En último lugar está AMD porque carecía de las herramientas de desarrollo ... hasta ahora que ha sacado lo de GPUOPEN. Tengo los dedos cruzados esperando que ganen algo de terreno/mercado.
Hay mucho SW de terceros ya migrado a CUDA y ya sabes: da pereza cambiar/migrar/soportar OpenCL, es costoso económicamente mantener ambas opciones, si el rendimiento es peor ... el cliente no lo usará y es mala prensa, han firmado acuerdos que tendrán cláusulas determinadas, ... Por último, el cliente oye CUDA y NVIDIA en Internet, AMD casi no se oye ... ¿qué va a pedir el cliente? Lo que se oye.
Hoy en día, los que entendemos de hardware, y tambien los fabricantes de computadoras de escritorio, buscamos armar equipos con buen rendimiento, al mas bajo costo posible, terminamos eligiendo un APU de AMD. Pero parece ser, que quienes diseñan el software no se enteran de eso, y te quieren obligar a usar librerías y drivers de Nvidia, cuando en el hardware de tu computadora, no hay ni un solo chip de Nvidia. Habría que echar un vistazo a los tiempos en que las granjas de renderizado, sebasaban en procesadores AMD64: http://www.linuxjournal.com/article/6783 Pero con la diferencia en cantidad de nucleos entre GPU y CPU, obviamente, se han decantado por los GPU con el correr de los años. Pero una cosa es una granja de renderizado, y otra cosa es una computadora de escritorio. A la hora de que una empresa desarrolla software para computadoras de escritorio, debería tener en cuenta cual es el hardware que tienen esas computadoras de escritorio. No por nada, los fabricantes de consolas de juegos de primeras marcas eligen los APUs de AMD. Pero sin embargo, si una busca cual es el hardware recomendado para una estación de renderizado casera, el GPU parece ser lo que menos importa: http://blog.digitaltutors.com/building-a-home-render-farm-without-breaking-t... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :)
2016-09-14 14:50 GMT+03:00 Juan Erbes
El día 14 de septiembre de 2016, 5:22, Rafa Griman
escribió: Wenas :)
2016-09-14 6:47 GMT+03:00 Carlos Ayala
: 2016-09-13 16:51 GMT-05:00 Rafa Griman
: [...]
Obviamente, no todo son ventajas: - CUDA es propietario y NO es multiplataforma como OpenCL - CUDA es complicado - CUDA no es un estándar
[...]
haciendo un poco de off-topic. Justo escuche CUDA en un proyecto de investigación sobre Deep Learning acerca de música. =|
Es lo más "in"/"trending"/"you name it" del momento. Ahora todo el mundo hace Deep Learning (salvo el Ser Humano >;)
Se usa para todo y en todos los campos ... o eso quieren. Ya sabes: "cuando tienes un martillo en la mano ... todo son clavos". Con eso no quiero decir que Deep Learning no sea útil, sino que es la última moda y todo el mundo quiere (o dice) que usan/hacen Deep Learning.
Pero primero lo primero, lo escuché en este podcast [Software Engineering Daily - Music Deep Learning with Feynman Liang](http://softwareengineeringdaily.com/2016/09/02/music-deep-learning-with-feyn...) el repositorio de su proyecto [GIT - Bach Bot](https://github.com/feynmanliang/bachbot) y la web de su proyecto [Bach Bot Challenge](http://bachbot.com/#/?_k=smfllq)
En el repositorio incluyen la imagen docker para CUDA 7.5 =| Si lo están usando, algo de bueno habrá de tener.
Como decía más arriba, CUDA no es malo. Lo que ocurre es que tiene algunas cosas a tener en cuenta (ver más arriba). Lo cierto es que CUDA ofrece mejor rendimiento que OpenCL, OpenACC y/o las Intel Phi y eso es lo que ha llevado a la gente a CUDA. CUDA fue el primero en salir y tienes muchas herramientas d edesarrollo, muchas librerías, soporte para muchos lenguajes de desarrollo, ... En segundo lugar está Intel con sus Phi ya que tiene muchas herramientas, es compatible con x86 (en teoría basta con recompilar ... la realidad es que tienes que paralelizar el código si quieres realmente mejorar el rendimiento, igual que con CUDA), pero el rendimiento es menor. En último lugar está AMD porque carecía de las herramientas de desarrollo ... hasta ahora que ha sacado lo de GPUOPEN. Tengo los dedos cruzados esperando que ganen algo de terreno/mercado.
Hay mucho SW de terceros ya migrado a CUDA y ya sabes: da pereza cambiar/migrar/soportar OpenCL, es costoso económicamente mantener ambas opciones, si el rendimiento es peor ... el cliente no lo usará y es mala prensa, han firmado acuerdos que tendrán cláusulas determinadas, ... Por último, el cliente oye CUDA y NVIDIA en Internet, AMD casi no se oye ... ¿qué va a pedir el cliente? Lo que se oye.
Hoy en día, los que entendemos de hardware, y tambien los fabricantes de computadoras de escritorio, buscamos armar equipos con buen rendimiento, al mas bajo costo posible, terminamos eligiendo un APU de AMD.
Bueno, eso depende de la tarea que vaya a realizar el equipo. La FPU de Intel ofrece mejor rendimiento que la de AMD ;) Si el usuario no sabe de IT ni de HW, comprará lo que ve en las tiendas: Intel. Por desgracia lo que más se ve en las tiendas es la pegatina de "Intel Inside". Muy pocos usuarios dedican tiempo a buscar en Inet comparativas y benchmarks, eso lo hacemos los que nos dedicamos a esto y nos gusta. Si el usuario quiere jugar en el PC a juegos modernos ... yo no iría por una APU, iría a por una GPU en PCIe, que luego pueda ampliar si sale un nuevo juego con más requerimientos gráficos. Luego tienes usuarios que te piden opinión ... eso es otro tema. Ahí ya, lo que se deje convencer o lo que confíe en ti ;)
Pero parece ser, que quienes diseñan el software no se enteran de eso, y te quieren obligar a usar librerías y drivers de Nvidia, cuando en el hardware de tu computadora, no hay ni un solo chip de Nvidia.
Resuesta del fabricante: "Tienes dos opciones: comprar una NVIDIA ... o utilizar otro SW".
Habría que echar un vistazo a los tiempos en que las granjas de renderizado, sebasaban en procesadores AMD64: http://www.linuxjournal.com/article/6783
Pero con la diferencia en cantidad de nucleos entre GPU y CPU, obviamente, se han decantado por los GPU con el correr de los años.
Ojo !! El render (igual que otras aplicaciones/procesos) no siempre se ve beneficiado por correr en la GPU !!! Recordemos que las GPUs son procesadores vectoriales. En un render hay muchas cosas a tener en cuenta y muchos pases. Un pase se puede ver beneficiado y otro no o un frame se ve beneficiado y otro no. No es sencillo migrar a GPUs.
Pero una cosa es una granja de renderizado, y otra cosa es una computadora de escritorio. A la hora de que una empresa desarrolla software para computadoras de escritorio, debería tener en cuenta cual es el hardware que tienen esas computadoras de escritorio.
Para eso se basan en la demanda/market share. Por ahora, NVIDIA se "lleva el gato al agua" en PC. Las consolas son otra historia (otro mercado).
No por nada, los fabricantes de consolas de juegos de primeras marcas eligen los APUs de AMD.
Eso es cierto, pero las consolas NO son PCs. Son otro mercado y así lo consideran tanto AMD como NVIDIA. Y sí, AMD tiene mayor market share en consolas.
Pero sin embargo, si una busca cual es el hardware recomendado para una estación de renderizado casera, el GPU parece ser lo que menos importa: http://blog.digitaltutors.com/building-a-home-render-farm-without-breaking-t...
Cosas varias ...: - ese post es algo antiguo (2 años). Ese tiempo en IT es una eternidad. - ¿el motor de render que utilizo saca provecho de las GPUs? Si la respuesta es NO ... pues a tirar de CPUs. - ¿sé cuándo me viene bien usar la GPU? O, dicho de otra manera, ¿el software que uso lo hace "automágicamente"? Si el usuario tiene que andar configurando, instalando librerías, ... mal vamos. - ¿puedo renderizar y visualizar al mismo tiempo? Hay modelos de GPU que no lo permiten ... - ¿voy a sacarle todo el provecho a la GPU? O bien, ¿es una inversión o un gasto? - ¿me sale mejor comprar 4 PCs sin GPU? Si tengo un PC con una GPU renderizando ... lo tengo "secuestrado" durante el render. Si tengo 4 PCs, mientras 3 renderizan el 4º lo uso para seguir trabajando - hay (o había) motores de render/aplicaciones que hacen/hacían uso de la GPU para previsualización en tiempo real, pero no hacen/hacían render final - ... Respecto al HW recomendado ... depende de todas las preguntas anteriores y otras como: ¿qué recomienda el fabricante de SW que estoy utilizando? Y otras tantas. Yo, personalmente, preferiría que la gente utilizase AMD (CPU, GPU y/o APU), pero hay veces que no es la mejor solución ... y no voy a forzar a nadie a usar algo que no le conviene ;) MHO ... BTW, no se ha mencionado nada de OpenPOWER y los POWER9 ... auténticas bestias ... y ARM viene dando guerra con cosas interesantes (pena que AMD ha paralizado sus proyectos basados en ARM hasta que salgan Polaris y Zen). ¿FPGAs? Tienen su utilidad también ... y dan mucho mejor rendimiento que las GPUs a mucho menor precio en ciertas áreas, pero hay que (saber) programarlas ;) Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 14 de septiembre de 2016, 10:14, Rafa Griman
Hola :)
Pero sin embargo, si una busca cual es el hardware recomendado para una estación de renderizado casera, el GPU parece ser lo que menos importa: http://blog.digitaltutors.com/building-a-home-render-farm-without-breaking-t...
Cosas varias ...: - ese post es algo antiguo (2 años). Ese tiempo en IT es una eternidad. - ¿el motor de render que utilizo saca provecho de las GPUs? Si la respuesta es NO ... pues a tirar de CPUs. - ¿sé cuándo me viene bien usar la GPU? O, dicho de otra manera, ¿el software que uso lo hace "automágicamente"? Si el usuario tiene que andar configurando, instalando librerías, ... mal vamos. - ¿puedo renderizar y visualizar al mismo tiempo? Hay modelos de GPU que no lo permiten ... - ¿voy a sacarle todo el provecho a la GPU? O bien, ¿es una inversión o un gasto? - ¿me sale mejor comprar 4 PCs sin GPU? Si tengo un PC con una GPU renderizando ... lo tengo "secuestrado" durante el render. Si tengo 4 PCs, mientras 3 renderizan el 4º lo uso para seguir trabajando - hay (o había) motores de render/aplicaciones que hacen/hacían uso de la GPU para previsualización en tiempo real, pero no hacen/hacían render final - ...
Respecto al HW recomendado ... depende de todas las preguntas anteriores y otras como: ¿qué recomienda el fabricante de SW que estoy utilizando? Y otras tantas.
Yo, personalmente, preferiría que la gente utilizase AMD (CPU, GPU y/o APU), pero hay veces que no es la mejor solución ... y no voy a forzar a nadie a usar algo que no le conviene ;) MHO ...
Con respecto al software de renderizado, no está muy claro que software utiliza, por mas que diga "Operating System and Software/Render Management" Aparecen 2 benchmark con Cinebench, de CPU y de OpenGL: http://i2.wp.com/blog.digitaltutors.com/wp-content/uploads/2014/04/6-openGL_... http://i2.wp.com/blog.digitaltutors.com/wp-content/uploads/2014/04/7-cpu_tes... Tal como dices "ese post es algo antiguo (2 años). Ese tiempo en IT es una eternidad." Pero cuando se busca rendimiento a bajo precio, un producto de hace 2 años, tiene un precio mas asequible, y "todavía no es viejo". A Algunos les gusta estar "en la cresta de la ola", y así tambien "se tienen que comer algunos sapos", como el fiasco de la Galaxy Note 7, que se les explota la batería. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (5)
-
Carlos Ayala
-
Carlos E. R.
-
Juan Erbes
-
Pinguino Patagonico
-
Rafa Griman