Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'gráficos'.

  • 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 17 resultados

  1. Buenas tardes, estoy con Ubuntu 16.04 instalado en un Compaq 610. Buscando como mejorar un poco la gráfica encontré que Intel tiene una herramienta muy interesante, la Intel Graphics Update Tool for Linux* OS v2.0.2. Fuente: https://01.org/linuxgraphics Esta herramienta actualiza los drivers de las tarjetas gráficas Intel tanto en Ubuntu 16.04 como en Fedora 24, arquitecturas de 32 y 64 bits. Pues bien al hacer: $ lspci | grep VGA obtengo: 00:02.0 VGA compatible controller: Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller (rev 0c) Para instalar la herramienta agregamos la llave pública del repositorio Ubuntu 16.04 $ wget --no-check-certificate https://download.01.org/gfx/RPM-GPG-KEY-ilg-4 -O - | \ $ sudo apt-key add - $ sudo apt-get update $ sudo apt-get upgrade Información adicional Ubuntu https://01.org/linuxgraphics/documentation/running-update-tool-using-gdebi Fedora 24 Luego de agregar las firmas, elegimos el paquete según arquitectura y distribución: Descargamos el correspondiente, y en mi caso solo tuve que hacer doble click en el archivo .deb, y el instalador de software de Ubuntu instaló el paquete (requirió la clave de administrador). Una vez instalado, ubicamos el "intel-graphics-update-tool" en Unity con el Dash buscamos Intel, y en Genome Aplicaciones, Herramientas del sistema, Preferencias. Doble click sobre él y se inicia el proceso Nota: como siempre, agradezco sí el tema lo requiere, sean modificadas etiquetas o reubicado, por parte de moderadores o Admin del Foro. Espero sea de utilidad JPablos
  2. El nuevo Doom, uno de los títulos más esperados de este año, está dando mucho de que hablar, tanto por su nuevo enfoque arena, combinando elementos modernos, pero a la vez con un toque muy clásico, como por otros aspectos a nivel más técnicos. Si bien ya sorprendieron hace unos meses por lo que su nuevo motor ID Tech 6 era capaz de ofrecer apoyándose exclusivamente en OpenGL, con un rendimiento, al parecer, muy bueno y una calidad gráfica impactante, ahora han decidido ir un paso más allá y han anunciado oficialmente que Vulkan será uno de los pilares de este shooter. Aprovechando la reciente presentación de la nueva arquitectura de GPUs Pascal, de Nvidia, quien ha colaborado activamente en el título, se han decidido a mostrarnos todo el potencial de la API moviendo el que, por ahora, es el único título AAA en aprovecharse de las bondades de las nuevas APIs gráficas. Y, como no podía ser de otra manera, tenían que los desarrolladores de ID, ahora sin John Carmack, los que estuvieran detrás de este salto generacional. Los medios ya se han hecho eco de lo bien que le ha sentado el cambio al título, que se ha dejado ver estos meses en forma de betas, tanto en rendimiento, corriendo sobradamente con una media de 110 FPS a resoluciones muy altas, como en lo referente al aspecto visual, con efectos de iluminación verdareamente sorprendentes. Aunque eso sí, no sin la consabida cantinela pro-DirectX que parece que están obligados a repetir como loros aunque no venga a cuento. Hay que reconocer que técnicamente será inferior, pero a nivel de Marketing la alternativa de Microsoft al estándar abierto oficial (y no al revés como suelen confundirse todos los medios) juega en otra liga. Obviamente no podía ser tan bonito y Bethesda, quien compró ID Software hace unos años, sigue manteniendo una estricta política de exclusión y aunque el motor gráfico y el título hayan sido diseñados y desarrollados con APIs y estándares abiertos y en torno a la plataforma del Ñu y el Pingüino, seguirá fiel a su filosofía de impedir que el juego vea la luz en GNU/Linux. Se mantiene aún la esperanza que, dada la creciente popularidad de Valve y Steam OS, pueden cambiar de parecer, pero de momento sus planes están claros y la respuesta para las Linuxeros es un NO rotundo, que no se sustenta en ningún problema técnico, sino en una decisión puramente política, como ya ocurrió con Rage o Wolfestein, en la época de ID Tech 5. La llegada del título es inminente, apenas quedan un día para que los jugadores puedan tener la versión final en sus manos, así que es de esperar que el lanzamiento oficial se haga con el motor OpenGL antiguo y más adelante ofrezcan una gran actualización que nos traiga la versión definitiva de ID Tech con soporte completo para Vulkan.
  3. Como estaba previsto, este Lunes ha arrancado la trigésima edición de la Game Developers Conference en San Francisco y, a falta de un día para que finalicen las conferencias, las muestras y novedades en torno a la nueva API gráfica del grupo Khronos no han dejado a nadie indiferente. Valve, Epic Games, Oxide Games, Nvidia... son sólo algunos de los que han estado allí para mostrarnos lo que Vulkan puede llegar a hacer. Si bien aún es pronto para tener en nuestras manos todo el material que ha salido a la luz durante la GDC, ya empiezan a llegar algunas muestras de aquellos que han tenido la suerte de poder asistir, aunque eso sí, con una calidad más propia de un screener de cine. Tendremos que esperar a que sean liberados los vídeos oficiales, ordenados y con una calidad aceptable, a través del portal del grupo Khronos, pero mientras tanto, podemos ir haciendo boca con los adelantos que ellos mismos nos han ofrecido. Aunque teniendo en cuenta que son alrededor de 6 horas de material, creo que podrían considerarse algo más que un "adelanto" Al margen de lo que podemos encontrar a través del canal del grupo Khronos, algunos de los pesos pesados del sector no han podido resistirse a mostrar sus armas para la próxima generación. En ese sentido Epic Games, como no podía ser de otra manera, volvió a sorprendernos con los avances de su motor gráfico Unreal Engine 4. Como dato interesante y algo que parece haber sorprendido a algunos curiosos, Epic se ha centrado mucho en hacer hincapié en su total compromiso con Vulkan, algo que veremos a continuación en uno de sus trailers, ignorando completamente cualquier otra API de segunda fila que no parece interesarles (Y a buen entendedor, pocas palabras bastan ) Por su parte, Valve se ha centrado en hablarnos de su motor Source 2, que cuenta ya con un completo sistema de renderizado Vulkan y ha sido distribuido a los IHVs (independent hardware vendors), asegurando que ha podido correr sin problema en gráficas Intel, Nvidia y AMD. Por supuesto, el primer beneficiado de esto no será otro sino será Dota 2 Reborn Oxide games, artífices de Ashes of the Singularity, el cual corre sobre su motor gráfico Nitrous engine, ha vuelto a remarcar lo similares que son las nuevas APIs gráficas entre sḉi y que, de decantarte por la más cerrada, tendrías que mirar también hacia Vulkan, porque estaría el trabajo prácticamente hecho. Los test de Nvidia nos han dejado claro que en términos de Fotogramas por segundo, Vulkan aventaja a OpenGL y ambos dejan en mal lugar a Directx 11, aunque eliminando algo de detalle, Directx 9 puede aún hacerles frente a la mayoría de los anteriores Como ya he dicho, la GDC 2016 no ha terminado y aún nos quedan muchas cosas por ver, pero por ahora lo que hemos podido ver resulta muy emocionante. El futuro de los gráficos renderizados por ordenador no podría ser más alentador. http://www.gdconf.com/
  4. 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/
  5. Hace tiempo hice algo parecido, pero no tan exhaustivo, ya que por aquel entonces el panorama no se acercaba ni remotamente a lo que tenemos ahora e lo que se refiere a rendimiento gráfico y videojuegos. El propio Martin Gräßlin ya propuso un sistema para mover las aplicaciones que demandan un alto rendimiento gráfico fuera del servidor gráfico donde se encuentra corriendo el entorno de escritorio para evitar la sobrecarga y el consumo extra de recursos que supone tener corriendo un escritorio debajo de la aplicación que estamos ejecutando. Especialmente si se trata de un videojuego a pantalla completa. Interactuando directamente con libuniput y el servidor gráfico, sin compositores u otros intermediarios del entorno de escritorio, mejoraríamos, en teoría, el rendimiento y evitaríamos una serie de problemas típicos de los compositores y gestores de ventanas. Nvidia, por su parte, ha ido aún más allá y ya tienen un sistema que permite, gracias a EGL, renderizar contenido gráfico OpenGL (y suponemos que Vulkan también) no sólo sin entorno, sino prescindiendo también del entorno gráfico. Esto abre un mundo de posibilidades y podría ser la clave para la futura migración de X11 a Wayland, además de suponer un antes y un después para grandes servidores y granjas de equipos que se utilizan para renderizar gran cantidad de datos 3D. Aunque en nuestro caso no vamos tan lejos, sí que resulta un tema muy interesante de cara al día a día. Es lógico que el entorno gráfico tenga cierto impacto en el rendimiento, no es ninguna novedad, especialmente ahora que muchos exigen sí o sí contar con aceleración gráfica únicamente para mostrar las ventanas. Las preguntas que nos haríamos en este punto serían ¿Cuánto?¿Qué diferencia existe entre los diferentes entornos disponibles? Pero sobre todo ¿Prescindir de entorno gráfico es realmente una opción que realmente compensa a la hora de jugar a cualquier videojuego? Me encantaría contar con más medios y hardware para poner a prueba la teoría, pero tendremos que conformarnos con mi actual equipo, que ya tiene unos cuantos años a sus espaldas, pero que aún le queda guerra que dar Por supuesto las pruebas se harán sobre Debian ¿Dónde si no? Y si no me muero en el intento, habrán 7 contendientes: Enlightenment 0.20.3, Cinnamon 2.2.16, Mate 1.8.1, Xfce 4.12.1, Gnome 3.14, KDE 5.4.3 y el séptimo adversario a batir será nuestro veterano servidor X11 corriendo a pelo Las pruebas a superar, como no podía ser de otra manera, son puramente gamer y bastante exigentes, especialmente para mi GTX 560 Ti que ya empieza a mirarme mal He intentado que fueran lo más variadas posibles, aunque dadas las limitaciones y ciertos problemas que han aparecido durante el proceso, no puedo jactarme de ofrecer una fiabilidad mínimamente aceptable, aunque sí una buena muestra que nos pueda poner al tanto de un par de cosas Equipo de pruebas Tests GPU Test Creo que con el nombre de este Test basta para saber de qué se trata. GPUTest se compone de un gran número de tests OpenGL que cubren un amplio espectro en lo que se refiere a probar las capacidades de nuestra GPU GiMark Plot3D FurMark TessMark Triangle Pixmark Piano Pixmark Volplosion Resumen El resumen no deja lugar a dudas, sin entorno gráfico gozamos de cierta ventaja a la hora de renderizar contenido. Cinnamon por su parte, no ha salido muy bien parado de este GPUTest, siendo el entorno que ha quedado último en 6 de las 7 pruebas. Para el resto de entornos los resultados son más variados y sin mucho que destacar. Unigine Valley El motor gráfico Unigine Engine es un clásico entre las pruebas de rendimiento gráfico y, a la espera de la inminente llegada de los nuevos Benchmarks Unigine 2.0, tendremos que conformarnos con dar unas cuentas vueltas por el Valle virtual creado por los rusos. Se repite la misma situación que en el caso anterior, con Cinnamon en la cola, aunque esta vez KDE también se nos ha desinflado un poco. Por supuesto, al correr el Benchmark sin entorno gráfico tenemos un extra aunque esta vez es mínimo. Hay que tener en cuenta que la capacidad del hardware de prueba es limitado, los valores que arroja son relativamente bajos y, probablemente, con un equipo que pudiera correr el test de manera más holgada obtendríamos mayores diferencias Metro Last Light Redux En un primer momento quería incluir un mayor número de juegos reales y recientes, pero finalmente me he decantado por el último título de 4A Games, principalmente por la facilidad que ofrece a la hora de realizar pruebas con él. Este test ha puesto las cosas del revés. Xfce ha arrebatado a Cinnamon el título del más lento, aunque no por mucho, y observamos un desplome importante en la prueba realizada sin entorno gráfico. Podríamos estar ante la excepción que confirma la regla, pero la explicación es algo más sencilla. Nos encontramos ante el primer problema a la hora de realizar los test. En este caso, para poder realizar la prueba de Metro Last Light Redux, era necesaria la intervención del Cliente de Steam, que corría en segundo plano cuando se ejecutaba desde un entorno gráfico, pero que al lanzarlo directamente sobre las Xs, el la ventana de Steam se ha interpuesto, colocándose delante de las imágenes de prueba y saboteando así el resultado final. Unreal Engine 4 Matinee No podía faltar la mayor creación de Epic Games. Los demos de UE4 son de sobra conocidos y en este caso me he decantado por la espectacular escena de lucha Matinee para poner en apuros a mi tarjeta gráfica Este test es, sin lugar a dudas, el más extraño de todos, poniendo todo patas arriba y, en esta ocasión, sin ninguna excusa por mi parte. Es muy curioso ver a Gnome y KDE disputándose los puestos de cabeza con Mate, mientras que Enlightenment, que hasta ahora había estado siempre arriba, pierde algo de fuelle. Una vez más, Xfce nos deja un sabor amargo quedando otra vez por detrás de Cinnamon. Por último, de las siete pruebas, la que se ha realizado sin entorno gráfico ha quedado justo a la mitad, dejándome sin saber qué pensar. Aunque si observamos de cerca la línea de tiempo vemos que los resultados han sido muy irregulares con picos y valles muy acusados (o inverosímiles como en el caso de Cinnamon), con mínimas y máximas exageradas. Lo único que podría sacar en claro de este test es que, dada su "inestabilidad", se trata de una prueba que no nos permite sacar ninguna conclusión clara acerca del rendimiento. Pejiguero que es uno, cuando ya casi había hecho limpieza de toda la basura que he tenido que meter para hacer los test, he tenido una idea feliz Me he puesto a probar de nuevo con UE4 y he descubierto algo que también es muy interesante. El perfil de phoronix test suite para los demos de Unreal Engine no incluye ninguna opción adicional, sólo la ejecución básica. Eso significa que cuando he realizado los test, matinee se estuvo ejecutando de la manera más "conservadora" posible, que viene a ser el modo GLSL 150, OpenGL del año de maricastaña. Esta vez sólo he comparado E20 con la ejecución sin entorno gráfico y no pienso hacer ninguno más, de momento . La línea de tiempo y los valores de pico muestran de nuevo mucha inestabilidad, pero en contra del sentido común, al subir las opciones al máximo forzando la ejecución con GLSL 4XX (OpenGL 4.x), el rendimiento ha aumentado entre un 15% y un 20% "Conclusiones" Como no me he cansado de repetir, las limitaciones nos impiden ir más allá de algo más bien anecdótico para poner en apuros a mi equipo, pero al menos hemos podido comprobar que, efectivamente, el entorno gráfico tiene cierto peso en lo que a rendimiento gráfico se refiere. Establecer un ranking de entornos con tan pocos datos sería aventurarse demasiado. Sin embargo, parece que los pesos pesados del escritorio Linuxero, Gnome y KDE se mantienen más o menos en la media de la tabla, mientras que Cinnamon tiene que trabajar más en lo que se refiere a rendimiento gráfico. La gran sorpresa ha sido Xfce, pues el sentido común nos podría hacer pensar que un escritorio de este tipo debería rendir mejor que sus compañeros mucho más grandes y pesados y, sin embargo, lo hemos visto aparecer a menudo en los puestos de cola, siendo varias veces el último de todos. Insisto una vez más en que lo que he mostrado aquí ha sido mi muy limitada experiencia con un hardware muy concreto y tan sólo unas pocas pruebas, pero de vez en cuando no está de más comprobar las cosas por uno mismo
  6. Este año, como muchos sabemos, ha sido probablemente el punto álgido en la historia de GNU/Linux en lo que respecta a videojuegos. Hemos visto casi duplicarse el número de títulos nativos y "nativos" con respecto al años pasado, han sido lanzados Steam OS y Steam Machines, así como los esperadísimos periféricos de Valve, tenemos Vulkan, la nueva API gráfica del grupo Khronos a la vuelta de la esquina, Nvidia ha empezado tímidamente a abrirse con los desarrolladores de nouveau, AMD parece que por fin se ha comprometido en algo con AMDGPU... en definitiva, un año de grandes cambios que no han dejado indiferente a nadie. Sin embargo, como tantas veces hemos comentado, durante el mismo periodo, ahora mismo estamos en un punto de inflexión. Las cosas están cambiado para mejor, pero aún nos queda mucho camino por recorrer antes de cantar definitivamente ¡Victoria!. Los desarrolladores de Hardware, los problemas de la industria del videojuego, las horrendas políticas y decisiones de Microsoft, pero sobre todo la gran apuesta de Valve, han sido los detonantes que nos han llevado hasta donde estamos hoy. Este primer impulso, esta apuesta declarada y sincera, cual efecto dominó, ha hecho que poco a poco se vayan sumando y participando más estudios, portadores, desarrolladores, fabricantes, testers... una auténtica revolución digital que en breve supondrá un antes y después no sólo para GNU/Linux, sino para la industria del videojuego en General. Pero como ya dije, aún quedan muchísimas cosas por hacer y, por supuesto, grandes detractores que intentarán que no les pisen el negocio empleando para ello los medios que hagan falta. Debemos ser conscientes de cómo es la situación actual y, aunque muchos no podamos ser de gran ayuda, siempre podremos aportar nuestro granito de arena para ayudar a que sigamos avanzando. El estado de los juegos "nativos" para GNU/Linux Mucho se ha hablado de este tema, de hecho, no hace mucho que Ars Technica publicó un sesgado y manipulado estudio comparativo al respecto aclamando la supremacía de otro sistema que es el que mayormente paga sus facturas y que, si bien no podemos decir que es del todo falso, sí que hay que saber interpretarlo para poder sacar conclusiones coherentes a partir del mismo. EN primer lugar debemos tener en cuenta que la industria del videojuego, aunque parezca lo contrario, se mueve muy lentamente y aunque ya tenemos a nuestra disposición una nueva generación de hardware y consolas, los títulos con los que nos están abasteciendo siguen siendo más de la generación anterior que de esta. Los motores gráficos de "nueva generación", Unreal Engine 4, Cryengine 4, Unigine Engine 2, Source 2... apenas se han utilizado en un par de títulos o no se han usado en absoluto, por tanto, los desarrolladores de videojuegos que quieren expandirse a otras plataformas se ven en la tesitura de no contar con motores gráficos de antigua generación que no fueron diseñados con ese fin. Llegados a este punto hay varias opciones, actualizarse a los nuevos motores, rediseñar por completo el motor gráfico utilizado y optimizarlo para hacerlo funcionar con OpenGL o, la más recurrida, hacer alguna chapuza para salir al paso. Dado que los videojuegos que ya llevan unos años en el mercado no son susceptibles de ser rediseñados o recibir una actualización completa de su motor gráfico, la opción más clara para estudios y desarrolladores es realizar alguna chapuza que les permita conseguir su objetivo de ser multiplataforma sin perder demasiado tiempo y dinero en el intento. Incluso para los títulos lanzados recientemente o a punto de ser lanzados se cumple esto último, porque si bien son novedades, su desarrollo se remonta años atrás, cuando aún no se pensaba en el desarrollo multiplataforma. De hecho, en la industria actual existen vicios muy feos a la hora de desarrollar software, que podrían resumirse en: Trabajar únicamente para la plataforma más limitada/desfavorable y hacer ports y adaptaciones una sobre otra para el resto de las plataformas a las que se aspire. Es decir, que actualmente los usuarios de Play Station 4 ven títulos fresco y recién desarrollados para su plataforma, los usuarios de Windows reciben un port de esta versión, con sus limitaciones y sus chapuza y nosotros recibiríamos un tercer refrito de ésta última, sumando limitaciones de los dos anteriores o, en el caso de ser un título que también aparezca en OS X, cuyo soporte poara OpenGL es muy limitado, recibiríamos el 4º port extremadamente capado y limitado. Por mucho potencial que tenga GNU/Linux, por mucho que haya mejorado en tema de drivers, APIs, frameworks... la realidad es esta y hasta que la industria no se adapte a los nuevos tiempos tendremos que ser transigentes con algunas cosas y ser conscientes que en la mayoría de los casos no vamos a poder disfrutar de una experiencia 100% plena en comparación con otras plataformas. Irónicamente, dada la "calidad" de los desarrollos actuales muchas veces pasará desapercibido para la mayoría Dentro de los ports o adaptaciones tenemos un amplio abanico de posibilidades, entre los que destacan los siguientes: Ports realizados por el propio estudio Este tipo de adaptación es realizada por el propio estudio que desarrolló el juego originales, aunque no necesariamente por el mismo equipo de desarrolladores, y los medios empleados para realizar la tarea varían enormemente según el caso. Desde un equipo profesional completo dedicado a dicha tarea a contar con un único becario en prácticas que tiene que lidiar con todo el trabajo. Como ya dijimos antes, en ningún caso se llevará a cabo el rediseño del título para trabajar en una nueva plataforma bajo otras APIs, simplemente se modificarán las partes que sean necesarias y se utilizarán algunas capas de abstracción para aquellas donde no resulte rentable. Para esto existen herramientas como ToGL, IndirectX y otras muchas que ayudan a los desarrolladores a transformar las partes que ha sido diseñadas exclusivamente para DirectX en su equivalente OpenGL de manera sencilla y prácticamente automática. Evidentemente, aunque el resultado siempre serán binarios nativos, esta conversión no 100% eficaz y siempre tendrá un impacto mayor o menor en el rendimiento gráfico final. Un claro ejemplo de esto son los títulos de Valve, Left 4 Dead 2, Half Life 2, Dota 2... cuyas adaptaciones ha sido realizada por los creadores original y que ya nos han mostrado en más de una ocasión que su rendimiento incluso ha mejorado y ya en algún caso como Dota 2 se han atrevido a actuliazar el motor gráfico a uno de nueva generación. Pero insisto en que no siempre es así Ports subcontratados Esta es, sin duda, la opción más recurrida últimamente. Estaríamos ante la misma situación que en el caso anterior, un port nativo en el que se emplean algunas herramientas de conversión que no son del todo eficaces, pero que es realizado por un estudio que no tiene nada que ver con el desarrollo original. Este sería el caso de Feral Interactive, Aspyr Media o de grandes veteranos como Ryan Gordon o Timothee besset, que son subcontratados para obrar la magia de llevar un software a otras plataformas. Este método tiene sus ventajas, ya que son equipo de expertos que se dedican en exclusiva a este trabajo, pero al mismo tiempo ocurre que son personas al desarrollo original y están forzados a trabajar con código escrito por otros (cono todo lo que eso implica). En general este tipo de ports suelen ser bastante aceptables, no sólo por la experiencia que tienen los que lo realizan, sino porque una vez lanzado seguirán teniendo alguien que los respalde y corrija posibles problemas. Ejemplos en este caso tenemos Middle earth: shadow of Mordor, Grid Autosport, Alien Isolation, Sid Meier’s Civilization: Beyond Earth, Borderlands Pre sequel... títulos muy logrados que si bien no podemos esperar que estén 100% optimizados podemos estar seguros que al menos funcionaran bien y nos permitirán jugar de manera adecuada. Otro ejemplo opuesto de este tipo de ports lo tenemos con Batman arkham knight, un título que ha dado muchísimo de que hablar este año, no sólo por ser el cierre de la exitosa saga desarrollada por Rocksteady Studios, sino por haber sido portado a Windows de manera tan horrible y nefasta por Iron Galaxy Studios,que acabó siendo retirado del mercado, para ser relanzado recientemente en un estado no muy diferente al del primer port, que fue llevado a cabo desde un desarrollo exclusivamente PS4 (OpenGL) a WIndows (DirectX) y cuya adaptación para GNU/Linux iba a dejarse en manos de un tercer estudio, Feral Interactive, que ya ha dicho que no se ensuciarán las manos con semejante esperpento y seguirán trabajando a partir del original para intentar traernos una versión jugable, posiblemente durante el segundo trimestre de 2016. Este caso es posiblemente el más representativo que podemos encontrar de cómo funciona la industria a día de hoy y de lo que nos espera a corto/medio plazo hasta que la transición se complete. Ports ficticios Si bien ya he dicho que es muy raro ver un título realmente nativo para GNU/Linux y tenemos que resignarnos a contar con ports que son mayormente nativos pero con algunas chapuzas, en este último caso hablamos directamente de títulos que no son ports en absoluto. Otro de los métodos a los que recurren los grandes estudios a la hora de llevar su software a otras plataformas consiste en no esforzarse en absoluto por ofrecer software nativo y en lugar de ello utilizar Wrappers que hagan de intermediarios entre su software original sin modificar y la plataforma en la que quieren ejecutarlo. Sé que esto puede resultar un poco complicado de entender, pero creo que puedo resumirlo en única palabra de tal manera que todo el mundo lo entienda. WINE. No obstante, aunque es un clásico encontrar aplicaciones que dicen ser nativas y que venden como tal y que al observarlas se ve claramente como corren sobre una versión muy concreta de Wine, en la industria del videojuego quien se está encargando de esto es un Wrapper muy similar desarrollado por Virtual Programming llamado eON. Si bien para el estudio es una forma rápida y barata de llevar su software a otras plataformas y, al igual que con Wine, hay casos en los que las cosas parecen funcionar bien, lo más habitual es que este tipo de estrategias se caractericen por sufrir todo tipo de errores extraños, crasheos, fallos inexplicables y una experiencia de juego... digamos que "sorprendentemente entretenida e imprevisiblemente cautivadora" :lol: Es aquí donde debemos plantarnos y decir NO. Antes dije que había que ser algo transijentes dada la situación actual y apoyar a aquellos que hacen un esfuerzo por traernos software nativo a la plataforma del Ñu y el Pingüino. Sin embargo estaremos de acuerdo en que esto último no sólo no es un esfuerzo, sino que es directamente un engaño, por tanto no deberíamos ser partícipes para que no se perpetúe esta tendencia. Por mucho juegos que de manera "rápida" podría suponer para nosotros, el coste a pagar es demasiado elevado. Queremos juegos, sí, pero juegos con un mínimo de calidad. El renacer de las APIs gráficas Hemos hablado largo y tendido durante el último año sobre Vulkan, la API gráfica abierta, multiplataforma y a bajo nivel del grupo Khronos, que llega para sustituir a la veterana OpenGL con la intención de llevar los desarrollo gráficos al nivel tecnológico actual. Capacidad para exprimir aún más el hardware para obtener mejor rendimiento, desarrollos más sencillos, multiplataforma, bajo un estándar abierto ideado por los pesos pesados de la industria partiendo de la idea original que tuvo AMD con Mantle. Smartphones, consolas, televisores, PCs... todos se beneficiarán de este salto de gigante en lo que respecta a la industria de los gráficos renderizados por ordenador. Pero volvemos a lo mismo que hemos estado tratando desde el principio. Estamos en punto de inflexión donde todo está cambiando, pero aún no lo ha hecho. Vulkan no llegará mañana, ni dentro de un mes ni de dos, será una transición lenta y paulatina que terminará con el nacimiento de una nueva industria, nuevas formas de desarrollo y software que responderá a esta nueva tendencia, para bien o para mal, aunque todo apunta a que el cambio será positivo. Pero para eso, aún tendremos que esperar un poco más Los principales implicados Sin duda alguna quien dio el empujón definitivo que hacía falta para que todo esto ocurriera y que ha invertido muchísimo en GNU/Linux, al punto de crear su propia distribución, Steam OS y empezar a comercializar equipos destinados a jugar desde GNU/Linux, Steam Machines, a todo el catálogo disponible en su tienda de distribución digital de videojuegos Steam. El lanzamiento, que se produjo durante el pasado mes de Noviembre, fue bastante silencioso y, al mismo tiempo, fue salpicado por la polémica suscitada por muchos medios tecnológicos que distan mucho de ser imparciales y/o profesionales. Lo cierto es que tanto Steam OS como las Steam Machines acaban de nacer y aún nos queda mucho antes de ver cómo se hacen un hueco en el mercado. Aún así y a pesar de todo, las ventas ventas tanto de equipos como de periféricos han sido realmente buenas, lo que se opone frontalmente a lo dicho por tantos detractores. Otra cosa que he podido observar, que se repite mes tras mes desde hace dos años y que demuestra que el ser humano es el único animal que tropice no dos, sino inumerables veces con la misma piedar, son los artículos haciendo referencia a una ficticia cuota de mercado de jugadores linuxeros que ¡Fíjate que curiosa, sorprendente y cruel casulidad del destino! Se ha mantenido inamovible en el 1%. Hace tiempo que Valve respondió a esto de una manera clara, pero parece que muchos siguen sin enterarse y lo utilizan como dato significativo para justificar, probar o desmentirr las más disparatadas teorías. Lo cierto es que los datos que se recogen en las estadísticas de Steam son puramente anecdóticos y no pueden ser tomados al pie de la letra. La recopilación de datos se realiza de manera aleatoria a modo de "sondeo" que busca hacerse una idea de las especificaciones de los equipos de los jugadores que utilizan regularmente Steam, por lo que la inmensa mayoría de los usuarios de Steam no han sido jamás incluidos y su hardware/software es, tanto para Valve como para nosotros, un misterio. Al mismo tiempo, la propia compañía ya confirmó que, en lo que respecta a la parte específica para GNU/Linux, esto iba aún más allá y, aunque han hecho varios intentos, no han conseguido una manera eficaz de "medir" a los usuarios linuxeros, dada la inmensa variedad de distribuciones, configuraciones, versiones, etc, por lo que la mayoría de los linuxeros que, por casualidad, son contabilizados, finalmente tampoco acaban apareciendo representados en las estadísticas. Las estadísticas directas de venta tampoco son fiables, dado que están sujetas a muchísimas variables, juegos comprados antes de contar con versión nativa para GNU/Linux no cuentan, si han sido jugados durante X tiempo en otra plataforma, tampoco, si se obtuvieron a través de un medio ajeno a Steam y luego autentificados en éste tampoco les es posible saber dónde tenías pensado jugarlo al comprarlo... En definitiva, es triste ver como después de 24 años todavía sigamos erre que erre con el cuento del 1% Ampliamente conocida por todo linuxero amante de los videojuegos, la californiana es, por desgracia, la única que a día de hoy permite disfrutar en GNU/Linux de los títulos de última generación. Si bien lo hace a través de software mayormente privativo, algo que no nos agrada demasiado, es una compañía que casi siempre cumple en cuanto a rendimiento, especificaciones, soporte y la adopción temprana de nuevas tecnologías, al punto de asimilarlas antes de ser anunciadas oficialmente. Al mismo tiempo, su carácter cerrado hace que no se integre del todo en el ecosistema linuxero, tanto a nivel de usuario como entre los desarrolladores, aunque parece que durante los últimos años ha empezado a volverse más abierta, pero de manera tímida y principalmente en lo que respecta a su gama de procesadores Tegra y no tanto a sus series de escritorio Geforce y Quadro. Si bien es cierto que los precarios controladores gráficos libre Nouveau han avanzado mucho en el último año gracias a varios aportes de la propia Nvidia, a'un nos queda mucho camino por recorrer. Seguimos ante una propuesta privativa, con todo lo que ello implica, pero sin duda alguna, a la hora de rentabilizar una gran inversión como lo es una tarjeta gráfica dedicada, por ahora sigue siendo nuestra única opción. Si bien Intel se limita a ofrecer gráficas integradas en sus procesadores que no se acercan ni remotamente al rendimiento que pueden ofrecer las GPUs dedicadas, su caracter Open Source es de sobra conocido por los linuxeros que no tienen grandes necesidades a nivel de gráficos y pueden desarrollar su actividad diaria con este tipo de gráficas sin ningún problema de soporte. Los controladores para este tipo de Hardware no están a la vanguardia en cuanto a tecnología o especificaciones OpenGL, pero es que tampoco hace falta dado el uso al que están destinadas. Eso sí, al igual que Nvidia, el soporte para Vulkan está más que asegurado antes de su salida. Nos adentramos en un terreno inhóspito que hará que se levante más de una ampolla y que tampoco podremos tratar en profundidad porque no acabaríamos nunca. AMD ha sido, durante mucho tiempo, el patito feo para todos los linuxeros. Controladores privativos ineficientes a la par que problemáticos, carentes de opciones, que llegan tarde y mal, que descontinúan series relativamente recientes de hardware muy temprano dejando a sus usuarios con un palmo de narices... y una contraparte de controladores libres muy trabajados por parte de la comunidad pero que no se acercan a brindarnos el rendimiento y características que esas GPUs podrían darnos. Muchos años de mal soporte, de tener que estar saltando entre controladores privativos y libres para aspirar a poder ejecutar un tipo de aplicación u otra, de sufrir con cada salida de una nueva versión de X.org o del propio Kernel Linux por no tener soporte hasta meses o incluso años después... han sido las razones por las que, la mayoría de los linuxeros que quieren disfrutar de la experiencia de juego nativa en la plataforma de Ñu y el Pingüino, no tocarían una gráfica AMD ni con un palo. Durante el último año también han cambiado muchísimo las cosas para AMD y se ha hablado largo y tendido de su nueva propuesta, los Controladores AMDGPU, una apuesta de unificación de esfuerzo entre desarrolladores libres y privativos que viene a cambiar las cosas o, al menos, eso es lo que nos han dicho. No obstante, esto ha llegado tarde, muy muy tarde, y si en el mundo de los videojuego estamos antes un inminente cambio, en lo que respecta a AMD aún estamos empezando. AMDGPU implica grandes cambios, pero también la ruptura definitiva entre lo moderno y lo antiguo. Sólo las gráficas de nuevas generación y las que salgan a partir de ahora podrán aspirar a beneficiarse de las bondades de los nuevos controladores, algo que a priori tiene mucha lógica desde el punto de vista del desarrollo, pero que para los usuarios cuyos equipos tengan más de año y medio les sentará como una auténtica puñalada. Así todo y aunque el nuevo enfoque de los controladores de AMD supone un antes y un después, facilitará muchísimo las cosas en todos los aspectos y unificará esfuerzos, seguimos sin saber si ciertos problemas de siempre podrán o no solucionarse, entre ellos el pobre rendimiento de estas gráficas en GNU/Linux. La unificación supone mejora, sí, pero si hasta ahora ninguna de las dos partes ha conseguido un rendimiento óptimo ¿Se conseguirá con AMDGPU? Otro punto donde también ha supuesto una desilusión para usuarios y gamers es, precisamente Vulkan. AMD ya confirmó que la nueva API gráfica no será soportada den entrada por los nuevos controladores y que el soporte llegará inicialmente a través de los Catalyst (Crimson) de manera tardía y, posteriormente, comenzarán los trabajos para incorporarlo al controladores unificado. Puede sonar confuso, incongruente o incluso contradictorio, pero como ya dije antes, esto acaba de empezar y ahora mismo hay muchísimas más dudas que respuestas y, si para otras cosas que ya llevan años de desarrollo detrás aún vamos a tener que esperar, en el caso de AMD y su prometedora propuesta de futuro, la espera será aún mayor. En el caso de las APUS, si bien no serán tan fáciles de domar como las Intel, los controladores libres siempre estarán ahí para echarnos una mano y, dado que no le pedimos grandes cosas, la falta de rendimiento y características puede pasar un poco desapercibidas para usuarios de a pie. Sin embargo, a la hora de plantearse invertir una gran suma de dinero esperando obtener a cambio un rendimiento acorde... las Radeon siguen sin ser una alternativa viable y no parece que vayan a serlo en un futuro cercano. Reflexión ¿Final? Si han llegado hasta aquí, tendrán el mismo sabor agridulce que tengo yo mientras escribo esto, pero tampoco puedo maquillar las cosas para hacer ver que estamos en los mundos de Yupi o en el más profundo y frío abismo, lo cierto es que estamos justo en medio, sufriendo una dolorosa pero necesaria transición que no sabemos cuánto llevará, pero que apunta a que será algo muy positivo para la industria, para los usuarios en general, pero sobre todo para GNU/Linux. Nos quedan un par de años de incertidumbre, de grandes alegrías y tristes decepciones que nos llevarán finalmente hasta una estabilidad que esperamos que sea la que todos deseamos. Lo que no se puede negar es que el avance qe podemos apreciar hasta el momento en todos los frentes es, simplemente, espectacular, así que hagamos lo que buénamente podamos para que sigamos avanzando en el mismo sentido, aunque no sea aportando fondos o código, simplemente apoyando a quienes nos apoyan y condenando lo que haya que condenar para que las cosas mejoren. Y por último y más importante, sean críticos y no se crean la mayoría de las cosas que les cuentan, especialmente si provienen de cierto perro forero linuxero que no hace más que desvariar
  7. Hace ya tiempo que hablamos de GLVND (OpenGL Vendor-Neutral Driver) una ABI que permitiría la coexistencia de librerías gráficas de distintos fabricantes de manera simultánea, mediando y resolviendo las llamadas a la API OpenGL. Han pasado unos años, pero finalmente Nvidia ha liberado una nueva serie de controladores que, si bien con cuentan con otras novedades que nos hubiera gustado que incluyeran y aún se encuentran en estado beta, sí que dan una vuelta de tuerca al panorama de los controladores gráficos y OpenGL en GNU/Linux, gracias a libglvnd. Además de esto se corrige un bug de EGL, se actualiza el instalador de Nvidia y se eliminan definitivamente las librerías de Vdpau del instalador, pues a día de hoy, al ser libres, están incluidas en cualquier distribución. A priori estos controladores no supondrían un cambio en cuanto a rendimiento o desempeño, salvo en los casos donde esta nueva ABI sí que sea necesaria y marque la diferencia. https://devtalk.nvidia.com/default/topic/908423
  8. 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
  9. Aunque Nvidia no se caracteriza por ser la empresa más abierta, sí que nos suele sorprender a menudo con nuevas tecnologías, mejoras y soporte para cosas que ni conocíamos. La última gran sorpresa que nos llevamos fue la culminación de la nueva ABI OpenGL, que llevaba en el tintero varios años y que Nvidia puso en nuestras manos con la última serie de controladores 361.x En esta ocasión, Peter Messmer ha querido, a través del blog de desarrolladores de Nvidia, explicarnos cómo gracias al estándar EGL y los cambios que se han ido introduciendo en las últimas series de controladores de Nvidia, es muy sencillo desvincularse del servidor gráfico a la hora de renderizar contenido OpenGL. Si bien el principal objetivo se centra más en equipos y centros de desarrollo, en los que tener una sesión de las Xs abierta para renderizar contenido off-screen no es deseable, en el caso de los usuarios de a pié sí que nos permite imaginarnos las posibles aplicaciones de esto, especialmente en lo que podría suponer de cara a la inminente migración de X11 a Wayland. Por supuesto, no se limita únicamente al renderizado, sino que permite administrar los recursos de manera precisa, incluyendo configuraciones Multi-GPU. No seré yo quien explique el funcionamiento detallado, porque sinceramente hace rato que me he perdido, pero por lo poco que he podido entender, la cosa pinta muy, pero que muy interesante. gnulinuxvagos.es/index.php?app=forums&module=post&section=post&do=new_post&f=14
  10. GFXBench es un benchmark gráfico multiplataforma que, en su versión 4.0, ha decidido expandir aún más sus horizontes transformándose también en un benchmark OpenGL con soporte para GNU/Linux, que se suma al resto de plataformas móviles y de escritorio. La suite cuenta con varios test diferentes, Car chase, Manhattan y Manhattan 3.1, que ponen a prueba distintos aspectos de rendimiento. Además de eso, ya se preparan para la inminente llegada de Vulkan, e incluso para la API Metal de Apple Capturas Vídeo Descarga https://gfxbench.com/linux-download/ Web https://gfxbench.com/
  11. Vulkan, la API gráfica de nueva generación del grupo Khronos que se convertirá en el próximo estándar para los gráficos generados por ordenador, sigue haciéndose de rogar y aún tendremos que esperar un poco más para tener la versión final en nuestras manos. Aunque en un primer momento la API tenía como fecha de salida el último trimestre del pasado año, el proyecto ha resultado demasiado ambicioso y el grupo Khronos ha optado por hacer las cosas bien y postergar el lanzamiento hasta que todo esté atado y bien atado, aunque aseguran que la llegada de Vulkan es inminente. Los primeros rumores apuntaban a los primeros meses de este mes de Enero, durante el CES 2016, pero ha sido una conferencia más bien "sosa" en lo que a GNU/Linux y a gráficos se refiere, centrándose sobre todo en los nuevos dispositivos de realidad virtual y sin ninguna noticia sobre Vulkan. El próximo evento, al que estamos casi seguro que llegará la versión de la API, no sólo por la importancia de éste, sino porque ya sabemos de antemano que AMD, NVidia y otros muchos tienen conferencias muy sonadas que dar sobre Vulkan y sus planes para darle una vuelta de turca a la industria del entretenimiento gracias a este estándar. Lo que no tenemos claro es si aprovecharán el evento para hacer el anuncio durante la propia GDC, a celebrar en Marzo, seguido del lanzamiento y las posteriores muestra de las posibilidades y el potencial de la API, o si veremos Vulkan en las próximas semanas y las muestras del evento serán la guinda del pastel. La semana que viene también se celebrará una conferencia sobre Vulkan en París, pero parece demasiado pronto y muy poco mediática como para albergar esperanzas de tener la API tan cerca :cry: En cualquier caso, parece que fabricantes y desarrolladores están tan ansiosos por la llegada de Vulkan que no pueden contenerse y nos dejan perlas por doquier para ponernos los dientes largos. El último de ellos ha sido Christoph Kubisch, de NVIDIA, quien nos ha planteado un tema algo complicado en cuanto a la simbiosis inicial que existirá entre Vulkan y OpenGL. Como ya sabemos entre las grandes ventajas que ofrecerá Vulkan, están mejores capacidades Multi-threading, un control más directo de la GPU llevando los comandos directamente a ella (close to metal), resultando en un uso mucho menor de la CPU y un mayor rendimiento. OpenGL, por su parte, sigue siendo, a día de hoy, más sencillo a la hora de utilizar el acceso al Hardware, lo que resulta interesante para aplicaciones que no están limitadas por la CPU. La complejidad de adoptar una API que no se parece a nada que hayamos visto hasta ahora, supone un gran reto para los desarrolladores, por lo que desde Nvidia planean ofrecer, además de soporte completo desde el primer día, una serie de extensiones y facilidades para que la transición resulte simple. Con esto se contempla la posibilidad de correr Vulkan dentro de un contexto puramente OpenGL y también a la inversa, consumiendo los shaders GLSL directamente sin tener que recurrir siquiera a SPIR-V. De esta forma, nos permitirá utilizar librerías de ventanas y de interfaz de usuario favoritas, permitiendo comparar y aunar OpenGL y Vulkan sin problemas. Si bien se trata de un artículo orientado casi exclusivamente a desarrolladores y la inmensa mayoría de nosotros se perderá entre los conceptos y tecnicismo que esta nueva manera de trabajar implica, con cada nuevo anuncio que se realiza más prometedora se vuelve esta API. Lamentablemente sólo queda una cosa que podamos hacer y es lo mismo que hemos hecho desde el principio. Esperar a que Vulkan esté por fin lista para poner todo patas arriba. https://developer.nvidia.com/engaging-voyage-vulkan
  12. Como ya sabemos de sobra, el grupo Khronos ha estado trabajando sin descanso durante todo este año en las especificaciones de la nueva API gráfica obierta y multiplataforma que pasará a ser el estándar de la nueva era gráfica digital. Sin embargo, aunque en un principio los planes eran lanzar la primera versión oficial de Vulkan a finales de este mismo año, finalmente no va a poder ser. Ellos mismos han dado a conocer el estado actual de la API y aseguran que Vulkan 1.0 ya está lista, los test de conformidad han sido realizados y ahora mismo se encuentran puliendo los últimos detalles y poniendo a trabajar toda la maquinaria legal para poder hacer pública la nueva API. Pero con apenas 13 días para que termine Diciembre, hay que ser realistas. No queda tiempo suficiente para que salga este año. Los progresos para terminar los SDK para las distintas plataformas también van viento en Popa y Google ha aumentado su apuesta pasando de ser un miembro colaborador del grupo Khronos a uno de los pesos pesados dentro de su directiva. Todos los rumores apuntan a la próxima edición del CES 2016 que se celebrará del 6 al 9 de Enero, el escenario idóneo para hacer un lanzamiento de estas características, a la vez que las diferentes compañḉias y desarrolladores muestra todo el potencial de la nueva API. Una cosa está clara, la salida de Vulkan es inminente y esta vez tenemos una confirmación oficial, aunque, como siempre, seguimos sin una fecha exacta. Pero ¡Eh! Es el grupo Khronos y se trata de un estándar abierto ¿Qué otra cosa cabría esperar? https://www.khronos.org/vulkan
  13. Cada vez son más los que se suman al grupo Khronos para explotar el potencial de la nueva API gráfica Vulkan. Tras el Siggraph pudimos ver como LunarXchange apostaba por la formar a los futuros desarrolladores en el uso de la API con un portal Web educativo que además cuenta con el patrocinio de Valve. Ahora es Imagination Technologies, de quien hemos oído hablar largo y tendido desde que fue presentado Vulkan, quien quiere sumarse a la iniciativa con 5 seminarios Online para todos los desarrolladores o entusiastas que quieran saber más sobre el futuro de los gráficos generados por ordenador. Tobias Hector, ingeniero de Imagination encargado del diseño de Vulkan y OpenGL ES, es el encargado de las presentaciones que comenzarán el 26 de Octubre y terminarán el 17 de Diciembre. Serán retransmitidas a través de youtube, la web y el blog oficial de Imagination 1) Una API para todas las plataformas Página del evento | Página de Youtube | Blog 2) Alta eficiencia en terminales móviles Página del evento | Página de Youtube | Blog 3) Escalando a múltiples hilos Página del evento | Página de YouTube | Blog 4) Operaciones explícitas y tiempos consistentes entre frames Página del evento | Página de YouTube | Blog 5) Arquitectura positiva: Cómo la API Vulkan funciona para GPUs PowerVR Página del evento | Página de YouTube | Blog http://blog.imgtec.com/powervr/5-new-webinars-on-the-vulkan-api
  14. Abróchense los cinturones y mantengan el culo bien pegado al asiento porque ya tenemos en nuestras manos un gran número de demos técnicas impulsadas por el motor gráfico de Epic Games, Unreal Engine 4. De manera nativa y puramente para 64 bits, estas muestras que ha compartido Epic con nosotros pondrán a prueba nuestras equipos, exprimiendo al máximo las capacidades de nuestro hardware, al mismo tiempo que nos dejan con la boca abierta. Sólo recomiendo dos cosas, equipos antiguos o modestos mejor abstenerse y a los demás... tengan preparado un cubo, una fregona y un buen babero :lol: Elemental http://ue4linux.raxxy.com/elemental_demo.tar.bz2 Effects Cave http://ue4linux.raxxy.com/effects_cave_demo.tar.bz2 Realistic Rendering http://ue4linux.raxxy.com/realistic_rendering_demo.tar.bz2 Reflections Subway http://ue4linux.raxxy.com/reflections_subway_demo.tar.bz2 Sci-Fi Hallway http://ue4linux.raxxy.com/sci-fi_hallway_demo.tar.bz2 Sun Temple http://ue4linux.raxxy.com/sun_temple_demo.tar.bz2 Stylized http://ue4linux.raxxy.com/stylized_demo.tar.bz2 Blueprint Office http://ue4linux.raxxy.com/blueprint_office_demo.tar.bz2 Landscape Mountains http://ue4linux.raxxy.com/landscape_mountains.tar.bz2 Matinee http://ue4linux.raxxy.com/matinee_demo.tar.bz2 Shooter Game http://ue4linux.raxxy.com/shooter_game.tar.bz2 Strategy Game http://ue4linux.raxxy.com/strategy_game.tar.bz2 Vehicle Game http://ue4linux.raxxy.com/vehicle_game.tar.bz2 Platformer Game http://ue4linux.raxxy.com/platformer_game.tar.bz2 Atlantis Substance http://ue4linux.raxxy.com/atlantis_demo.tar.bz2 Couch Knights http://ue4linux.raxxy.com/couch_knights.tar.bz2 Light Room Interior http://ue4linux.raxxy.com/lightroom_interior_day.tar.bz2 Por supuesto, a través de la wiki oficial de Epic Games podremos acceder a toda la información y material disponibles sobre Unreal Engine 4 https://wiki.unrealengine.com/Linux_Support
  15. 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.
  16. Con la intención de hacer a Ubuntu más atractivo para los desarrolladores de juegos, fabricantes de hardware y usuarios, Canonical ha decidido cambiar su política de actulización de controladores gráfico para adoptar las nuevas versiones de los controladores más rápidamente. Bryce Harrington, uno de los pocos mantenedores de X.Org dentro de Ubuntu, ha escrito en su bog sobre una "mejor experiencia de juego en Ubuntu 12.04". En él dice básicamente, que buscan ofrecer una mejor experiencia para los gamers haciendo actualizaciones más rápidas de los controladores gráficos en las distribuciones de Ubuntu existentes para asumir rápidamente las correcciones que se hagan para algunos juegos, mejorar el soporte del hardware y hacer más sencillo y accesible el proceso de actualización para los usuarios. Hasta ahora, como Ubuntu es una distribución "Cycling release", los controladores gráficos de Nvidia y AMD permanecían, al igual que el resto de paquetes que conforman Ubuntu, congelados en la misma versión y no eran actualizados hasta la salida de la siguiente versión de Ubuntu. Recientemente han estado ofreciendo un opción "-updates" como alternativa para obtener nuevas actualizaciones desde sus repositorios, pero quieren ir más allá y no ofrecer versiones estables, sino también controladores experimentales/beta. Bryce ha comentado, "Los juegos comerciales a veces necesitan los controladores más recientes para corregir errores o soportar nuevas características. Pero tenemos que ser muy cuidadosos con este despliegue de cambios para evitar posibles regresiones, por lo que este soporte acelerado debe ser opcional. Con la guía y consejos de Valve, ofreceremos juntos algunas soluciones que respondan a los requisitos de los juegos y sean accesibles para el usuario final". Canonical ofrecerá paquetes nvidia-experimental-xxx para los controladores privativos de Nvidia, donde xxx indicará la versión mayor del controlador, por ejemplo nvidia-experimental-304. El controlador experimental de NVIDIA estará disponible en Ubuntu 12.04 LTS y también en las versiones posteriores, como Ubuntu 12.10. Canonical también planea hacer algo similar con los controladores privativos de AMD, pero aún no han empezado a trabajar en ello. En cuanto a los controladores libres, está el Ubuntu-X PPA. La actualización de los controladores libres es un "desastre" pues no implica un único componente, sino también el kernel, Mesa, libdrm, DDX y otras muchas dependencias. Este es uno de los grandes retos de los controladores libres. Básicamente, el cambio que hará a Ubuntu mejor para jugar es hacer más sencilla la instalación de los últimos controladores experimentales/beta desde repositorios en lugar de tener que descargarlos desde la web oficial del fabricante. Bryce termina diciendo que estos cambios serán para aquellos usuarios que quieran estar a la última, pues queremos ayudarlos a que empiecen a jugar a estos nuevos juegos en Ubuntu 12.04 lo antes posible. Para aquellos que quieran esperar un poco, en pocos meses a partir de ahora vamos a lanzar una actualización más amplia de Ubuntu 12.04.2, que debe incluir todas las actualizaciones anteriores. Pero espero que en el futuro veamos más juegos comerciales en GNU/Linux, y estaremos en condiciones de ofrecer (y mejorar) los nuevos mecanismos de actualización de controladores. "
  17. Uno de los proyectos mas importantes hoy en día para el rendimiento gráfico en las distribuciones GNU/Linux viene de la mano del servidor gráfico X.Org. Muchos de los problemas de compatibilidad que existen últimamente con los portátiles modernos que disponen de gráficos híbridos o intercambiables en GNU/Linux se deben a la capa intermedia del servidor gráfico X.Org. Con el lanzamiento de la versión estable 1.13, GNU/Linux ha dado un paso significativo para poder soportar con precisión las nuevas tecnologías como Nvidia OPTIMUS o AMD PowerXpress/Enduro que tantos dolores de cabeza nos están dando últimamente para los usuarios de GNU/Linux. Los cambios mas destacados son los siguientes: Soporte para la tecnología DisplayLink que permite gráficos por USB, gráficos híbridos como Nvidia OPTIMUS y AMD PowerXpress/Enduro. Capacidad de poder activar o desactivar un determinado dispositivo gráfico en caliente sin necesidad de reiniciar de nuevo el servidor gráfico, otro paso mas para soportar Nvidia OPTIMUS y AMD PowerXpress de forma nativa. Eliminado el soporte de XAA (XFree86 Acceleration Architecture), una tecnología de renderizado 2D bastante limitada y actualmente obsoleta. Los dispositivos gráficos modernos utilizan EXA o UXA, con capacidades de alto rendimiento en operaciones vectoriales y 3D. Soporte experimental para el soporte e integración de Wayland, claramente el futuro gráfico de GNU/Linux. Actualmente los controladores privativos de Nvidia ya ofrecen soporte para la nueva versión del servidor gráfico X.Org 1.13, por otra parte AMD con sus controladores privativos Catalyst todavía no ofrecen soporte en su ultima versión 12.8, tendremos que esperar seguramente a finales de Septiembre para que publiquen los controladores Catalyst 12.9. Actualmente ninguna distribución estable incorpora X.Org 1.13, pero se espera que Fedora 18 y Ubuntu 12.10 sean las primeras en integrar X.Org 1.13 por defecto para ofrecer sus principales características a las distribuciones mas modernas. Desde luego con esta noticia y que Nvidia esta trabajando duramente para soportar Nvidia OPTIMUS en GNU/Linux, se avecinan buenos tiempos para los usuarios de GNU/Linux en equipos portátiles. Visto en Leanuxeros
×
×
  • Crear Nuevo...