Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'Vulkan'.

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

  1. Tras la llegada de Vulkan, el grupo Khronos ha empezado a remover los ciemientos del resto de APIs y WebGL no iba a quedarse atrás en el proceso de "modernización". El período de propuestas se ha abierto para definir lo que será el sucesor de WebGL, apodado de momento WebGL-Next, y como era de esperar, Mozilla no ha tardado en aportar su granito de arena con una API para renderizado de gráficos para la web de bajo nivel que sigue las premisas que dieron origen a Vulkan y a la que han llamado Obsidian. Esta API viene de la mano de WebAssembly, el estandar del que ya hablamos durante el lanzamiento de Firefox 52. Este estándar, así como la API, apuntan al uso de GPUs modernas y sistemas multi-hilo y tienen como objetivo permitir un rendimiento nativo, o prácticamente nativo, para juegos y aplicaciones 3D en el navegador sin necesidad de plugins de terceros. Desde Mozilla son conscientes que el rediseño de las APIs gráficas para la web es un paso claramente necesario y, si bien en discusiones previas se han dos posturas opuestas, una más próxima a Metal, con un enfoque de simplicidad y un nivel mas alto de abstracción y otra virtualmente opuesta, apostando por el enfoque Vulkan, un rediseño de más bajo nivel, que requiere más trabajo pero también supone una visión de gráficos más ricos en la web apoyados en una API explícita de bajo nivel, así como portable, no consideran la primera opción la más adecuada. Esta decisión no ha sido tomada a la ligera, ya que Mozilla ha puesto en práctica las dos visiones bajo su nuevo motor de renderizado servo y la aproximación con enfoque Metal en WebIDL (para Javascript) presentaba problemas de comunicación, debido precisamente a las capas de abstracción y la transcodificación de comandos entre APIs. Si bien pudieron demostrar que era una alternativa "viable", también dejaron claro que se puede aspirar a muchísimo más y si hay que rediseñar una nueva API no es cuetión de quedarse a las puertas de lo que "podría ser", sino de aprovechar la oportunidad única que se presenta y hacerlo bien desde el principio. La propuesta es clara y ya podemos encontrar en github algunos códigos de ejemplo javascript, aunque la resolución final llegará, como siempre, a partir del consenso al que lleguen los miembros del grupo Khronos. https://github.com/KhronosGroup/WebGLNext-Proposals/pull/2/commits/464c70a7ed96d323c77595d792cfc41b69955429
  2. Shiba87

    GDC 2017

    Ya tenemos disponibles los vídeos de las conferencias la Game Developers' Conference 2017, que se celebró desde el de 27 Febrero hasta el 3 de Marzo en la ciudad norteamericana de San Francisco y en la que Vulkan, la nueva API gráfica del grupo Khronos, fue una de las protagonistas principales, así como también la realidad virtual, que parece estar en boca de todos estos días. Entre las novedades de la conferencia pudimos conocer las nuevas extensiones y el progreso de Vulkan, la versión 2.0 de WebGL, OpenXR el estandar para realidad virtual WebGL, WebVR y gITF Desarrollo de realidad virtual multiplataforma Desarrollo de juegos para móviles con Vulkan Vulkan en el escritorio. Profundizando Unificación de Vulkan. Pasado, presente y planes de futuro https://www.khronos.org/news/press/khronos-reveals-api-updates-new-workgroups-at-gdc
  3. Creo que esto son buenas noticias. ¿Un paso más en el ámbito de los juegos? ¿Nos beneficiaremos de esto quizá?
  4. Dota 2 el multitudinario MOBA de Valve, ha sufrido este Martes una nueva transformación. Si hace poco ya nos puso los dientes largos con su remodelación baja el nuevo Source Engine 2 de Valve, ahora le ha tocado el turno a la API de nueva generación, Vulkan. La nueva beta abierta del más que famoso F2P de Valve, se ofrece como una contenido descargable adicional (DLC) y, para forzar el lanzamiento del juego bajo el nuevo motor, han creado una nueva opción de lanzamiento "-vulkan", con la que debemos sobrescribir las que tuvieramos hasta ahora, -opengl, -dx9, etc. Los requisitos mínimos, como ya sabíamos, parten de la serie 600GTX de Nvidia (Kepler) y, aunque aún no del todo funcional, gracias a los AMDGPU PRO, las AMD GCN 1.2, es decir, las últimas R9. Avisan que durante la primera carga del juego, se cargarán nuevas texturas en cache, por lo que sufriremos algunos tirones al principio, que desaparecerán cuando termine la "adaptación" del motor a la nueva API. También hacen referencia a un problema de Tearing en GNU/Linux, que debería solventarse en la próxima versión de los controladores de Nvidia. Es de esperar, al igual que ocurrió con Principle of Talos, que esta primera aproximación a Vulkan se haga mediante Wrappers sobre la versión OpenGL y, por tanto, aún no podamos apreciar verdaderas mejoras sobre la versión antigua del motor gráfico, pero es sólo cuestión de tiempo que así sea. A pesar de estos "problemas" iniciales, vemos como la tendencia continua y con éste ya son varios pesos pesados del mundo los videojuegos el que da el salto para aprovechar las bondades de la prometedora API del grupo Khronos. Siendo Dota 2, junto con Doom, dos de los más populares del momento. http://www.dota2.com/news/updates/22000/
  5. 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.
  6. Desde el año pasado, las noticias sobre Vulkan y los comunicados por parte de fabricantes y desarrolladores que apoyaban el nuevo estándar no han parado de llegar. Entre ellos, las numerosas conferencias, presentaciones y demás información provista por parte de Nvidia siempre incluyeron todas las tarjetas gráficas de escritorio Geforce soportadas por las series de controladores actuales dentro del hardware que podría disfrutar de las ventajas de Vulkan. Esto significaría que, todas las gráficas comprendidas entre la serie GTX 400 (Fermi) y la actual GTX 900 (Maxwell) entrarían dentro de los planes de soporte para Vulkan. Sin embargo, en un inesperado giro de los acontecimiento vimos como la primera versión de controladores beta de Nvidia con soporte para Vulkan partía directamente desde la serie GTX 600 (Kepler), dejando a la arquitectura Fermi fuera de la ecuación. Aunque en un primer momento se especuló que podría tratarse simplemente de un retraso, las diapositivas utilizadas durante las conferencias de este mes de Febrero han sido modificadas, revelando un cambio de planes que para muchos está fuera de lugar. Fermi ya no contará con soporte para Vulkan y la única razón para ello es la apreciación de Nvidia de no haber suficientes usuarios que aún utilicen estas tarjetas, estimando que sólo el 10% aún poseen una de estas GPUs. Durante el seminario online celebrado el pasado 18 de Febrero, uno de los ingenieros confirmó nuevamente que Fermi, a pesar de no existir ningún impedimento técnico, no tendrá finalmente soporte para Vulkan. No sabemos cómo afectará esta decisión a las series actuales de controladores que sí cuentan con soporte para las gráficas Fermi, si se bifurcarán, se descontinuarán o pasarán a ofrecernos paquetes de drivers más complejos con contenido completamente distinto según la arquitectura de la GPU detectada. Si algo ha caracterizado a Nvidia hasta la fecha, es su gran soporte, el mantenimiento de sus controladores tanto para series antiguas como para las que ya llevan más de un lustro en el mercado, la integración inmediata de los nuevos estándares gráficos, librerías, tecnologías... pero esta vez han sacado lo peor de sí mismos, dejando a muchos de sus fieles consumidores con un palmo de narices. Otra de las especulaciones al respecto es que podría tratarse de una respuesta estratégica frente a la decisión por parte de AMD de no dar soporte a sus gráficas GCN 1.0 y, ya que la competencia no lo va a hacer, para qué molestarse ellos ¿No? Está claro que el negocio es el negocio y un nuevo estándar gráfico es una oportunidad de oro para los fabricantes, pero hay ciertos límites que no deberían traspasarse y esta vez parece que la única que ha mantenido el tipo es Intel, siendo precisamente la que menos tiene que ganar en todo esto. Tras muchas noticias positivas, este varapalo la verdad es que no me lo esperaba y muchos usuario que ya están quejándose en los portales y foros oficiales de la compañía, tampoco. Quien me conoce sabe que no dejo pasar una a AMD por su mal hacer y las malas decisiones que suele tomar, pero esta vez es Nvidia quien se merece mi total desaprobación. Esta no es forma de tratar a sus clientes y espero que cambien de parecer, porque alguno optará por seguirles el juego y comprar una nueva tarjeta, pero los Shibas no perdonan y son muy, pero que muy rencorosos... https://devtalk.nvidia.com/default/topic/917161/fermi-support-/ http://on-demand.gputechconf.com/gtc/2016/events/vulkanday/Vulkan_Overview.pdf
  7. 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/
  8. Mucho se ha hecho de rogar, pero finalmente tenemos lo que tanto hemos esperado. Nvidia acaba de liberar una nueva serie de sus controladores oficiales que traen, como siempre, muchas novedades interesantes, pero es que esta vez son más que eso. La nueva serie 364 culmina lo que comenzó con la serie experimental 355 y nos brinda soporte oficial estable para la nueva API gráfica de Khronos, Vulkan, en su actual versión 1.0.6, además de completar el proceso de adopción de EGL introduciendo las primeras librerías que dan soporte completo al servidor gráfico Wayland. Se cambia el patrón de instalación para hacer uso de las librerías GLVND GLX en lugar de las librerías GLX antiguas Se añade soporte inicial para DRM KMS (Direct Rendering Manager Kernel Modesetting) Esto significa la inclusión de un nuevo módulo nvidia-drm.ko, que se inscribe tanto con soporte PRIME como DRM KMS Se añade soporte para numerosas extensiones EGL EGL_EXT_platform_waylandencargada de hacer que aplicaciones Wayland corran en la implementación EGL de Nvidia EGL_WL_bind_wayland_displayencargada de hacer que compositores Wayland corran en la implementación EGL de Nvidia EGL_EXT_device_drm EGL_EXT_output_drm EGL_EXT_stream_consumer_egloutputPara permitir que los compositores Wayland muestren su contenido a través de EGLDevice, EGLOutput y EGLstreams. Se añade la librería libnvidia-egl-wayland.so, que permite a los compositores Wayland el uso de EGLDevice, EGLOutput y EGLstreams para compartir el buffer de EGL con las aplicaciones Wayland Suporte estable para la API Vulkan 1.0 Se mejora la precisión de X colormap desde 8 bits significativos a 11 en GPUs Geforce Se añade una nueva característica RandR, CscMatrix, la cual especifica una matriz de conversión de espacio de color de 3x4. Esta matriz se aplica después de X colormap y antes de gamma ramp. Es compatible con GPUs GF119 o más recientes. Así mismo se mejora el manejo de X gamma ramp en GPUs GF119 o más recientes. RandR gamma ramp cuenta siempre con 1024 entradas y ahora se aplica al cursor, VDPAU capas de estaciones de trabajo como añadido a la ventana de root de las Xs. Los registros del controlador de Nvidia han sido rediseñados con el nuevo subsistema DRM de Linux para dar soporte a PRIME. Como consecuencia de esto, es necesario contar con Linux 3.13 o superior para instalar esta nueva serie de controladores. Se mejora la interacción de aplicaciones que utilizan el cursor de hardware mientras G-SYNC está activo. Se incluye también soporte para nuevas GPUs GeForce 920MX GeForce 930MX Y, por supuesto, numerosos parches y correcciones Sobra decir que al margen de la ingente cantidad de novedades y mejoras, tanto Wayland como Vulkan son dos cosas que llevábamos mucho tiempo esperando y que por fin tenemos a nuestro alcance para sacarle todo su potencial. Nos queda aún el sabor agridulce por la falta de soporte a gráficas Fermi, esperemos que finalmente de parecer, pero igualmente hay que reconocer que, si bien no como a todos nos gustaría, Nvidia sigue siendo única a la hora de ofrecer soporte a los linuxeros más exigentes.
  9. 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
  10. Finalmente ha ocurrido. Tras algunos retrasos y mucha información por parte de desarrolladores y fabricantes que no podían contener sus ansias por echarle mano a la nueva API gráfica abierta y multiplataforma gestada en el seno del grupo Khronos, por fin hoy, es el día en el que las especificaciones de Vulkan 1.0 y su SDK, desarrollado por LunarG, han sido publicadas oficialmente. Vulkan es el resultado de 18 meses de intenso trabajo por parte de todos los miembros del grupo Khronos, una API disponible para multitud de plataformas, un estándar abierto que sentará las bases de la industria de los gráficos renderizados por ordenador en el futuro próximo. La cantidad de material abierto sobre Vulkan ha alcanzado cotas sin precedentes, incluyendo especificaciones, tests, SDKs, herramientas y una fuerte comunidad creada para la participación activa de todos para asegurar el desarrollo consistente de la API y la evolución de un ecosistema de desarrollo alrededor ésta. Vulkan llega para eliminar la sobrecarga sobre los controladores gráficos que ejercían las APIs de antaño, aumentando el rendimiento y ofreciendo un control más directo de las capacidades de la GPU que tanto demandan los motores gráficos de nueva generación, de manera simple y predecible, permitiendo además desarrollar drivers que ofrezcan rendimiento, funcionalidad y portabilidad, sin mucho esfuerzo . Otra enorme ventaja de Vulkan es su capacidad para hacer trabajar en paralelo a la GPU con tantas núcleos de CPU que haya disponibles, eliminado el cuello de botella que existía hasta ahora en este sentido. Con Vulkan se ha pensado también en la transición y, si bien su objetivo a largo plazo es llevar a la industria a un nuevo modelo de desarrollo más moderno, no dejará, de momento, de apoyar a los existentes desarrollos basados en OpenGL y OpenGL ES, complementándolos y/o potenciándolos, haciendo que evolucionen en paralelo junto a la nueva API. SPIR-V será el intermediario que consiga habilitar front-ends de lenguajes de alto nivel que emitan programas en una forma estandarizada para ser asimilada por Vulkan. Eliminando así la necesidad de desarrollar lenguajes de compilación de alto nivel, reduciendo significativamente la complejidad de los controladores gráficos y permitiendo la dicersidad de front-ends para distintos lenguajes. https://www.khronos.org/assets/uploads/developers/library/overview/Vk_201602_Overview_Feb16.pdf Por supuesto, al tratarse de un estándar desarrollado por los pesos pesados de la industria, y al contrario que otras APIs que han apostado por un enfoque similar, la retrocompatibilidad y la compatibilidad son una de las piedras angulares en las que se asienta Vulkan, permitiendo sacar partido de la API en casi cualquier dispositivo, ya sea un equipo de escritorio, consola, terminal móvil pequeños dispositivos... y permitiendo a usuario con hardware no tan moderno poder disfrutar también de las bondades que ofrece el nuevo estándar. Cualquier hardware capaz de lidiar con OpenGL 4 u OpenGL 3.1 podrá lidiar con Vulkan sin ningún problema, lo que para los usuarios de escritorio significa, cualquier gráfica Nvidia soportada por los controladores oficiales actuales (GTX 400 en adelante), las gráficas integradas Intel (HD 4000 en adelante). En el caso de AMD, la cosa no está tan clara y con el reciente cambio de estrategia llevado a cabo con sus nuevos controladores AMDGPU, el soporte para Vulkan se hará de rogar un poco más. EN principio sólo las GPUs Tonga y las que salgan a continuación tendrán soporte ofrecido por blobs privativos, para, en un futuro sin fecha concreta, tratar de ofrecer una alternativa abierta. Aunque para no dejarnos con las manos vacías, desde AMD sí que nos traen una pequeña muestra de lo que nos espera con Vulkan Los controladores gráficos ya están disponibles para los usuarios de gráficas Nvidia e Intel, así como para dispositivos con hardware Qualcomm e Imagination, tal como podemos ver en la página oficial del grupo Al tiempo que contamos con ejemplos y demos para que probemos por nosotros mismos las capacidades de la nueva API. Los controladores para GPU's AMD, como mencioné antes, no llegarán a GNU/LInux, al menos no de momento. https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf Ya sabíamos que el próximo GDC de Marzo será el escaparate perfecto para que todos los grandes desarrollos y futuros proyectos encandilen al público y el lanzamiento oficial de la API no podía hacerse realizado en mejor momento. Además, El seminario virtual que dará el grupo Khronos este jueves 18 de Febrero será la guinda que corone el pastel ¡Salve VULKAN!¡Larga vida y prosperidad! https://www.khronos.org/news/press/khronos-releases-vulkan-1-0-specification https://www.khronos.org/registry/vulkan/specs/1.0/apispec.html https://www.khronos.org/vulkan/ EDITO Intel se pronuncia acerca de los controladores Open Source, que tienen soporte para Vulkan desde el mismo día del lanzamiento. http://blogs.intel.com/evangelists/2016/02/16/intel-open-source-graphics-drivers-now-support-vulkan/ https://01.org/linuxgraphics Nvidia, por supuesto, ha hecho lo mismo y, además, ha liberado una API C++ para Vulkan de su propia cosecha y disponible para todo aquel que quiera utilizarla. En este caso, el controlador está basado en una serie BETA Intermedia (355.00), que al parecer no cuenta con soporte para la última versión de Linux, 3.4 y la aún en desarrollo 3.5 y tampoco ofrece soporte para gráficas Fermi (series Gtx 400 y Gtx 500), que tal y como han dicho anteriormente, sí que serían soportada por la versión estable del controlador. http://blogs.nvidia.com/blog/2016/02/16/vulkan-graphics-api/ https://github.com/nvpro-pipeline/vkcpp AMD, por su parte nos ha dejado con las ganas, ya que AMDGPU no está listo y tampoco ofrecerá soporte para gráficas anteriores a 2015. Pero es que además, según parece, tampoco han ofrecido drivers funcionales para ninguna otra plataforma y lo que hay disponible ahora mismo para M$ Windows es sólo un esbozo que no pasa de ninguna manera los test de conformidad de Vulkan. EDITO2 Uno de los desarrolladores de Croteam, el primer estudio que ha lanzado uno de sus títulos con soporte para Vulkan, nos explica un poco por encima, cuáles son los 3 pasos clave que se necesitan para pasar de OpenGL a Vulkan en lo referente a su motor gráfico EDITO4 Qt se suma a Vulkan Qt company se une al grupo khronos con la única intención de impulsar Vulkan. Esperan que la APÎ gane rápidamente importancia y apoyos, así como los controladores gráficos mejoren notablemente, para así poder trabajar con la comunidad, el grupo Khronos y el resto de colaboradores, en un Qt totalmente compatible con Vulkan. http://blog.qt.io/blog/2016/02/16/the-qt-company-joins-khronos-group-and-promotes-vulkan/?utm_content=28774110 EDITO5 AMD no ofrece controladores, pero sí que nos deja detalles e información muy interesante: http://gpuopen.com/vulkan-renderpasses/?sf20978991=1 EDITO6 El FAQ que ha escrito Croteam acerca de Vulkan no tiene desperdicio. Llevo una hora riéndome Fantásticas perlas que nos deja DEN, que lo ha enfocado como si estuviera hablando directamente con un usuario inu... medio. El primer FAQ que he disfrutado leyendo entero http://steamcommunity.com/app/257510/discussions/0/412447331651720139/
  11. El día 18 de este mismo mes de Febrero, tendrá lugar un seminario online, o "Webinar", impartido por el presidente del grupo Khronos Neil Trevett y el directora ejecutiva de LunarG. Así como otros miembros destacados del grupo, que estarán presentes para atender a las preguntas de los "asistentes" Tom Olson: Miembro del grupo de trabajo de Vulkan Graham Sellers: Editor de especificaciones de Vulkan Karl Schultz: Líder técnico del SDK de LunarG Jon Ashburn: Líder técnico del SDK de LunarG Con este evento pretenden hacernos llegar información sobre qué es Vulkan, de forma que aprendamos todo lo necesario sobre la nueva API directamente de la gente que la ha creado. El seminario durará una hora, donde además de especificaciones se hablará del SDK desarrollado por LunarG, entre otras cosas. Una vez expuestos todos los temas, pasarán a una ronda de preguntas generales, que serán respondidas por los expertos. Para poder "asistir", es necesario registrarse y confirmar la asistencia a través de la web oficial de Khronos El seminario comenzará el 18 de Febrero de 2016 a las 18:00 GTM. Para todos aquellos que no puedan asistir han prometido que toda la sesión será grabada en vídeo y compartida en la misma página de registro. https://www.khronos.org/news/events/vulkan-webinar
  12. No sólo a los fabricantes y usuarios les entusiasma la nueva API del grupo Khronos, los desarrolladores también están ansiosos de poder trabajar con Vulkan. Desde grandes desarrolladores de motores gráficos, como Epic Games o Valve, pasando por estudios más pequeños o Indie, está claro que la revolución gráfica que se avecina no ha dejado indiferente a nadie y los Croatas responsables de la famosa saga Serious Sam no han querido quedarse atrás. Con la cuarta entrega de sus título insignia se encuentra en pleno desarrollo, la inminente llegada de Vulkan no podía venirles mejor y ya nos han confirmado que Sam volverá con más acción, más locuras y corriendo sobre Vulkan. Y no sólo eso, al parecer también quieren exprimir todo el potencial de la API llevándola a otros de sus títulos, como el reciente Thalos Principle y, si todo sale como esperan, también al anterior Serious Sam 3 BFE. Dean Sekulic, programador senior de Croteam, ha aclarado algunas dudas, además de comentar algunas cosas la mar de interesantes Apenas 5 minutos para implementarla. Aunque estuviéramos hablando en "tiempo Valve" queda claro que la implementación de Vulkan es algo relativamente sencillo de hacer. Algo que ya imaginábamos al escuchar que querían incluir la API no sólo en sus nuevos desarrollos, sino de golpe y porrazo también en los antiguos La conversación continúa, tras la captura tan Vulkaniana que nos brinda Dean, con la pregunta clave Al parecer no se conforman con implementar Vulkan, también realizarán una conferencia durante la GDC, uniéndose al grupo de grandes estudios que ya han confirmado su asistencia al evento y, queriendo o accidentalmente, dándonos una nueva pista sobre cuándo podríamos tener Vulkan en nuestras manos. Aunque la respuesta oficial es, simplemente http://www.croteam.com/talos-principle-will-support-vulkan-first-screenshot-released/
  13. 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
  14. 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
  15. 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
  16. Hemos hablado largo y tendido sobre Vulkan, la API gráfica abierta del grupo Khronos que será el futuro de los gráficos generados por ordenador y que, según sus integrantes estará finalmente entre nosotros antes de que acabe el presente año. Mucho se ha hecho de rogar, aunque hay que comprender que una API multiplataforma que sea verdaderamente un estándar, funcione en cualquier dispositivo, asegure cierta retrocompatibilidad y nos brinde todas las ventajas en rendimiento que tanto hemos oído no es una tarea sencilla ni mucho menos. Se han sucedido los eventos y conferencias donde nos han puesto los dientes largos con charlas y demostraciones en vivo muy prometedoras, pero hasta seguíamos a la espera, sin saber cuándo podríamos por fin empezar a beneficiarnos de las ventajas de Vulkan. Tanto Intel como Nvidia han asegurado soporte desde el primer día para la API en GNU/Linux, pero parece ser que ni siquiera ellos pueden contener la emoción y la última versión de la serie 358 de Nvidia ha abierto la veda de Vulkan, añadiendo referencias, librerías y funciones relacionadas con dicha API. Los nuevos controladores 358 incluyen un gran número de librerías VK (vulkan Api), Pascal y Volta. Aunque por ahora sólo conocemos los cambios referentes a la versión para Windows (358.66), como viene siendo habitual, los controladores para el resto de plataformas llegarán en los próximos días. Sin bien estamos ante una noticia a medias, pues no tenemos nada concreto sobre Vulkan aún, tanto movimiento por parte de los fabricantes sólo puede hacernos pensar que debemos estar ya muy cerca del lanzamiento http://forums.laptopvideo2go.com/topic/31826-nvidia-geforce-driver-35866-adds-vulkan-pascal-and-volta-support/
  17. 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
  18. El grupo Krhonos debe tener algún problema con las tuberías de la sede, pues ha acabado fichando al fontanero más famoso de todos los tiempos para que les eche una mano :lol: Cada vez son más las compañías, estudios y desarrolladores que ven el potencial de los estándares abiertos y unen sus fuerzas con el grupo Khronos para impulsarlos y adoptarlos. Si bien en esta ocasión ha sido una adición que no ha hecho demasiado ruido, ni siquiera un anuncio oficial todavía, es un placer ver que, estando Vulkan a la vuelta de la esquina, los pesos más pesados del mundo del entretenimiento gráfico no quieren perdérselo. No es ni remotamente el miembro más extraño, irónico e impactante del grupo, pero sí uno de los que íbamos echando en falta, especialmente cuando, hasta ahora, todas sus consolas se han beneficiado de OpenGL para cautivar a los jugadores. Ahora sólo nos queda una pregunta ¿Cómo se verá el próximo Mario con Vulkan? https://www.khronos.org/members/contributors/nintendo-co.-ltd
  19. 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
  20. Este mes de Agosto, desde el 9 y hasta el pasado día 13, se ha celebrado el Siggraph 2015, la feria donde los pesos pesaos de sector de los gráficos computerizados nos muestran las novedades del sector y de paso nos dejan con la boca abierta. Lamentablemente, aunque Vulkan, La nueva API gráfica abierta del grupo Khronos, fue una de las grandes protagonistas del evento, al final no ha ocurrido lo que todos esperábamos. Vulkan aún no ha sido lanzada oficialmente, peor sí que sabemos que la tendremos entre nosotros en breve, antes de que acabe el año. La siguiente fecha clave a la que apuntan todo los rumores no sólo sobre Vulkan sino con casi todo lo que tiene que ver con gráficos por ordenador, pasa a ser Octubre, cuando tendremos otro evento cumbre para Linuxeros y gamers, la salida, por fin, de las dos grandes apuestas de Valve, Steam OS y Steam Machines. Como comentábamos hace unos días, aunque no tenemos Vulkan, las APIS actuales del grupo Khronos sí que han sufrido cambios, brindándonos nuevas versiones, especificaciones y extensiones de OpenGL 2015, OpenGL ES 3.2 y la promesa de la llegada de la esperada WebGL 2.0 también antes de que acabe el año. Google e Imagination technologies nos han puesto los dientes largos, el primero al asegurar que la próxima versión de Android se beneficiará de todas las ventajas de Vulkan y el segundo, al demostrar el enorme aumento de rendimiento que esto supone: Epic Games y otros grandes del sector de los videojuegos y el entretenimiento digital también se han deshecho en elogios hacia la API y mostrado un total compromiso a la hora de adoptarla desde el mismo instante en que ésta sea oficialmente liberada. Unreal Engine 4 cuanta ya con soporte para Vulkan, al menos hasta el punto donde esta se encuentra ahora mismo y a falta de la salida de sus especificaciones finales para poder poner apunto todos los detalles. Samsung también nos ha asegurado que Tizen será una de las primeras plataformas que contarán con soporte para Vulkan. No obstante, no todo ha sido risa y jolgorio, pues nos ha pillado un poco por sorpresa la decisión tomada por la gente de Unity de no trabajar con Vulkan para centrarse en las APIs cerradas, como Metal de Apple, terminando su conferencia con un vago "no estamos trabajando en Vulkan por el momento, pero lo tendremos presente". Una decisión que no sólo nos deja estupefactos a linuxeros y gamers, sino que choca frontalmente con la decisión de Google de ir a por todas con Vulkan, siendo precisamente Android una de las plataformas donde más presencia está ganando el motor gráfico Unity últimamente. Al margen de la polémica y siguiendo con los más destacados del Siggraph, LunarG puso el punto y aparte con LunarXchange, un portal de soporte para el desarrollo centrado en Vulkan y que nace gracias al patrocinio de Valve. https://www.youtube.com/watch?v=LyyKj2LJ0E0 Aunque lo damos por hecho, también se ha hablado sobre GNU/Linux, siendo la plataforma por excelencia para las APIs abiertas y no sólo eso, también nos confirman que no habrá ningún impedimento para poder explotar Vulkan desde Wayland, X11 o cualquiera que sea nuestro servidor o entorno gráfico. Dado que parece que nos hemos convertido unos expertos a la hora de "esperar", ya sólo nos queda hacer lo que mejor sabemos porque sin duda alguna el último trimestre de este año será un no parar para gamers, linuxeros, desarrolladores y entusiastas. https://www.khronos.org/vulkan
  21. Por fin tenemos un vídeo, aunque la calidad deja mucho que desear, sobre la conferencia realizada sobre la nueva PI gráfica del grupo Khronos Vulkan, durante el GDC 2015. Mas de hora y media de presentación que nos revelará muchos de los entresijos de esta nueva tecnología, así como las de sus acompañantes, Spir-V y OpenCL 2.1 Y para no perdernos, también tenemos disponibles las transparencias desde la página oficial del grupo https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
  22. El GDC 2015 está siendo increíble, la cantidad de novedades y nuevas tecnologías que se han presentado en apenas dos días que llevamos es abrumadora, pero más lo ha sido la presentación oficial de la nueva API gráfica abierta y multiplataforma del grupo Khronos que nos acompañará durante los próximos años. Vulkan ha llegado con fuerza a San Francisco y junto a ella hacen su entrada también OpenCL 2.1 y SPIR-V, el lenguaje que ejercerá de intermediaro. Vulkan, para quien no lo conozca aún, es un estándar abierto que nos da acceso a una computación gráfica altamente eficiente en GPUs modernas. El diseño de la API, previamente conocida como OpenGL Next, ha sido llevado a cabo de manera conjunta por los mayores representantes del sector y permite a las aplicaciones un control directo de la aceleración gráfica de la GPU maximizando así la eficiencia y la predictibilidad. Vulkan nos asegura Control directo de las operaciones de la GPU, con un mínimo consumo por parte de los driver, maximizando el rendimiento Arquitectura Multi-threading-friendly para incrementar el rendimiento general del sistema. Diseñada para ser utilizada un una amplia variedad de dispositivos, incluyendo equipos de escritorio, consolas, teléfonos móviles y sistemas integrados. Hace uso del nuevo lenguaje intermedio para representación flexible de sombreado y controladores gráficos simplificados Arquitectura de capas extensible que posibilita la inclusión de herramientas innovador sin que implique un impacto en el rendimiento mientras se realiza el debbuging o el análisis de rendimiento Controladores simples para asegurar un bajo consumo, alta eficiencia y portabilidad entre los distintos fabricantes. https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf https://www.khronos.org/registry/spir-v/papers/WhitePaper.pdf Se empiezan a difundir algunos de los demos, aunque tendremos que esperar un poco más para que todo el material vaya siendo liberado, tanto especificaciones más concretas como controladores, herramientas y benchmarks. Y como el demo como tal no es que nos dé muchos datos, la comparativa del uso de la CPU corriendo el demo con Vulkan frente a OpenGL es esta: Para más detalles, la gente imagination han dedicado una entrada completa a este Benchmark, que crearon ellos mismos http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus Por supuesto no podían faltar una palabras al respecto del propio Gave Newel Y vamos a terminar con una foto "de grupo" de los que han hecho posible que desde hoy mismo podamos disfrutar de Vulkan P.D. Recordemos que la presentación oficial, aunque hoy tengamos ya todo esto en nuestro poder, es el día 5 de Marzo y es cuando Epic Games, Valve, Unity y algunos más sacarán toda la artillería https://www.khronos.org/news/press/khronos-reveals-vulkan-api-for-high-efficiency-graphics-and-compute-on-gpus https://www.khronos.org/vulkan
×
×
  • Crear Nuevo...