Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'AMD'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 23 resultados

  1. Comenzamos el año con una noticia perturbadora dentro del mundo tecnológico y de la que son protagonistas Meltdown y Spectre, dos vulneravilidades graves y que afectan a millones de dispositivos. La prensa sensacionalista no se ha hecho de rogar y están, dicho de manera simple y llana, tirando mierda como si no hubiera mañana, con grandes muestras de fanatismo por cierta marca o su rival y nubes y claros por la zona de levante. Si hay algo que se puede sacar en claro es que estos medios se especializan en pintar las cosas de tonos de amarillo y rosa y poco más. ¿Qué ocurre realmente? Pues vamos a intentar indagar un poco a ver si no enteramos. Y dado que Pablo Isua ha hecho un análisis bastante cortito y comprensible, a la par que completo, en su cuenta de Twiter, vamos a partir de ahí En primer lugar debemos saber que hablamos de un problema de seguridad a nivel de hardware que se remonta dos décadas o más, por lo que podemos decir con casi total certeza que todos nuestros dispositivos serán vulnerables. Tanto Spectre como Meltdown se aprovechan de ciertas características de los microprocesadores conocidas como ejecución especulativa y ejecución fuera de orden, técnicas muy antiguas y que, dicho de manera sencilla, buscan "predecir" la instrucción a ejecutar a continuación por el procesador para aprovechar los tiempos en que este está ocioso para adelantar trabajo y aprovechar mejor los recursos en lugar de ejecutar instrucción tras instrucción de manera secuencial. El rastro de este proceso es lo que hace posibles las dos vulnerabilidades antes mencionadas: Meltdow permitiría acceder, desde un proceso con bajos privilegios, a la zona reservada en el mismo para el kernel, permitiendo tener acceso directo a la memoria física y acceder a información confidencial. Es una vulnerabilidad que es relativamente fácil de explotar y está es la razón por la que ha cundido el pánico. La solución planteada en este momento es radical, a la espera de mejores alternativas, y es deshabilitar todo lo relacionado con estas características de la CPU. Resultando en la tan mencionada y polémica pérdida de rendimiento de entre un 5 y un 30% de la que tanto eco se hacen los medios. En el caso de Linux hemos visto como el parche se centra en proveer un aislamiento de la tabla de páginas del núcleo (Page Table Isolation o PTI) para procesadores de arquitectura x86, que ha aplicado de manera inmediata en versiones activas y en desarrollo del kernel. Esta vulnerabilidad parece afectar EXCLUSIVAMENTE a procesadores Intel (a excepción de los Itanium y Atom), aunque con el paso de los días y según avance la investigación al respecto, podremos estar más seguros. Spectre, por su parte, rompe la barrera entre aplicaciones, permitiendo manipular o "engañar" al kernel para que revelen información sensible almacenada en zonas de memoria que controle el proceso relacionado con dicha aplicación. Este malware es más complejo a la hora de explotarlo y requeriría que el malware estuviera presente y ejecutándose en el mismo equipo a vulnerar. Esta vulnerabilidad es de carácter general, basada en una gama más amplia de de características de ejecución especulativa. Esto afecta a cualquier procesador, tanto Intel como AMD e incluso procesadores de arquitectura ARM son vulnerables a Spectre y, de momento, no existe ninguna solución posible para este problema. Repercusiones Más allá de tomar nosotros mismos la decisión radical de iniciar nuestro equipo con la opción pti=off (haciendo así caso omiso del parche que corrige la vulnerabilidad), como usuarios no podemos hacer gran cosa al respecto hasta que los fabricantes y desarrolladores no den con una solución al problema. No obstante, como usuarios tampoco nos veremos afectados en prácticamente ningún aspecto por los daños colaterales que suponen las soluciones actuales para estas vulnerabilidades. En un escenario donde se haga uso de aplicaciones que hagan múltiples cambios al modo kernel, que son todas, o al menos la inmensa mayoría de aplicaciones que utilizamos a diario, no habrá ninguna penalización de rendimiento. Donde sí resultará un drama será en centros de datos, servicios en la nube y similares, tanto en la parte que respecta a la seguridad, como en lo que se refiere a pérdida de rendimiento. Las primeras pruebas que se han hecho públicas en diferentes portales así lo avalan. No hay diferencia apreciable de rendimiento a la hora de jugar, reproducir contenido multimedia, trabajar con documentos y otras aplicaciones de uso común, así que de momento lo que debemos hacer es mantener nuestros equipos actualizados y seguir pendientes de nueva información acerca de este gigantesco problema con el que los fabricantes están obligados a lidiar, de una manera u otra, a partir de ahora, aunque desde el CERT (Computer emergency response team) ya han asegurado que la única solución a la vista es, dado que se trata de un problema que radica en el hardware, sustituir todos los microprocesadores afectados por nuevos componentes sin este problema de diseño. https://meltdownattack.com/
  2. Hace unos días fuimos testigos de una noticia que jamás habríamos imaginado ver y es que Intel y AMD decidieron enterrar el hacha de guerra y cooperar para crear, de manera conjunta, un procesador con GOU Radeon integrada, pensado no sólo para ser el más potente del mercado hasta el moemnto, sino para acabar con la hegemonía de Nvidia y sus Tesla en los referente a hardware gráfico para equipos integrados y portátiles. El mencionado procesador combinará las especificaciones de un chip Core H de la octava generación de Intel con una GPU Radeon de AMD con memoria HMB2 y diseñada exclusivamente para este cometido y se montará en tres chips separados. Pero es que Intel no ha parado aquí y acaba de anunciar su intención de fabricar tarjetas gráficas dedicadas de alto rendimiento. Hasta tal punto llega su ambición en este sentido que ya han fichado algunos pesos pesados del sector, como Raja Koduri, el que hasta ahora era el máximo responsable de la división Radeon dentro de AMD, para que lidere el "Core and Visual Computing Group" de Intel, que tiene como objetivo expandir las soluciones gráficas de Intel. Aunque no se ha desvelado una fecha concreta, se espera que los procesadores Intel con GPU AMD llegarán al mercado durante el primer trimestre de 2018, no así las gráficas dedicadas que se rumorea llegarán algo más tarde. La entrada de un tercer competidor en el mercado de las tarjetas gráficas supone una grata noticia, aportando no sólo una mayor variedad de hardware a elegir, sino fomentando la competencia entre las compañías para ganarse el favor de estos ofreciendo precios más bajos y mejoras tecnológicas más atractivas y continuas, acabando con el duopolio que han mantenido Nvidia y AMD desde hace tanto tiempo y que, ahora mismo, con la ausencia de productos AMD para las gamas más altas, ha dejado a Nvidia en una posición demasiado cómoda y a los pobres consumidores unos precios desorbitados. Aún es pronto para pensar en controladores, compatibilidad y hardware, pero cabe esperar que se mantenga la tónica actual y que el nuevo hardware ofrezca un buen soporte para todas las plataformas, incluyendo, como no, GNU/Linux. Pero como ya he dicho, de momento lo único que podemos hacer es esperar a ver cómo resulta esta alianza entre los enemigos más acérrimos del mundo de los procesadores y si de verdad Intel será capaz de quitarle el galardón de tarjeta gráfica más potente del mundo a una Nvidia. https://newsroom.intel.com/news-releases/raja-koduri-joins-intel/
  3. Bueno pues me compre pc nueva es un Asus y con procesador Beema A4-6210 trae 4GB Ram, una grafica integrada en el procesador APU ATI radeon r3 (no es de lo mejor) y un disco de Tera. Bueno la cosa es que quando lo inicie inicio la instalacion del windows 10 , cosa la cual me duro en el 1 dia ya que ya le he metido Lubuntu 14.04 64bits (Yupi ya tengo uno 64). Mejor de lo esperado todo me funciona muy bien hasta los drivers privativos eso si en 16.04 por lo visto ya hay que ir con los libres, he llegado a probar Lubuntu 16.04 y lo comprobe. Bueno pues la parte a la que tenia miedo la Bios y el arranque de Linux no me dio ni un problema es simple en estos Asus instalar otros SO no hay muchos problemas. Un video de uno igual solo que el mio es la version K20DA -
  4. Dónde puedo buscar información sobre qué placa de video elegir para comprar? Por lo que sé uno puede usar drivers libres o propietarios, y cada uno tiene nombres: Intel: Creo que solamente hay drivers libresAMD: Libre: radeon Propietario: fglrx (Catalyst) Nvidia: Libre: nouveau Propietario: nvidia? Cómo hacen ustedes para elegir GPU? Por lo que leí nvidia tiene los mejores drivers propietarios pero los peores drivers libres. Dónde puedo obtener información actualizada sobre como viene la cosa? O una lista de todas las GPU soportadas para cada driver Varía mucho el rendimiento de los drivers al comparar distitas GPU del mismo fabricante? O se puede decir que por ejemplo todos los GPU nvidia tienen buenos drivers sin excepciones?
  5. Muy buenas a todos!!! Hace unas semanas se me cruzó el cable y decidí cambiar mi GeForce GTX660 por una Radeon RX470. Sabía que los drivers libres iban por buen camino y que también estaba el driver privativo AMDGPU-PRO, pero no tenía ni idea de lo que me iba a encontrar en mi equipo de sobremesa (sí, le he dicho adiós a Debian y he instalado Ubuntu, sé que iré al infierno). Para empezar debo decir que Ubuntu 16.04 no trae soporte de serie para Polaris10/11, y que la aceleración que nos dan los drivers Mesa 11.2 que trae es por software, vía llvm. Así que nada de jugar por ahora. Usando el driver AMDGPU-PRO tenemos aceleración por hardware, pero el rendimiento en los juegos deja bastante que desear (en algunos incluso era peor que con la GTX660). Así que vamos a conseguir que esto funcione. Lo primero es activar las actualizaciones "proposed". La manera más sencilla es ir a Configuración del Sistema -> Software y actualizaciones -> Opciones de desarrollo. Ahí marcamos la opción de "Actualizaciones no publicadas". Cerramos y se actualizarán los repositorios. Para actualizar los paquetes pues ya les dejo a su elección, ya sea de manera gráfica o desde la terminal. Lo que sí debemos asegurarnos es que se nos haya actualizado el kernel a la versión 4.4.0-38. Este paso no sé si es muy relevante, pero aquí lo dejo. Se trata de actualizar nuestro paquete linux-firmware a la versión más reciente. Para ello vamos a https://launchpad.net/ubuntu/+source/linux-firmware y nos descargamos la última versión para Yakkety (16.10). Será un archivo .deb que podemos instalar con doble click o desde la terminal con dpkg. Y por último, añadir el PPA de oibaf para poder actualizar nuestros drivers Mesa a la versión 12.1. Para ello nos digirmos a https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers y seguimos las instrucciones, no tiene pérdida. Una vez actualizados todos los paquetes y reiniciado el sistema, en detalles del sistema nos debería salir algo parecido a esto: Gallium 0.4 on AMD POLARIS10 (DRM 3.2.0 / 4.4.0-38-generic, LLVM 3.9.0) Y listo, ya podemos jugar sin problemas!!!. Hasta el sonido por HDMI funciona. Cualquier duda, sugerencia respecto a la redacción del post o lo que sea, aquí estoy. Un saludo!!! Re-EDITADO: Kernel 4.7 - 64bits para usar con gráficas Polaris10/11 https://drive.google.com/drive/folders/0B8cUeAsvryrrUHZXY3J5enBwa2c?usp=sharing
  6. Si el último anuncio sobre la 1080 GTX nos puso los dientes largos por su potencia desmesurada a un precio, "relativamente modesto", AMD, por su parte, ha decidido que durante esta generación competirá en el extremo opuesto, con tarjetas gráficas de gama media-baja, a un precio muy asequible, como gancho para afianzarse este nicho del mercado. La primera de sus tarjetas de arquitectura Polaris es la RX 480, una minibestia, que correspondería a la serie más baja dentro de la gama gamer entusiasta (equiparándolo a la nomenclatura de Nvidia, que la mayoría entendemos mejor, sería la competidora de la 1060 GTX), que saldrá al mercado a un precio "rompedor" de 200$. No obstante, como ya ha ocurrido con las gráficas de la competencia que ya están disponibles, debemos recordar que al precio oficial hay que sumarle multitud de impuestos, además de lo que sume cada montador, al margen que hay dos modelos, el de 4GB y el de 8GB y estos 200$ se refieren al más básico. Aún así, con ese precio de partida podemos estar hablando de unos 280€ por una tarjeta gráfica que supone un gran salto en cuanto a tecnología y rendimiento, por no mencionar la tan de moda realidad virtual, que parece que será el punto fuerte de esta generación. Para nosotros, es un poco menos excitante esta noticia, porque si bien AMD planea comenzar el despliegue de Polaris a principios de Julio, para GNU/Linux no existen controladores gráficos ni tampoco se los espera, al menos no a corto plazo, hasta que AMDGPU empiece a despegar. Eso sí, es muy probable que, para variar, sí que lleguen a ser funcionales poco tiempo después o el mismo día del lanzamiento, a través de los AMDGPU-PRO, pero con el pobre rendimiento al que nos tienen acostumbrados. En definitiva, aunque esto significa que no tienen intención de competir en la gama alta, en la que Nvidia tendrá la exclusividad y, por tanto, podrá poner los precios que le dé la gana, esta guerra encarnizada en la parte baja de la tabla, donde hay menos entusiastas y muchos más usuarios de a pie, puede ser muy beneficiosa para los consumidores, obligando a Nvidia a tener que hacer rebajas si quieren competir y a AMD a poner toda la carne en el asador, si quieren estar a la altura.
  7. Siguiendo con el plan, AMD ha liberado la primera preview de la versión híbrida de su controlador AMDGPU. Como ya sabíamos, esta nueva línea de controladores abiertos se centran en dar soporte únicamente a las últimas gráficas lanzadas al mercado, en este caso las GPU Tonga y Fiji. Esta versión incluye las implementaciones de Catalyst para OpenCL, OpenGL y la versión preliminar de Vulkan. Las gráficas que pueden utilizar esta línea de controladores son: AMD Radeon R9 Fury X AMD Radeon R9 380X AMD Radeon R9 Fury AMD Radeon R9 380 AMD Radeon R9 Nano AMD Radeon R9 285 AMD Radeon R9 M395X Y según nos informan incluiría soporte para las siguientes APIs ​OpenGL 4.5 GLX 1.4 OpenCL 1.2 Vulkan 1.0 VDPAU http://support.amd.com/en-us/kb-arti...ase-Notes.aspx http://gpuopen.com/gaming-product/vulkan/
  8. Desde hace ya algunos años y tras la compra por parte de Nvidia de Ageia, hemos visto en el mundo de los videojuegos tecnologías llegaban para mejorar la experiencia de los jugadores, a la vez que ponían en apuros a los desarrolladores por sus peculiaridades y carácter exclusivo. Quien más ha invertido en este tipo de tecnologías ha sido indiscutiblemente Nvidia, que empezó con Physx y ha terminado creando todo un ecosistema de efectos visuales bajo el nombre de Gameworks. Si esto bien ofrece un mundo de posibilidades a los desarrolladores a la hora de llevar más allá sus títulos, su carácter cerrado y exclusivo suponen una gran traba para todos. Durante el GDC de 2015 hizo un movimiento bastante sorprendente liberando el código de Physx, así como su kit de desarrollo. Siguiendo esta misma tendencia, pero yendo mucho más allá, AMD recientemente quiso "contraatacar" con GPUOpen, una iniciativa que busca ofrecer algo similar a la plataforma Gameworks de Nvidia, pero de carácter abierto. En la misma línea, probablemente influenciados por el lanzamiento de GPUOpen y, para no romper con la tradición, también durante el GDC, Nvidia ha comenzado a liberar los componentes Individuales de Gameworks, empezandoando porNvidia Volumetric Lighting y FaceWorks, a los que acompañan documentación y ejemplos. Al mismo tiempo también han asegurado que HairWorks, HBAO+ y NVIDIA WaveWorks seguirán el mismo camino muy pronto. Es esperanzador ver como el panorama general va cambiando y Nvidia, conocida antaño por sus políticas extremadamente cerradas y exclusivas, empieza a abrirse y a apostar por un nuevo modelo de negocio y AMD parece que también quiere abandonar sus costumbres "pasotas" e indiferentes para ponerse las pilas de una vez. https://developer.nvidia.com/content/introducing-nvidia-gameworks http://gpuopen.com/
  9. Todos estamos que nos subimos por las paredes con la inminente llegada de la nueva API gráfica del grupo Khronos, Vulkan (¿O acaso soy sólo yo? ). Con cierto retraso, como es habitual, y la promesa de su inminente llegada, Vulkan se está haciendo de rogar más de la cuenta y, aunque cada vez son más los indicios de su lanzamiento final, seguimos sin tener una fecha concreta. Hoy tenemos una prueba más de que Vulkan está a la vuelta de la esquina. Graham Sellers (AMD) y John Kessenich (Google) han publicado la guía oficial de programación de Vulkan, con una portada en una línea muy similar al famoso libro rojo de OpenGL, 900 páginas de contenido y que ya puede reservarse en Amazon. La fecha estimada para distribución, según la plataforma, es Agosto de este año, así que al menos sabemos que Vulkan llegará antes. ¿Cuando? Los rumores vuelven a circular y, dado que la GDC de este año está plagada de conferencias sobre Vulkan y demostraciones llevadas a cabo por la mayoría de las compañías implicadas, la semana del 14 al 18 de Marzo parece ser, si no la fecha definitiva de lanzamiento, el escenario más propicio para dar a conocer al mundo el nuevo estándar abierto que guiará a la industria del entretenimiento en el futuro próximo. http://www.amazon.com/Vulkan-Programming-Guide-Official-Learning/dp/0134464540
  10. XCOM 2, secuela del afamado título de estrategia por turnos XCOM: Enemy Unknown, nos lleva 20 años después de que la humanidad perdiera la guerra contra los invasores alienígenas. Tras años escondido en la sombra, XCOM ha resurgido de sus cenizas y tratará de recuperar el planeta en el último intento que tiene la humanidad de poder vencer. Uno de los grandes títulos de este año, de los más esperados y prometedores, que ha cumplido con su promesa de llegar a todas las plataformas desde el primer día, gracias al buen trabajo, una vez más, de Feral Interactive. Siempre hay algún pero, tampoco vamos a engañarnos, y como ya expliqué en su día más profundamente, a día de hoy los títulos que llegan a GNU/Linux, aunque cada vez avanzamos más, no son realmente nativos sino ports hechos a posteriori, con todo lo que eso implica y no podemos esperar algo perfecto en cuanto a rendimiento sino un producto algo menos pulido que para el resto de plataformas. En ese sentido, este XCOM2 exige un hardware un poco más potente para poder jugarlo en GNU/Linux, pero según los primeros que lo han podido probar, se nota que la mano de Feral ha estado presente afinando el título al máximo para que podamos disfrutarlo como es debido. La invasión ha llegado a Europa y Asia antes que al resto del planeta, así que no será hasta mañana que los portales anglosajones del otro lado del charco se hagan eco del resurgir de XCOM y podamos tener una muestra más grande de revisiones y opiniones acerca del título y de su desempeño en la plataforma del Ñu y el Pingüino Como era de esperar, AMD se ha quedado de nuevo al margen y, aunque Feral lo ha intentado, sin la colaboración de los de Sunnyvale poco se ha podido hacer para que el título corra con GPUs de esta compañía, así que tenemos de nuevo el aviso de "Hardware AMD/Intel no soportado". En cuanto a las tarjetas gráficas integradas de Intel, dado su escaso potencial y la falta de soporte para muchas extensiones OpenGL recientes, es del todo lógico que no se recomiende su uso a la hora de correr este titulo, pero las tarjetas gráficas de AMD vuelven a dar la nota discordante. Michael Larabell, de Phoronix, ya ha hecho algunas pruebas preliminares y la cosa va más allá del pobre rendimiento, errores gráficos y demás fallos a los que estamos acostumbrados, esta vez el juego directamente no arranca, tanto con los controladores privativos Catalyst/Crimson como con las alternativas libres. Feral, al igual que otros estudios ya se han quejado en otras ocasiones por la falta de compromiso de la compañía para con los desarrolladores, quienes al intentar solventar los problemas que se les presentan por culpa del precario estado de los controladores gráficos contactando directamente con AMD, no han recibido más que excusas y promesas vagas y/o han sido completamente ignorados. Sabemos que AMDGPU sigue evolucionando, la promesa del cambio sigue en el aire y todo lo que escuchamos acerca del futuro de AMD suena muy prometedor, pero cuando bajamos al mundo real nos encontramos, un año más, con la misma situación de siempre, rendimiento pobre o nulo y un soporte más que cuestionable por parte de una empresa que parece que empieza a cambiar, pero que sigue muy por detrás del resto de alternativas que tenemos los linuxeros. Vulkan, que se presenta como la vuelta de tuerca definitiva para disfrutar de aplicaciones 3D en cualquier plataforma, está casi entre nosotros y no se ve ningún avance que nos indique que AMD llegue a tiempo para aprovechar los avances que ésta ofrece. Por ahora no me aventuro a decir nada acerca de lo que nos espera en el futuro con AMD, especialmente después de tantos años de decepciones. Esta vez quiero creer que por fin van a conseguirlo o al menos han dado por fin los primeros pasos en la dirección correcta. Lo que sí tengo claro es que aún falta mucho para que lo que tienen pensado ofrecernos llegue a materializarse.
  11. Como en otras muchas ocasiones, los movimientos registrados por SteamDB en las últimas semanas apuntaban, aunque no de manera oficial, a la inminente llegada del último título de la frnaquicia Alien, que fue lanzado a finales del año pasado y que, al contrario que su deshonroso predecesor, ha sido aclamado por críticos y jugadores por su experiencia de juego y su terrorífica atmósfera. En un extraño giro de los acontecimientos y ante la sorpresa de todos, ha sido AMD quien, en un desliz (y un hecho sin precedentes al lanzar controladores que de verdad corrigen errores), ha confirmado el rumor, al exponer claramente en el changelog de su último controlador Catalyst 15.9 para GNU/Linux, correcciones y mejoras para éste título en concreto, aunque posteriormente han corrido a eliminarlo. Todo apunta a que Feral, una vez más, es el que se encargará de obrar la magia, aunque eso sí, lo hacen con su estilo característico, dejándonos miguitas de pan y acertijos para que nos estrujemos el cerebro averiguando de qué juego se trata. Como comentaba antes, es quizá la primera vez que se anuncian controladores de AMD que llegan a tiempo y se preocupan por la experiencia de juego de los linuxeros. Tendremos que darles un voto de confianza a ver si esta vez es verdad que han hecho su trabajo.
  12. Hemos pasado meses oyendo hablar sobre Vulkan a través de las conferencias de numerosos fabricantes y desarolladores, a excepción de AMD que había permanecido en silencio, hasta ahora. La XDC2015 de Toronto ha sido el escenario propicio para que los californianos nos pongan al día sobre sus planes de futuro acerca de Vulkan y su nuevo concepto de controladores AMDGPU. Según nos cuentan están trabajando en optimizar el planificador GPU, nuevos componentes para el administrador de energía (para gráficas Volcanic Island) y de pantalla, así como el soporte para nuevo Hardware. Otro de los objetivos es que las partes relacionadas con Vulkan y OpenCL, que al parecer ya existen y utilizan DRI3, pasen a ser Open Source, aunque esto último no se hará de entrada sino de forma paulatina. A pesar de que se esperan numerosas e interesantes actualizaciones para los controladores AMDGPU, apenas hay cambios en cuanto a plan original que ya conocíamos en lo referente al Hardware. Las series actuales y antiguas de AMD no serán soportadas, sólo a partir de la arquitectura Tonga y APUS Carrizo o posteriores. Aunque tras conocer algunos detalles más sobre los planes de futuro de AMD, nos vamos con más dudas que respuestas, es interesante ver este cambio de rumbo hacia una estrategia más colaborativa y abierta entre la comunidad de desarrolladores libres y AMD. Esperemos que éste sea ya, por fin, el punto de inflexión que nos haga pasar del paupérrimo soporte ofrecido hasta ahora para los usuarios linuxeros a poder tener los merecidos controladores eficientes y capaces que llevamos tantos años esperando. http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
  13. AMD tiene interesantes planes de futuro para GNU/Linux, algo que tras muchos años de tenernos técnicamente como usuarios de segunda es de agradecer Alex Deucher ha sido el encargado de sorprendernos en el XDC 2104 anunciando una nueva estrategia de unificación Open-Source para sus controladores, que para entendernos es una estrategia de unificación de esfuerzos entre los desarrollos libre y privativo, aunque eso sí, con algunos matices. Este nuevo controlador para LInux, por ahora denominado "amdgpu" es un cambio de estrategia que planea unificar esfuerzos y consolidar las ventajas que ofrecían, hasta ahora por separado, los controladores actuales. Las tecnologías TTM, DRM, GBM, DRI, y GLAMOR continuarán siendo utilizadas por los controladores libres Radeon y ahora también serán aprovechadas por los Catalyst, los cuales, y aquí es donde viene el primer matiz, NO serán liberados en modo alguno. Este punto es algo más confuso ya que nos encotramos ante tres facetas o niveles, All Open, Non-Pro y Pro. El nivel intermedio sería en el que entrarían en juego los controladores privativos para aplicaciones OpenGL, OpenCL y multimedia y un nivel más allá, es decir, el Pro, ofrecería además algunos addons Firepro Para no liarnos demasiado, ya que los esquemas tampoco son demasiado claros, digamos que hablamos de un nuevo controlador que tendrá partes que corresponden al actual controlador Radeon y partes que forman parte de los controladores privativos Catalyst trabajando en sintonía, o al menos esa parece ser la idea. El actual xf86-video-ati será relevado por el nuevo xf86-video-amdgpu DDX, que tratará de lidiar con todo ese hardware que ofrecerá AMD y como están viendo en las imágenes, también nos recuerdan una y otra vez que aunque se aprovechará el código de los controladores libres, no piensan liberar nada de sus equivalentes privativos. Esto plantea también una serie de retos tanto en lo referente a la documentación como en lo que respecta a los desarrolladores que trabajan con los controladores privativos (los que quedan) que necesitarán formación extra para lidiar con la tarea que se les viene encima Pero no por ello dejan de hacer hincapié en lo que aportarán los Blobs a la mezcla Otro de los matices que nos plantea esta nueva estrategia es que está planteada única y exclusivamente pensando en el hardware que veremos en el futuro y no para las generaciones actuales o pasadas de AMD. El trabajo ha comenzado con las Sea Island a modo de prototipo pero no será hasta las futuras Pirate Island las que veremos gráficas con soporte amdgpu Aún con todas las cosas que no sabemos y que quedan en el aire y todos esos "matices" que hacen que desluzca un poco, la estrategia no suena nada mal. Es sin duda un paso adelante que esperábamos desde hace mucho tiempo, quizá no de esta manera, pero es un inicio para cambiar una situación que se prolonga ya demasiado y, quien sabe, quizá la clave que nos dará por fin controladores de calidad para poder disfrutar de nuestras gráficas rojas en GNU/Linux http://www.x.org/wiki/Events/XDC2014/XDC2014DeucherAMD/amdgpu_xdc_2014_v3.pdf
  14. Hola, tras haber comprado un monitor de 24" y 1090p y conectarlo por hdmi a una grafica AMD me encuentro con que no se utiliza todo el monitor, la resolucion esta correcta pero se ve el escritorio rodeado por un marco negro. La solucion a este problema que he encontrado y me ha funcionado es esta orden aticonfig --set-pcs-u32=MCIL,DigitalHDTVDefaultUnderscan,0 La solucion la obtuve de la wiki de Arch sobre Catalyst
  15. Buenas, como ya sabréis por el chat hoy se a muerto algo de mi ordenador xD, y quería saber que creeis que sea. Os explico lo que hace: Al iniciarse en el monitor se ve pantalla negra, pero no me arrancar las letras de la bios ni nada, y resulta que me comenzo a hacer un ruido en el ventilador del microprocesador. Y todo esto por iniciar un triste juego... se me apago de repente y ahora esto.
  16. HSA (Heterogeneous System Architecture) es una tecnología de Amd que mejora la respuesta de la GPU en conjunción con la CPU, compartiendo recursos de manera más eficiente. Esta característica, propia de las tarjetas Radeon con chip Sea Islands, pretense ser no sólo beneficiosa para el hardware de AMD, sino servir para todo el hardware compatible con HSA. El código está diseñado para soportar múltiples CPUs conectadas con sus respectivas GPUs, aunque la implementación actual esta enfocada en soporta una única APU Kaveri/Berlin APU, y trabajar a través del controlador gráfico Radeon (kgd). Las GPUs AMD GPUs diseñadas para hacer uso de HSA (Sea Islands) comparten algunas funcionalidades de hardware entre el cómputo HSA y el cómputo regular gfx(memoria, interrupciones, registros), mientras otras funcionalidades han sido añadidas específicamente para el cómputo HSA. Todo el hardware compartido es administrado por el controlador gráfico radeon, y una interfaz entre kfd y kgd permite a kfd hacer uso de los recursos compartidos, mientras que las funcionalidades específicas de HSA son manejadas directamente por kfd mediante el suministro paquetes en una cola de comandos específica de HSA (HIQ). http://lkml.iu.edu/hypermail/linux/kernel/1407.1/02923.html http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/
  17. Buenas, como saben se me quemo el pc por un fallo en la red electrica. Me voy a comprar una nvidia!!!! SIIIII por fin!!!! xDDD necesito ayudita para ver cual pillar compro de esta tienda que esta en mi pueblo. http://www.appinformatica.com/tarjetas-graficas.htm
  18. Actualizo con una nueva versión de los drivers de AMD. Ya van por la versión 14.3 Beta v1 Nueva versión con solamente 3 bugs corregidos. Resolved Issues: [394848] - Xorg crashed playing AVI video file in VLC player or Parole player [394705] - "Nexuiz - Demo3" Ubuntu performance lower than Redhat [394704] - "Nexuiz - Demo3" Linux performance lower than Windows Errores pendientes de corregir Link descarga de los nuevos drivers http://www2.ati.com/drivers/beta/Linux_AMD_Catalyst_14.3_Beta_V1.0_B22_March12_2014.zip FIN EDIT Ya tenemos disponibles para descargar la nueva versión de los drivers de AMD. Esta vez parece que se han dedicado a corregir muchos problemas (bugs) y a dar soporte al kernel 3.13! Destacar RHEL 6.5 production support openSUSE 13.1 production support Ubuntu 13.10 production support Xserver 1.15 support Kernel 3.13 support Resolved Issues: [386897] : System hang on resume from S4 with OpenGL screen saver running [387678] : Backtrace occurs when kill X [387664] : Failed to start X without kernel module loaded [378620] : OpenCL test failure in CrossFire Mode [386945] : piglit test "spec/ARB_copy_buffer/overlap" failed [386710] : piglit test "spec/ARB_draw_buffers_blend" failed [386818] : piglit test "spec/OpenGL 2.0/depth-tex-modes-glsl" failed [386941] : piglit test "spec/ARB_blend_func_extended" failed [386903] : piglit test "spec/OpenGL 3.0/gl-3.0-required-sized-texture-formats" failed [386840] : Viewport goes blank when mouse cursor leaves when run Houdini on Ubuntu [387596] : piglit test "spec/ARB_framebuffer_object (fbo-scissor-blit)" failed [389174] : Failed to get fan speed on Bonaire card [388110] : Intermittent flashing problem when running at 2560x1600 [372656] : Crash when resizing Konsole [388325] : Brightness cannot be adjusted on Ubuntu 12.04 LTS [388330] : piglit test "spec/ARB_framebuffer_object (fbo-blit-stretch)" failed [385457] : Blue/white screen after using Google-chrome to run fishietank [388500] : piglit test "spec/EXT_texture_integer" failed [388802] : piglit test "spec/ARB_map_buffer_alignment" failed [386396] : piglit test "spec/ARB_depth_buffer_float/fbo-depthstencil-drawpixels" failed [389431] : Screens are distorted when connecting an external monitor on some Haswell platforms [389530] : Blank screen/crash observed while running unigine heaven benchmark in windowed mode [387124] : OpenCL performance drop observed on Hawaii compared to Tahiti XT [386940] : piglit test "spec/EXT_texture_sRGB" failed [392137] : [SteamOS] Failed to return to desktop from steam. [392015] : [SteamOS] Screen is locked when changing user. [392014] : [SteamOS] Failed to login Steam sometimes [391231] : Blank screen observed while running steam games with Big picture Open Issues: [390964] : Stuttering and poor performance after playing an OpenGL game for a several minutes on Ubuntu [393377] : Terminal panel stops refreshing until there is movement from mouse cursor [392546] : System hang observed while hotpluging the stereo display [388835] : Corruption and system hang observed while running Sanctuary BM with TFD enable [392552] : Enabling Overlay: StartX , the screen shows corruption Edit para poner link de descarga y fuente: http://support.amd.com/en-us/kb-articles/Pages/Latest-LINUX-Beta-Driver.aspx
  19. Tras el retraso, Metro: Last Light, el título de 4A Games y secuela de famoso Metro 2033 ha llegado de manera nativa a GNU/Linux y ya puede adquirirse a través de Steam. Sin embargo, tras la alegría inicial he querido indagar más a fondo para averiguar que tan bueno es, no el juego, sino este port que han hecho a posteriori. Dado que no poseo este título he de "fiarme" de los comentarios, capturas y apreciaciones de gente que sí lo tiene y ha podido probar con sus propias manos cómo es el desempeño de Metro Last Light en GNU/Linux. De entrada tenemos algunos vídeos de muestra de los primeros minutos del juego, todos muy parecidos y bastante prometedores, suficiente para que se nos caiga la baba https://www.youtube.com/watch?v=kXU-S7pBnWM Pero... lamentablemente no es oro todo lo que reluce y ahora, con la cabeza fría, toca sopesar si verdaderamente se ha hecho un buen trabajo. Para empezar, tenemos el eterno problema, que hostiga a los linuxeros desde hace años y que se resume en 3 letras, AMD y su mal hacer a la hora de dar soporte a plataformas *nix. Tanto es así, que el retraso del lanzamiento no ha servido de nada y en el anuncio oficial así lo hacen saber, seguimos a la espera de una futura actualización de los controladores de AMD que permita disfrutar de este título porque a día de hoy es casi imposible bajo una de estas tarjetas. Según los comentarios de algunos usuarios, el desempeño de estas tarjetas es nefasto, apenas llegando a los 10FPS y presentando numerosos errores y sin poder recurrir a los controladores libres, dado que éstos aún no tienen soporte para las versiones más recientes de OpenGL exigidas por el juego. Si se dan una vuelta por los foros de soporte, por las comunidades de Steam o, sin ir mas lejos, por los mismos comentarios que han ido dejando bajo el anuncio oficial de, verán una queja tras otra de usuarios con tarjetas AMD que no pueden disfrutar del título en condiciones o que ni siquiera pueden llegar a iniciarlo http://steamcommunity.com/games/MetroVideoGame/announcements/detail/1841138399631172025 El 2º objetivo de mi ira a día de hoy es menos habitual y, a priori parece no tener ninguna relación con el asunto que estamos tratando, pero en base a las comparaciones hechas por Evil Penguin y cuyas capturas pondré a continuación, nos llevan a una conclusión que ahora trataré de explicar. Directx VS OpenGL (Y no voy a decir cuál es cual ) Aunque a primera vista parece todo correcto, si nos fijamos en detalle notamos, al menos, un par de cosas: La tessellation (No sé traducir esto) brilla por su ausencia, así que algunos relieves son casi totalmente planos en la versión GNU/Linux. Algunas sombras/iluminación no se muestran de manera correcta. Capado y acomodado, como mucho, a OpenGL 3.2/3.3 Phsyx ¿Eso qué es?¿Se come? Probablemente donde mejor se aprecie la diferencia acerca de estas dos cuestiones es en las últimas dos imágenes, que engloban todos los errores al mismo tiempo y, seguramente, algunas cosas más que yo no he visto. La conclusión a la que se ha llegado del por qué de esta limitación o falta de características de la versión GNU/Linux tiene dos componentes diferenciados y, repito, no se trata de nada oficial sino de conclusiones sacadas por los usuarios que han podido probar el título hasta ahora. El primero ya lo hemos nombrado, las limitaciones y falta de soporte de AMD, que finalmente han tenido poco menos que "ignorarse" para que el port saliera al mercado y en 2º lugar, a la "herencia recibida" (Me he sentido lo más sucio y ruin del mundo al decir esto, no sé por qué ) Y es que no debemos olvidarnos de que no es un título diseñado para ser multiplataforma sino un port hecho a posteriori, se diseñó para Windows con DirectX, posteriormente se portó a Mac OS bajo OpenGL y a partir de éste último se ha hecho un segundo port a GNU/Linux, con lo cual, en las carencias gráficas del juego están las de Mac OS y la tardanza de Apple en dar soporte a las nuevas características de OpenGL y/o hacerlo "a su manera". Por tanto, si la versión Mac OS no puede hacer frente a los efectos de Tessellation y otras características propias de OpenGL 4.X, la versión para GNU/Linux, que es una derivada de esta, evidentemente tampoco podrá y podemos dar gracias a Apple por su contribución a que esto sea así, pues mientras nosotros disfrutamos desde hace tiempo de OpenGL 4.4, salvo la última versión de Mac OS X lanzada hace muy poco que soporta OpenGL 3.3 y un poco de la 4.1, el resto de versiones siguen con la 3.2/3.3. Lo que no quita responsabilidad a los desarrolladores por haber "reciclado" código antiguo y desfasado en lugar de hacer las cosas en condiciones para este nuevo port. En cuanto a rendimiento parece que la opinión generalizada es que, quizá, rinda un poquito mejor que la versión bajo DirectX, pero no hay ninguna prueba seria que lo apoye sólo apreciaciones personales y, teniendo en cuenta lo que acabamos de decir en este tema, puede que los resultados estén falseados (No es lo mismo correr el título con todos los efectos habilitados que sólo con algunos), así que tendremos que esperar un poco más a ver si alguien se anima a hacer una comparación verdaderamente seria. SI alguno de los presentes se anima... Sin embargo y a pesar de todo lo dicho, sigue tratándose de un gran título y aunque no cumpla al 100% con la calidad prometida, no lo hace por muy poco, es un juego que vio la luz hace bien poco (2ª mitad del año) y es uno de los pesos pesados dentro de los AAA, por lo que es una gran oportunidad para los Gamers linuxeros y una prueba más del apoyo creciente de la industria hacia GNU/Linux.
  20. Sin duda alguna, AMD consiguió conmocionar a la industria hace apenas dos meses con su nueva API gráfica a la que han apodado "Mantle". Durante su presentación inicial no desvelaron casi ningún detalle, sólo una idea general de lo que pretendían conseguir con esta API, que según sus responsables se diferenciaba de las APIs gráficas tradicionales por ser de bajo nivel (Close to metal) permitiendo así atender hasta 9 veces más peticiones por segundo que las APIs de alto nivel como, por ejemplo, OpenGL, lo que supondría una increíble mejora en cuanto a rendimiento gráfico se refiere. Esta API, según nos cuentan, aboga por la facilidad y transparencia, haciendo la vida más fácil a los desarrolladores y permitiendo mayor libertad, abaratando los costes de desarrollo, etc Sin embargo, fuer de estas promesas no sabíamos nada acerca de esta nueva API, salvo algunos pequeños detalles que nos dejaron sus responsables, como que sería compatible con Microsoft HLSL y NO con OpenGL, que estaban colaborando estrechamente con DICE y su motor gráfico Frostbite y que estaba enfocada en hardware muy concreto, las AMD Radeon con arquitectura GCN (Graphic Core Next). Durante esta semana, en la AMD developer submit 2013 celebrada en el centro de convenciones de San José, se han realizado numerosas presentaciones y conferencias en las que AMD ha dado a conocer más detalles sobre su nueva apuesta de futuro. EDITO Tengo que hacer una puntualización aquí debido a un pequeño malentendido. La presentación a la que hago referencia no fue hecha por AMD sino por DICE, es decir, no es exactamente la visión que tiene la compañía Roja para con Mantle, sino un interpretación propia que nos hace DICE No obstante, si bien han hecho una presentación más larga y concisa, a primera vista parece que contradicen muchas cosas que se habían dicho anteriormente. Y sí, admito que he empezado a ver la presentación pero no he podido acabarla, parecía más un anuncio de teletienda que otra cosa, con muchas promesas y posibilidades salpicados con algunos datos sueltos de vez en cuando pero nada del otro mundo, así que vamos directos al grano apoyándonos en las diapositivas mostrada, que tenemos disponibles gracias a Planet3DNow (¿Algún germanoparlante en la sala?) pues esté sí muestra algunas cosas "interesantes". En primer lugar vemos un cambio de rumbo claro y si antes remarcaban la compatibilidad con M$ HLSL, ahora son las plataformas *Nix las que cobran importancia, incluyendo lo que podemos calificar de llamada de atención desesperada hacia Valve para que no los dejen fuera de Steam OS Y también apuestan por el cada vez más relevante mercado de los dispositivos móviles buscando hacer la competencia directa a OpenGL ES que es el que domina la situación actualmente en este sector Ahora es cuando la situación se torna extraña, empiezan las contradicciones y nos dejan aún más confusos que antes y es que lo ponen bien claro desde el principio. Mantel está diseñado como una "fina" capa de abstracción que no está atada a la arquitectura GCN de AMD, pudiendo ser soportada por la mayoría de tarjetas gráficas recientes y con extensiones específicas para todas las plataformas y arquitecturas actuales. Esto es justo lo opuesto a lo que nos contaron en la presentación inicial y se aleja totalmente del concepto "close to metal" que nos habían vendido. De hecho, si la primera descripción que hicieron de Mantle nos hizo equipararlo con el extinto 3dfx GLide o la actual NVApi, tal y como nos lo cuentan ahora, más parece un equivalente exclusivo AMD a la actual OpenGL. A partir de aquí empezamos con la parte más "técnica", en las que equiparan Mantle con las actuales APIs gráficas y nos hablan de sus ventajas y las diferencias a la hora de trabajar con con Mantle en lugar de con las APIs tradicionales. Hacen hincapié en la desaparición de los cuellos de botella, la disminución de la latencia, el escalado lineal con los núcleos de la CPU y el trabajo en paralelo, así como la simplificación de los drivers, evitando sobrecargas e hilos de ejecución innecesarios. Y también, como no, un pequeño spot publicitario de DICE Luego nos hablan del nuevo modelo de desarrollo en comparación con el actual, abogando por la transparencia, la documentación explícita, la interacción sencilla y el acceso más directo a los recursos disponibles. Mientras el modelo tradicional es definido como una "Caja Negra" (Aquí hemos saltado a DirectX), Mantle se muestra como explícita, flexible y eficiente, permitiendo saber y manipular cada pequeño detalle de cada proceso. Pipelines monolíticos, todo se combina en un único objeto, lo que significa que la compilación o parcheado no son necesarios durante la ejecución, lo que supone una carga mucho menor Soporte para construcción y cacheado en paralelo, lo que supone tiempos de carga menores. Uso y administración en la capa de aplicación Todo esto supone una mejora de rendimiento de la GPU evitando cuellos de botella y evitando el renderizado por fuerza bruta, otorgan mayor grado de flexibilidad a los drivers y evitan a las aplicaciones las transiciones redundantes Para terminar, se centran en cómo funcionan las gráficas actuales, que trabajan de manera heterogénea, y cómo se distribuye la asignación de recursos a las distintas actividades. Imagino que aquí volverían a hablar de esas "9 veces más peticiones que las APIS tradicionales". Y cerramos con un último anuncio de DICE, esta vez con una imagen que muestra cómo hubiera sido Plants VS ZOmbies si hubieran hecho uso de esta tecnología :lol: La conclusión es... bueno... no hay ninguna conclusión salvo que han cambiado de opinión en muchos aspectos desde Septiembre hasta ahora o, simplemente, nos han contado dos películas diferentes y seguimos sin saber aún qué es Mantle, cómo funciona o qué repercusiones tendrá. El único aspecto positivo que podemos sacar de todo esto es que parece que ha pasado de ser una API completamente cerrada y exclusiva a algo multiplataforma, así que dentro de lo malo deberíamos poder llegar a usarlo todos los usuarios y no únicamente los poseedores de una GPU GCN compatible en una versión muy concreta de un sistema operativo en particular bajo las estrictas condiciones de AMD como parecía haberse planteado en un principio. Lo que podemos pensar es que, al haberle llevado un portazo en las narices por parte de M$ y $ony de cara a formar parte en el desarrollo de títulos para las consolas de próxima generación, han puesto a Mantle en una posición delicada y lo que en un principio sacaron a la luz como una jugada maestra se ha convertido en una tímida apuesta que dependerá completamente de lo bien que se lleven con Valve, el apoyo que reciban de otros fabricantes y si los desarrolladores están dispuestos a trabajar o no con otra API más. EDITO Al ser palabras de DICE y no directamente de AMD, no podemos tener una visión clara de lo que verdaderamente pretende esta última, pero al menos esto supone una confirmación del interés por parte de DICE para traer un título "rompedor" a GNU/Linux, portanto FrostBite y apostanto por Steam OS :cheers: http://www.planet3dnow.de/cms/5720-apu13-andersson-will-mantle-fuer-alles-und-jeden/
  21. Hace poco, algunos ingenieros de Nvidia se pusieron en contacto directo con los desarrolladores de los controladores Nouveau con la intención de mejorar las relaciones entre la gran compañía verde y el ecosistema de la comunidad Linux. Para apoyar esta iniciativa comenzaron a liberar documentación y especificaciones, empezando por las Tegra y posteriormente han empezado a liberar también documentos de su serie GTX. Por su parte, aunque AMD no ha cumplido con algunas propuestas/promesas que hizo durante los últimos meses, no ha querido quedarse atrás y, en una peculiar batalla con Nvidia, la empresa roja también está liberando documentación sobre sus últimas Radeon a un ritmo mucho mayor del que nos tiene acostumbrados En esta ocasión, AMD nos ha dejado varios documentos relacionados con las Evergreen, Southern, Northern y Sea Island: AMD GPU 3D/Compute Documentation Por su parte, la documentación de Nvidia tiene un fin mucho más concreto y se centra en las especificaciones de vBios para solucionar un problema concreto que sufren los controladores libres: ftp://download.nvidia.com/open-gpu-doc/
  22. Como muchos de nosotros, durante esta semana he estado pendiente de las jugosas novedades presentadas por Valve y Nvidia y he dejado de lado la promesa de AMD de anunciar "algo" que haría que tanto desarrolladores como Gamers linuxeros saltáramos de alegría: Sin embargo, han pasado varios días desde la fecha en la que supuestamente se haría tan esperado anuncio y aún seguimos sin saber nada, no hay nuevos controladores, no hay nueva documentación (como en el caso de Nvidia) no hay confirmación de estar colaborando con Valve y su Steam OS y/o sus "Steam Machines"... Lo único que hemos podido sacar en claro de la conferencia llevada a cabo por AMD es el lanzamiento de la nueva línea de tarjetas R7 y R9 cuya nomenclatura ha cambiado y ahora pasan a a ser x2XX, empezando con los modelos x260, x270 y x280, prácticamente igual a la nomenclatura que empezó a usar por Nvidia 6 o 7 años atrás. Además del nuevo hardware, AMD hizo otro importante anuncio y es en lo que pretendo que nos centremos, la Nueva API de bajo nivel llamada Mantle y que vendría a competir con las veteranas APIs de alto nivel OpenGL y DirectX, por lo que vamos a hablar un poco del tema, no como noticia sino más como una charla entre usuarios que se beneficiarán o sufrirán esta tecnología en el futuro. Según nos comenta AMD, al tratarse precisamente de una API de bajo nivel, la comunicación con el Hardware es más directa, sencilla, por lo que es posible realizar hasta nueve veces más llamadas por segundo que haciendo Uso de las APIs de Alto nivel tradicionales y además, prometen que mediante el uso de Mantle, los desarrolladores podrán llevar a cabo sus proyectos de manera más simple comunicándose más estrechamente con el Hardware. Por lo que hemos oído hasta ahora podríamos pensar que Mantle es de lo bueno lo mejor, comunicación estrecha y directa con el hardware, fácil de programar, rendimiento muy superior... que es básicamente lo que están difundiendo la mayoría de medios durante los últimos días. No obstante, debemos tener en cuenta TODO lo que supone Mantle y por qué podría ser una muy buena idea o todo lo contrario. De entrada, de la comunicación directa con el Hardware se encargan los controladores o Drivers y en el caso de Mantle esto se lleva aún más allá, pues existe una mayor responsabilidad por parte de este software para hacer que la tarjeta gráfica responda directamente a las llamadas realizadas por las diferentes aplicaciones y realizar las tareas que se le encomiendan correctamente. AMD no es una empresa que destaque precisamente por su soporte y no hace falta volver a recalcar el estado en que se encuentran los controladores Catalyst para Linux y, de hecho, parece que no tienen intención de ofrecer soporte nativo para Mantle en GNU/Linux, al menos no de entrada, e incluso dejan claro que se han preocupado porque exista compatibilidad entre Mantle y Microsoft HLSL (High Level Shader Language) pero no con OpenGL u otro sistema operativo, con lo cual a priori, lejos de alegrarnos y ponernos a dar saltos de alegría se nos queda la cara a cuadros y nos asaltan un millón de dudas. En este punto quiero destacar que lo que propone Mantle NO es nada nuevo, 3Dfx ya presento su API de bajo nivel Glide para las tarjetas Voodoo allá por el año 1999 (Y acabó siendo comprada por Nvidia) y desde hace varios años tenemos Nvidia NVAPI o las alternativas que tendrá Intel y con las que no estoy familiarizado. Es decir que, si hasta ahora no han triunfado/visto la luz alternativas semejantes no ha sido porque no las haya, sino porque no es una práctica viable al ser totalmente dependientes del hardware para el que están diseñadas, impidiendo que el software sea compatible con el resto de hardware del mercado.. En el caso concreto de Mantle, sería compatible exclusivamente con las tarjetas con soporte AMD Graphics Core Next y ninguna otra, dejando a los desarrolladores la decisión de desarrollar para Mantle y con ello sólo para las últimas tarjetas AMD, hacer uso de una API de alto nivel como OpenGL y crear algo "universal" o hacer ambas cosas, teniendo que trabajar mucho más pero cubriéndose las espaldas "por si acaso". Aún con la poca información que han dado sobre el funcionamiento y posibilidades de Mantle y a pesar de afirmar que se tratará de una API abierta, esto no significa que otros fabricantes puedan darle soporte sin más, pues como hemos dicho está pensada para un hardware concreto, no para cualquier hardware y o bien tendríamos diferentes versiones de Mantle, una para cada fabricante, lo que no sería anda beneficioso para los desarrolladores o numerosas capas de abstracción que asegurarían la compatibilidad pero echarían por tierra el supuesto aumento del rendimiento. Sin embargo, a pesar de todo lo que acabamos de decir hay que quitarse el sombrero ante AMD que, aunque haya presentado la API posiblemente a mala idea y dándonos completamente la espalda, ha sabido jugar sus cartas muy muy bien. ¿Por qué digo esto? Pues por una sencilla razón y es que TODAS las consolas de la próxima generación llevarán APUs AMD, por tanto, tienen el 100% de este mercado, así que aunque su API sea totalmente exclusiva y por inverosímil/inviable que resulte la idea, están en una posición de monopolio absoluto, no hay nadie que pueda hacerles la más mínima sombra. En este sentido y según ellos mismos, Mantle ofrecería una forma rápida, fácil y mucho más eficiente de programar para las futuras consolas, a la vez que haría que los ports hacia PC fueran directos, aprovechando la compatibilidad con Microsoft HLSL para dar soporte a los juegos DirectX (Y a OpenGL que es el verdadero estándar que le den por C***) Por tanto y sin saber apenas nada, por ahora Mantle no sólo no nos beneficiará en modo alguno a los linuxeros sino que podría suponer una enorme traba a la hora de portar juegos de consola a otras plataformas a pesar de que AMD haya expresado justo lo contrario, pues o bien sólo serviría para GPUs muy específicas o supondría tener más capas de abstracción por medio que lejos de aumentar el rendimiento lo reducirían, así que sólo nos queda esperar a Noviembre, que es cuando han prometido mostrar la nueva API con mayor detalle y ver lo que nos deparará el futuro, o bien un gran avance tecnológico o una tecnología dañina y monopolista que nos traerá nuevos dolores de cabeza o un vano intento de destacar por parte de AMD que quedará en nada. Lo único que por ahora sabemos seguro es que, al menos en un principio, AMD no ha pensado en nada más que no sean las futuras consolas o Windows.
  23. Los usuarios de AMD/Ati conocerán bien la situación en la que se encuentran los controladores de esta empresa para GNU/Linux y en general, ya que también en Mac OS e incluso en Windows hay problemas. Hace relativamente poco la empresa decidió descontinuar los controladores Catalyst para tarjetas "antiguas", dejando sin soporte a todas las tarjetas por debajo de la serie HD5000 e incluyendo a las series HD2XXX, HD3XXX y HD4XXX como Catalyst-legacy, cuya última versión es la 12-6 y su soporte es prácticamente nulo, con innumerables errores y bugs que siguen sin ser corregidos. Por este motivo, la gente de DesdeLinux ha decidido organizar una recogida de firmas para posteriormente enviarla a AMD: SUpongo que más de uno conocerá la plataforma change.org, para quien no, para firmar sólo es necesario dejar nombre y un email https://www.change.org/es/peticiones/amd-mejoras-substanciales-en-el-driver-radeon-legacy-12-6-linux
×
×
  • Crear Nuevo...