Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'API'.

  • 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. Tras la XDC2016, el debate sobre el futuro de Wayland, GBM, EGLStreams y los controladores de Nvidia, sigue en el aire, pero las conversaciones continúan y vamos aclarando algunas cosas. Recordemos que la polémica surgió cuando Nvidia desarrolló una nueva línea de controladores gráficos pensados para explotar todas las bondades de Wayland, apoyándose en el estándar libre EGL, o más concretamente EGLStreams. Esto no sentó bien a la comunidad de desarrolladores, tanto de controladores libres como de entornos gráficos y administradores de ventanas, pues hasta ahora se habían centrado en desarrollar todo alrededor de GBM (Generic Buffer Management), "exclusivo" de los controladores MESA. La nueva aproximación "más abierta" de Nvidia implicaría o bien un giro raical en la dinámica con la que se venían desarrollando las aplicaciones gráficas para Wayland hasta ahora o un enfoque más conservador, duplicando esfuerzos y manteniendo GBM junto con EGLStreams simultáneamente. Mientras que por el otro lado, Nvidia se enfrentaría a tener que rediseñar sus controladores, con algunos problemas añadidos debido a conflictos legales entre licencias. En definitiva, un callejón sin salida para ambas partes, que deben ponerse de acuerdo para encontrar una nueva vía que dé solución al problema. James Jones ha hablado sobre esto en la conferencia que realizó en el XDC, en el que insiste, una vez más, que lo que pretende Nvidia es apostar por una solución agnóstica, tanto para fabricantes, kernels, sistemas de ventanas, a la vez que se ofrecería un escenario gráfico con optimización para optimización para cada fotograma representado. Está claro que se trata de un gran reto para Wayland en este momento, pero hay que mirar con un punto de vista mucho más amplio, buscando optimizar la asignación de memoria para todos los dispositivos. Y para ampliar un poco más esta idea, que a priori parece más que razonable, nos ha hablado de las posibles alternativas que existen en este momento. GBM Es la manera utilizada actualmente por los compositores Wayland. Proporciona asignación de buffer, arbitraje y handlers. La principal ventaja es, como no, que ya se encuentra implementado y lleva mucho tiempo de desarrollo y testeo. Las deficiencias que presenta en la presentación es que los procesos que maneja son estrictamente locales, se centra excesivamente en la GPU y el arbitraje es dentro del alcance de dispositivo Gralloc Es la aproximación del sistema Android.Proporciona asignación de buffer, arbitraje, handlers, además de sincronización y out-of-process handles, pero requiere otros componentes. Al igual que el anterior, ha sido ampliamente probado, es una especificación de uso de tiempo de asignación y soporte utilización no-gráfica. En cuanto a defectos tenemos un arbitraje limitado, gestión de estado de la superficie no explícita y partes privativas/cerradas. DMA-BUF Proivee handles y trabaja con dispositivos no-gráficos, pero no no existe una API centralizada de asignación del espacio de usuario, sólo funciona en GNU/Linux, no describe la disposición del contenido, carace de arbitraje y la especificación de uso de tiempo de asignación es limitada. Vulkan Aunque la API presenta multitud de beneficios evidentes, además de contar con asignación relativa de interfaces, manejo de estado y sincronización. Pero es graphics/compute/display-only cerente de cross-process/cross-API/cross-device handles o arbitraje. EGLStreams La alternativa impulsada por NVIDIA soporta asignación, handles, manejo de estado y sincronización. Está siendo probada, es portátil y con amplias/extensas capacidades integrales. El principal escollo del estandar abierto es que cada fabricante lo implementa a "su manera", no existe soporte multidispositivo, se asienta sobre EGL, hay un montón de encapsulación y su comportamiento puede variar en ciertas áreas. Con esto en mente, Jones espera que la comunidad de desarrolladores pueda enfocarse en concebir una API más óptima y minimalista, que sea portable, soporte más que únicamente GPUs, a la vez que garantice un buen rendimiento, soporte transiciones de diseño de imagen, maneje las capacidades de negociado de imagen del controlador y mucho más. En definitiva, una crear una API universal y completa para otros clientes y sistemas de ventanas, para una optima asignación de memoria/superficie. https://www.x.org/wiki/Events/XDC2016/Program/Unix_Device_Memory_Allocation.pdf
  3. 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.
  4. 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/
  5. 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
  6. 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/
  7. 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
  8. 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
  9. 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
  10. 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/
  11. 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
  12. Hemos pasado meses oyendo hablar sobre Vulkan a través de las conferencias de numerosos fabricantes y desarolladores, a excepción de AMD que había permanecido en silencio, hasta ahora. La XDC2015 de Toronto ha sido el escenario propicio para que los californianos nos pongan al día sobre sus planes de futuro acerca de Vulkan y su nuevo concepto de controladores AMDGPU. Según nos cuentan están trabajando en optimizar el planificador GPU, nuevos componentes para el administrador de energía (para gráficas Volcanic Island) y de pantalla, así como el soporte para nuevo Hardware. Otro de los objetivos es que las partes relacionadas con Vulkan y OpenCL, que al parecer ya existen y utilizan DRI3, pasen a ser Open Source, aunque esto último no se hará de entrada sino de forma paulatina. A pesar de que se esperan numerosas e interesantes actualizaciones para los controladores AMDGPU, apenas hay cambios en cuanto a plan original que ya conocíamos en lo referente al Hardware. Las series actuales y antiguas de AMD no serán soportadas, sólo a partir de la arquitectura Tonga y APUS Carrizo o posteriores. Aunque tras conocer algunos detalles más sobre los planes de futuro de AMD, nos vamos con más dudas que respuestas, es interesante ver este cambio de rumbo hacia una estrategia más colaborativa y abierta entre la comunidad de desarrolladores libres y AMD. Esperemos que éste sea ya, por fin, el punto de inflexión que nos haga pasar del paupérrimo soporte ofrecido hasta ahora para los usuarios linuxeros a poder tener los merecidos controladores eficientes y capaces que llevamos tantos años esperando. http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
  13. 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
  14. 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
  15. 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
  16. Para despedir el año el Grupo Khronos, durante el SIGGRAPH asiático celebrado durante el pasado Diciembre, nos ha hablado sobre la actualidad y el futuro de las APIs gráficas abiertas http://www.slideshare.net/slideshow/embed_code/42464487
  17. Artículo original de Sebastian Anthony en ExtremeTech Seguimos con la saga Khronos... En Siggraph 2014, el Grupo Khronos ha anunciado tanto OpenGL 4.5 como la Iniciativa OpenGL Next Generation. OpenGL 4.5, a excepción de algunas nuevas características de Direct3D 11 de emulación para una fácil portabilidad, es su actualización anual estándar de OpenGL. OpenGL Next Generation (OpenGL NG) sin embargo, es una reconstrucción completa de la API OpenGL. La idea, al igual que la intención de AMD Mantle y DirectX 12, es la construcción de una versión completamente nueva de OpenGL que elimine gran parte de la abstracción, lo que reduciría significativamente los consumos y las ineficiencias cuando se trabaja a bajo nivel sobre el hardware de la GPU. No obstante, Khronos tiene un difícil reto por delante que superar: Mientras que AMD y Microsoft se centran en sus propias implementaciones específicas, OpenGL NG será una solución multiplataforma para todos los sistemas operativos y los fabricantes de hardware, al igual que las especificaciones de OpenGL existentes. Con más de 22 años en su haber, OpenGL (originalmente publicado por SGI en 1992) es la más antigua de las API de alto nivel de gráficos 3D todavía en uso masivo. Al igual que DirectX (que es sólo un poco más joven), OpenGL se ha ganado una elevada reputación en los últimos años. Aún más importante, OpenGL --al igual que DirectX y Direct3D-- es un API de muy alto nivel que hace que sea difícil de ejecutar de manera eficiente el código en la GPU directamente. Esto no importaba tanto en los viejos tiempos, cuando las GPU eran cosas desagradables que necesitan abstracción de alto nivel para ser programadas de forma eficiente. Pero ahora, como las GPUs son cada vez un producto más maduro y desarrollado con mayor sensatez y ampliamente documentado, los desarrolladores están pidiendo APIs gráficas que les permitan conseguir estar mucho más cerca del hardware, lo que mejoraría significativamente el rendimiento y reduciría los consumos de recursos. OpenGL NG, será rediseñado «desde abajo» y no será compatible con versiones anteriores de OpenGL. Khronos Group, que desarrolla la especificación OpenGL (y otras especificaciones relacionadas), dice que está trabajando intensamente con todos los miembros de su consorcio para desarrollar unas especificaciones técnicas para que las empleen las empresas de hardware y software. El último intento de Khronos para crear una nueva especificación, no compatible con versiones anteriores --Longs Peak--, fracasó estrepitosamente por lo que no está dispuesto a cometer los mismos errores dos veces. El paisaje ha cambiado mucho desde «Longs Peak», aunque ahora, con una variedad de APIs de bajo nivel que salen de AMD, Microsoft, e incluso Apple, parece que los desarrolladores están dispuestos a romper con los duros días de la abstracción de antaño. A propósito, Longs Peak nunca vio la luz del día ya que fue destrozado en 2007 y sustituido por el mucho más "normal" y compatible OpenGL 3.0 en 2008. En declaraciones públicas, Khronos admite que se ha fijado una tarea muy desalentadora para sí mismo. Aún así, Khronos parece contar con la mayoría de las personas adecuadas a bordo (la única omisión significativa es Microsoft). «Es agradable ver una gran cantidad de proveedores de software, tales como Valve, Epic, Blizzard, y Unity, implicados en el proyecto. El desarrollo del juego es cada vez más multi-plataforma; estoy seguro de que a los desarrolladores le encantaría dirigir OpenGL NG y tener sus juegos funcionando en la mayoría de las plataformas... Aunque, por supuesto, eso sólo funcionará si el soporte de hardware está ahí». Esto encaja perfectamente en otro punto relevante: Khronos también admite que, debido a OpenGL NG tendrá que trabajar a través de múltiples GPUs y no podrá ser físicamente a tan bajo nivel como AMD Mantle. Khronos confía en que todavía pueda ofrecer reducciones significativas de consumo y aumentar las prestaciones aun siendo multiplataforma. Teniendo en cuenta sus diferentes enfoques en alcanzar más o menos el mismo objetivo, será interesante averiguar cómo lo resuelven AMD Mantle, DirectX 12 y OpenGL NG. No parece existir una línea temporal definida para el lanzamiento de OpenGL Next Generation, pero no parece que vaya a ser pronto. Está previsto el lanzamiento de DirectX 12 hacia el final de 2015, y la opinión general es que a Khronos le gustaría desembarcar OpenGL NG más o menos al mismo tiempo, pero puede ser que se demore algo más. Muchos comentaristas y observadores sepreguntan por el destino de AMD Mantle ahora que tanto Microsoft como Khronos se han metido a fondo en la lucha. Los cambios que anuncia OpenGL 4.5 están contenidos en la documentación publicada en su lanzamiento. Aunque realmente no hay muchos salvo algunas nuevas características que ayudan a portar aplicaciones entre entornos para móviles y de escritorio, y entre DirectX 11 hacia OpenGL 4.5), y algunas limpiezas generales de API para su alineamiento y correlación para acercar a las diferentes especificaciones de OpenGL: OpenGL, OpenGL ES, WebGL.
  18. Seguimos recibiendo noticias de Valve, cuya apuesta por un nuevo ecosistema en el mundo de los videojuegos y el PC sigue cada vez con más fuerza. Si hace poco anunciaban Steamworks VR API, una nueva propuesta para llevar la realidad virtual a los videojuegos y que otras interesantes apuestas como Oculus Rift puedan ser utilizadas por cualquier jugador y desarrollador para enriquecer aún más la experiencia de juego, ahora han decidido iberar el código fuente de esta API para ponérselo aún más fácil a quien quiera adaptarla. Al mismo tiempo, en la versión Beta de su cliente Steam ya está disponible SteamVR para descargar entre la lista de herramientas para todo aquel que quiera empezar a sacarle partido. El código fuente de esta nueva API podemos conseguirlo, como no, a través de github https://github.com/ValveSoftware/steamworks-vr-api
  19. Sin duda alguna, AMD consiguió conmocionar a la industria hace apenas dos meses con su nueva API gráfica a la que han apodado "Mantle". Durante su presentación inicial no desvelaron casi ningún detalle, sólo una idea general de lo que pretendían conseguir con esta API, que según sus responsables se diferenciaba de las APIs gráficas tradicionales por ser de bajo nivel (Close to metal) permitiendo así atender hasta 9 veces más peticiones por segundo que las APIs de alto nivel como, por ejemplo, OpenGL, lo que supondría una increíble mejora en cuanto a rendimiento gráfico se refiere. Esta API, según nos cuentan, aboga por la facilidad y transparencia, haciendo la vida más fácil a los desarrolladores y permitiendo mayor libertad, abaratando los costes de desarrollo, etc Sin embargo, fuer de estas promesas no sabíamos nada acerca de esta nueva API, salvo algunos pequeños detalles que nos dejaron sus responsables, como que sería compatible con Microsoft HLSL y NO con OpenGL, que estaban colaborando estrechamente con DICE y su motor gráfico Frostbite y que estaba enfocada en hardware muy concreto, las AMD Radeon con arquitectura GCN (Graphic Core Next). Durante esta semana, en la AMD developer submit 2013 celebrada en el centro de convenciones de San José, se han realizado numerosas presentaciones y conferencias en las que AMD ha dado a conocer más detalles sobre su nueva apuesta de futuro. EDITO Tengo que hacer una puntualización aquí debido a un pequeño malentendido. La presentación a la que hago referencia no fue hecha por AMD sino por DICE, es decir, no es exactamente la visión que tiene la compañía Roja para con Mantle, sino un interpretación propia que nos hace DICE No obstante, si bien han hecho una presentación más larga y concisa, a primera vista parece que contradicen muchas cosas que se habían dicho anteriormente. Y sí, admito que he empezado a ver la presentación pero no he podido acabarla, parecía más un anuncio de teletienda que otra cosa, con muchas promesas y posibilidades salpicados con algunos datos sueltos de vez en cuando pero nada del otro mundo, así que vamos directos al grano apoyándonos en las diapositivas mostrada, que tenemos disponibles gracias a Planet3DNow (¿Algún germanoparlante en la sala?) pues esté sí muestra algunas cosas "interesantes". En primer lugar vemos un cambio de rumbo claro y si antes remarcaban la compatibilidad con M$ HLSL, ahora son las plataformas *Nix las que cobran importancia, incluyendo lo que podemos calificar de llamada de atención desesperada hacia Valve para que no los dejen fuera de Steam OS Y también apuestan por el cada vez más relevante mercado de los dispositivos móviles buscando hacer la competencia directa a OpenGL ES que es el que domina la situación actualmente en este sector Ahora es cuando la situación se torna extraña, empiezan las contradicciones y nos dejan aún más confusos que antes y es que lo ponen bien claro desde el principio. Mantel está diseñado como una "fina" capa de abstracción que no está atada a la arquitectura GCN de AMD, pudiendo ser soportada por la mayoría de tarjetas gráficas recientes y con extensiones específicas para todas las plataformas y arquitecturas actuales. Esto es justo lo opuesto a lo que nos contaron en la presentación inicial y se aleja totalmente del concepto "close to metal" que nos habían vendido. De hecho, si la primera descripción que hicieron de Mantle nos hizo equipararlo con el extinto 3dfx GLide o la actual NVApi, tal y como nos lo cuentan ahora, más parece un equivalente exclusivo AMD a la actual OpenGL. A partir de aquí empezamos con la parte más "técnica", en las que equiparan Mantle con las actuales APIs gráficas y nos hablan de sus ventajas y las diferencias a la hora de trabajar con con Mantle en lugar de con las APIs tradicionales. Hacen hincapié en la desaparición de los cuellos de botella, la disminución de la latencia, el escalado lineal con los núcleos de la CPU y el trabajo en paralelo, así como la simplificación de los drivers, evitando sobrecargas e hilos de ejecución innecesarios. Y también, como no, un pequeño spot publicitario de DICE Luego nos hablan del nuevo modelo de desarrollo en comparación con el actual, abogando por la transparencia, la documentación explícita, la interacción sencilla y el acceso más directo a los recursos disponibles. Mientras el modelo tradicional es definido como una "Caja Negra" (Aquí hemos saltado a DirectX), Mantle se muestra como explícita, flexible y eficiente, permitiendo saber y manipular cada pequeño detalle de cada proceso. Pipelines monolíticos, todo se combina en un único objeto, lo que significa que la compilación o parcheado no son necesarios durante la ejecución, lo que supone una carga mucho menor Soporte para construcción y cacheado en paralelo, lo que supone tiempos de carga menores. Uso y administración en la capa de aplicación Todo esto supone una mejora de rendimiento de la GPU evitando cuellos de botella y evitando el renderizado por fuerza bruta, otorgan mayor grado de flexibilidad a los drivers y evitan a las aplicaciones las transiciones redundantes Para terminar, se centran en cómo funcionan las gráficas actuales, que trabajan de manera heterogénea, y cómo se distribuye la asignación de recursos a las distintas actividades. Imagino que aquí volverían a hablar de esas "9 veces más peticiones que las APIS tradicionales". Y cerramos con un último anuncio de DICE, esta vez con una imagen que muestra cómo hubiera sido Plants VS ZOmbies si hubieran hecho uso de esta tecnología :lol: La conclusión es... bueno... no hay ninguna conclusión salvo que han cambiado de opinión en muchos aspectos desde Septiembre hasta ahora o, simplemente, nos han contado dos películas diferentes y seguimos sin saber aún qué es Mantle, cómo funciona o qué repercusiones tendrá. El único aspecto positivo que podemos sacar de todo esto es que parece que ha pasado de ser una API completamente cerrada y exclusiva a algo multiplataforma, así que dentro de lo malo deberíamos poder llegar a usarlo todos los usuarios y no únicamente los poseedores de una GPU GCN compatible en una versión muy concreta de un sistema operativo en particular bajo las estrictas condiciones de AMD como parecía haberse planteado en un principio. Lo que podemos pensar es que, al haberle llevado un portazo en las narices por parte de M$ y $ony de cara a formar parte en el desarrollo de títulos para las consolas de próxima generación, han puesto a Mantle en una posición delicada y lo que en un principio sacaron a la luz como una jugada maestra se ha convertido en una tímida apuesta que dependerá completamente de lo bien que se lleven con Valve, el apoyo que reciban de otros fabricantes y si los desarrolladores están dispuestos a trabajar o no con otra API más. EDITO Al ser palabras de DICE y no directamente de AMD, no podemos tener una visión clara de lo que verdaderamente pretende esta última, pero al menos esto supone una confirmación del interés por parte de DICE para traer un título "rompedor" a GNU/Linux, portanto FrostBite y apostanto por Steam OS :cheers: http://www.planet3dnow.de/cms/5720-apu13-andersson-will-mantle-fuer-alles-und-jeden/
  20. 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.
  21. GNUstep fue iniciado hace 15 años, con el fin de implementar el estandar OpenStep. Como muchos sabrán (o no) OpenStep se convirtió en el corazón de los ahora es Cocoa, establecido en corazón de Mac OS X y todos los dispositivos iOS. El propósico original de OpenStep era ser multiplataforma, pero esto se acabó cuando Apple se fusionó con NeXT en 1996. Tras esto, la meta de GNUstep fue continuar Cocoa, pues esta representa la continuación de las APIs OpenStep y su intención es que funcionae perfectamente en todas las plataformas posible. Con este fin, sus responsables buscan financiación en Kickstarter, pera poder refinar las herramientas de desarrollo actuales, permitiendo a los desarrolladores crear aplicaciones para cualquier plataforma, no Sólo Mac OS X, conseguir que GNUstep funcione bien en todas las plataformas donde corre actualmente y completar los trabajos para que sea totalmente compatible, al menos con la versión de la API Cocoa disponible en 10.6 http://www.kickstarter.com/projects/203272607/gnustep-project
  22. El grupo Khronos ha anunciado el lanzamiento de OpenGL 4.4, la cual proporciona las últimas funcionalidades gráficas, que nos brinda el hardware de última generación, pero eso sí, manteniendo la compatibilidad con las versiones anteriores, pudiendo utilizar las nuevas características incorporadas de manera incremental a lo que ya tuviéramos hecho con las API. Por otro lado, OpenGL 4.4 define una nueva funcionalidad para simplificar la migración de aplicaciones desde otras plataformas y APIs. La lista completa de especificaciones y materiales de referencia ya están disponibles para su condulta en la página oficial del grupo: https://www.opengl.org/documentation/current_version/ Además de las especificaciones de OpenGL 4.4, el grupo de trabajo OpenGL ARB (Architecture Review Board) de Khronos ha creado el primer conjunto de tests formales OpenGL 2.0, mediante el cual Khronos ofrecerá certificación de drivers desde la versión 3.3. La certificación completa es obligatoria para OpenGL 4.4 y posteriores. Esto ayudará a reducir las diferencias entre los drivers OpenGL de diferentes desarrolladores, resultando en una mejor compatibilidad entre versiones. Como respuesta a esto, Nvidia ha lanzado los nuevos controladores 325.05.03 que nos brindan soporte para OpenGL 4.4, así como las acostumbradas correcciones de errores y algunas mejoras. Las tarjetas compatibles con OpenGL 4.0 y LSL 4.40 son las siguientes: Quadro series:K600, K5000, K4000, K2000D, K2000, 6000, 600, 5000, 410, 4000, 400, 2000D, 2000 GeForce 700 series:GTX TITAN, GTX 780, GTX 770, GTX 760 GeForce 600 series:GTX 690, GTX 680, GTX 670, GT 645, GT 640, GT 630, GT 620, GT 610, 605 GeForce 500 series:GTX 590, GTX 580, GTX 570, GTX 560 Ti, GTX 560 SE, GTX 560, GTX 555, GTX 550 Ti, GT 545, GT 530, GT 520, 510 GeForce 400 series:GTX 480, GTX 470, GTX 465, GTX 460 v2, GTX 460 SE v2, GTX 460 SE, GTX 460, GTS 450, GT 440, GT 430, GT 420, 405 Nuevas extensiones OpenGL Para hardware compatible con OpenGL 4: ARB_buffer_storage ARB_clear_texture ARB_query_buffer_object Para hardware compatible con OpenGL 3: ARB_enhanced_layouts ARB_multi_bind ARB_texture_mirror_clamp_to_edge ARB_texture_stencil8 ARB_vertex_type_10f_11f_11f_rev Nuevas extensiones ARB Para GeForce 6xx y superiores): ARB_bindless_texture ARB_seamless_cubemap_per_texture Para hardware compatible con OpenGL 4: ARB_compute_variable_group_size ARB_indirect_parameters ARB_shader_draw_parameters ARB_shader_group_vote ARB_sparse_texture NV extensions: NV_blend_equation_advanced NV_bindless_multi_draw_indirect NV_gpu_program5_mem_extended Descarga Linux x86 Linux x86_64 FreeBSD 32-bit FreeBSD 64-bit
×
×
  • Crear Nuevo...