Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'nvidia'.

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

  1. Buenas a todos, como no me corre ninguna prisa y hace tiempo que no posteo, queria dejar esto por aqui. Resulta que instale LMDE3, como siempre en mis distros debian, tambien instalo liquorix, y normalmente lo suelo acompañar del driver nvidia con dkms.... para mi es una combinacion ganadora, con la que pocas veces he tenido problemas, el caso es que ahora, por mas que instalo el driver nvidia "nvidia-kernel-dkms", me hace la compilacion o la carga de los modulos correctamente en el kernel sin mostrarme ningun error. Pero nada, que no hay manera, y si intento levantar xorg a mano, me dice que no puede. tambien probe a ejecutar el nvidia-xconfig a mano y nada. por supuesto, noveau y todo lo relacionado al driver libre, se encuentra desinstalado y en la blacklist. el caso es que no consigo tener entorno grafico ni con un kernel ni con otro... alguna idea?
  2. Pues es una pregunta tonta que hago en función de que pocas veces he tenido tantas opciones mirando el Drivers adicionales de Ubuntu, solia ir con tarjetas ya sin soporte. A ver os pongo una imagen y quisiera saber si escogeriais otro que aquel que yo tengo que es el de codigo abierto → Los juegos yo creo que me van bien y recuerdo haber dejado los nouveau para poder en Blender hacer uso del cuda que creo yo que al instalar otros drivers no me dejaba poner esa opción o no se configuraba pero que recuerde no tenia tantas entradas de posibles drivers compatibles. Pues es eso un poco para aprender si seria mejor para esto una version o para aquello otra. Eso es amigos. Saludos a todos.
  3. erremartin

    Elección de distribución

    Hola, amigos... Compré hace un par de años un Lenovo ideapad Y700-17ISK con un I7-6700HQ CPU @ 2.60 GHZ y 8.00 GB de RAM y nvidia gforce gtx 960M Apenas lo uso. Anoche lo encendí tras un par de meses sin hacerlo. Tras una pequeña actualización (le quité la wifi antes de empezar) ahora no puede reproducir archivos mp3 ni mp4. Dice no se que mierda de un valor no válido para el Registro. El caso es que estoy pensando en mandar Windows 10 a freír espárragos. Con qué distribución y escritorio aprovecharé mejor esa gráfica? La idea es usar ese portátil para juegos, ya que para trabajar tengo otro portátil más ligero. Ese Lenovo que digo es de 17 pulgadas y pesa casi 5 kilos, en serio.
  4. Buenas, hoy descubri una cosa muy util, que quiza algunos ya conocereis. para mi ha sido de tal utilidad, que entra en mi lista de tareas a realizar a la hora de poner al dia una distro recien instalada, y por eso lo dejo en el foro, para cuando me entra la fiebre distrohopera... La tarea que nos atañe es muy simple, resulta que hoy en el grupo de manjaro salto la duda, ya que un usuario reporto que su grafica nvidia estaba a 55º y el ventilador marcaba 0, fui a mirar mi grafica y casualmente, marcaba tambien cerca de 50º y RPM a 0. Bien, resulta que los driver de nvidia no hacen saltar los ventiladores hasta la temperatura no supera los 55º grados. Pero tenemos una funcion que podemos añadir al controlador de nvidia y configurar a nuestro antojo, para que los ventiladores funcionen de manera automatica dependiendo de la temperatura que tengamos en ese momento. es muy sencillo: 1- tenemos que añadir la linea "coolbits4", en nuestro fichero de configuracion del driver nvidia, en mi caso al estar en manjaro quedaria asi: # Add to /etc/X11/xorg.conf.d/95-mhwd.conf # Screen Tearing: https://wiki.manjaro.org/index.php?title=Simple_fix_for_screen_tearing_-_nVidia # Nvidia Coolbits: https://wiki.archlinux.org/index.php/NVIDIA/Tips_and_tricks#Enabling_overclocking Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" Option "NoLogo" "1" Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" Option "Coolbits" "4" EndSection siiiiiiiiiiiiii, debajo de la otra magica linea que me enseñasteis que cura mi pantalla del malvado tearing... con esta simple linea, ahora nos aparecera en nuestra pantalla de nvidia settings, una barrita donde podemos elegir la velocidad del ventilador, tal que asi: 2- GUAYYYYYYY!!!, pero os preguntareis, muy bien, ya puedo regular el ventilador a mi antojo, pero como hago que se regule el solito automaticamente??? pues muy simple, un compañero de manjaro se ha currado un pequeño script, que deberemos de ejecutar al inicio de nuestro sistema, yo lo añadi al arranque automatico de plasma5, y buala!. ahora se regula el solito. podeis descargar el script de aqui:https://github.com/Madh93/dotfiles/blob/master/stuff/nvidia/nvidia.conf o copiarlo y crear vosotros el vuestro modificando los valores por los que deseis, para mi esta bien asi. como podeis ver, he pasado de tener la grafica siempre entre 50/55º, ha tenerla en 35º con el ventilador a menos de 900rpm, que no hace nada de ruido, yo lo prefiero asi, la verdad, creo que el hardware/gpu sufrira menos y vivira mejor. teneis mas info aqui: https://wiki.archlinux.org/index.php/NVIDIA_(Espa%C3%B1ol)#Ajustar_la_velocidad_del_ventilador_en_la_sesi.C3.B3n
  5. A principios de 2017 Nvidia donó DRIVE Design Sudio a Qt, el cual ha servido como base para Qt 3D Studio, que ya está disponible a modo de Pre-Release. Se trata de una herramienta de diseño de interfaces de usuario 3D multiplataforma al tratarse de una aplicación Qt. Es capaz de importar recursos de diseño desde otras aplicaciones como Autodesk Maya, Adobe Photoshop o FOundry Modo, además de contar con una extensa biblioteca propia de efectos y materiales. Hace posible el prototipado rápido mediante animaciones gracias a su potente editor de línea de tiempo. Además, como no podía ser de otra forma, se integra perfectamente con Qt Quick y otros módulos del Framework Qt Es por esto que es muy sencillo crear interfaces de usuario 3D en tiempo real mediante Qt 3D Studio Durante los últimos meses se ha estado trabajando en portar la interfaz desde MFC a Qt y llevar a cabo otras tareas de mejora en lo referente al aspecto y diseño de la aplicación. La API Qt/QML ha sido ampliada y se ha desarrollado toda una nueva API C++, además de eliminar componentes y dependencias de terceros que incluía el software original donado por Nvidia, para sustituirlos por implementaciones basadas en Qt, minimizando así las dependencias y desechando gran cantidad de código innecesario. La versión 1.0 final de Qt 3D Studio está fechada para principios de Noviembre y para Mayo de 2018 se espera haber completado, en una futura versión 2.0, el proceso de sustitución de todo el código antiguo motor de renderizado de Nvidia por una nueva implementación construida íntegramente sobre Qt 3D, pero manteniendo la compatibilidad con proyectos desarrollados con versiones anteriores de Qt 3D Studio El código fuente de la versión preliminar puede obtenerse desde el repositorio de Qt 3D Studio de qt-project, donde también encontraremos documentación e instrucciones para compilarlo https://codereview.qt-project.org/#/admin/projects/qt3dstudio/qt3dstudio https://codereview.qt-project.org/gitweb?p=qt3dstudio/qt3dstudio.git;a=blob;f=build_instructions http://doc-snapshots.qt.io/qt3dstudio/index.html http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/
  6. Hola amigos, estoy presentado un problema y no encuentro como solucionarlo. Quiero mantener el color de pantalla calibrado. Lo he calibrado con estas dos aplicaciones: - Xcaliber - Nvidia x server settings Pero cada vez que ejecuto por ejemplo un juego en pantalla completa, el color de pantalla vuelve a defaut. osea tengo que volver a calibrar el color. Como hago para que quede predeterminada la calibración que le doy al monitor? Sistema Operativo: LinuxMInt 18.1 Cinnamon.
  7. Pregunta tonta alguien sabe como se hace para que Blender de una vez por todas recoconozca la GPU Nvidia y haga el render por ella ? , ya he leido media web he instalado cudas de distintas versiones que son GB que se baja, no hay manera no se que hacer más.
  8. Dónde puedo buscar información sobre qué placa de video elegir para comprar? Por lo que sé uno puede usar drivers libres o propietarios, y cada uno tiene nombres: Intel: Creo que solamente hay drivers libresAMD: Libre: radeon Propietario: fglrx (Catalyst) Nvidia: Libre: nouveau Propietario: nvidia? Cómo hacen ustedes para elegir GPU? Por lo que leí nvidia tiene los mejores drivers propietarios pero los peores drivers libres. Dónde puedo obtener información actualizada sobre como viene la cosa? O una lista de todas las GPU soportadas para cada driver Varía mucho el rendimiento de los drivers al comparar distitas GPU del mismo fabricante? O se puede decir que por ejemplo todos los GPU nvidia tienen buenos drivers sin excepciones?
  9. Hace ya varios años que Wayland, el protocolo de servidor gráfico que sustituirá al veterano X11, está "por llegar", pero sigue sin hacerlo y es que, aunque cada vez estamos más cerca y ya hay distribuciones que se atreven a incluirlo entre su paquetería, como alternativa o incluso, como servidor gráfico por defecto, aún hay muchos escollos en el camino que hay que solventar para que Wayland puede estar en el escritorio de todos los linuxeros. Entre las tareas pendientes están, como no podría ser de otra manera, la compatibilidad por parte de los distintos controladores gráficos y la adaptación de entornos gráficos, gestores de ventanas, compositores, etc al nuevo protocolo. En este sentido, desde hace más de un año viene desarrollándose y acalorado y enrevesado debate que dio origen con la presentación, por parte de Nvidia, de EGLStream. Por hacer un breve resumen, hasta ahora Wayland ha girado en torno al administrador genérico del buffer GBM, algo que Nvidia, ya por el año 2012 criticó, para un par de años más tarde presentar su alternativa, que es lo que ahora conocemos como EGLStreams. Esto no fue bien recibido por la comunidad, que ya sabemos de sobra que es de mecha corta y desde entonces el conflicto está en el aire. Lo irónico del caso es que, en esta ocasión, la empresa californiana, conocida por tener muy buen soporte pero también prácticas muy privativas, tiene razón. GBM, aún siendo software libre, es de carácter exclusivo y está atado estrictamente a los controladores mesa, mientras que EGLStream se basa en el estándar abierto EGL, es multisistema, multiplataforma y, por lo que hemos podido saber hasta el momento, en cuanto a eficiencia y capacidades técnicas también supone una mejora importante. La problemática reside, precisamente, en ese lapso de tiempo de 3-4 años desde que Nvidia hiciera públicas sus intenciones hasta que finalmente se materializaron, pues todo el trabajo se ha venido desarrollando pensando únicamente en GBM y un cambio a estas alturas significaría replantearse muchas cosas y modificar un gran número de líneas de código. Además, muchos temen que a falta de un consenso acaben teniendo que mantener simultáneamente dos métodos de manejo del buffer para cada compositor, con todo el esfuerzo que ello implica. E incluso hay quien sugiere reinventar GBM para ponerlo a la altura de las características de EGLStreams en lugar de modificar los compositores para que hagan uso de otro administrador del buffer. Aun sin haber llegado a una conclusión clara todavía, parece que Nvidia va ganado adeptos que consideran que apuntar a un estándar universal y abierto, además de más completo y eficiente, en torno a una nueva API desarrollada de manera conjunta, es el camino a seguir. Entre ellos está la gente de Gnome, que ya ha empezado a trabajar para adaptarse lo antes posible. Por si fuera poco y como reza el título de este tema, Nvidia sigue avanzando mientras la comunidad sigue debatiendo y en su última serie de controladores incluye nuevas librerías EGL para Wayland y una interfaz de plataforma externa para EGLStreams, de tal forma que manejo de buffer utilizando EGLStreams podría ser implementado de manera sencilla en cualquier sistema de ventanas sobre plataformas EGL de bajo nivel superpuestas. Concretamente sobre EGL_PLATFORM_DEVICE_EXT, utilizando extensiones EGLStream. Para rematar, nos brindan todo el código fuente de ambos, tanto de la interfaz de plataforma externa EGLStremas como de las librerías EGL para Wayland,incluyen nuevas extensiones Vulkan, sombreado multihilo GLSL y habilitan las optimizaciones OpenGL por defecto (con un sistema de autoajuste que las desactiva en caso de que no supongan una mejora del rendimiento) en el nuevo controlador 378.X. Casi nada... y de fondo la comunidad aún discutiendo:sweat: https://lists.freedesktop.org/archives/wayland-devel/2017-January/032722.html.
  10. Estimados, antes que nada, me presento, soy de Argentina, un placer ser parte del foro. Les comento mi problema: Tengo instalado Linux Mint 32 bits 17. 1 Tengo en el Equipos instalado 2 placas de Video nVidia GT 720, las cuales son detectadas: Necesito hacer funcionar 4 monitores, la idea es usar 2 puertos de cada placa, con Ubuntu, logre que funcionara, pero la app que necesito no corre en ubuntu, en Mint Corre perfectamente, la app funciona, pero no logro hacer andar los monitores. Por ejemplo en Nvidia X Server, veo que me detecta las dos placas, incluso me detecta el monitor en la segunda placa, pero no me lo habilita: Si habilito la placa de forma manual, al reiniciar me arroja un error: Podrían ayudarme? Gracias.
  11. A ver.. os cuento. Como ya sabeís tengo un portátil con un i5 y una gráfica nvidia gt620m, el caso es que esta viene con el optimus y claro me han dicho que es mejor que la instale porque consume menos batería y demás. Actualmente estoy usando los controladores libres por defecto de elementary os pero para jugar emular y demás necesito los drivers gráficos.
  12. 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
  13. Aunque hace tiempo que me decidí por no sucumbir a polémicas a la hora de escribir, en este caso quiero hacer una excepción, porque es un tema que nos llega de cerca a muchos y que podría ser decisivo para el futuro de los entornos gráficos en GNU/Linux Hace muy poco, Nvidia liberó por fin una nueva serie de controladores que, no sólo nos traían Vulkan de manera estable y completamente funcional, sino que nos brindaban soporte para el servidor gráfico Wayland a través de EGL. Algo que llevábamos esperando desde hace ya mucho tiempo. Sin embargo, aunque en principio esta noticia sobre Nvidia suponía un salto importante a la hora de empezar a adoptar masivamente el servidor gráfico Wayland, dejando por fin "de lado" al veterano X11, junto a los controladores oficiales se han liberado una serie de parches de código abierto, que fueron enviados a la comunidad de desarrolladores de Wayland, que no han sido visto con buenos ojos por parte de los desarrolladores del servidor gráfico. Este código, pensado en principio para permitir que Weston, el compositor base de Wayland pueda correr sobre los controladores gráficos oficiales de Nvidia (privativos), ha sido rechazado. El origen de la polémica parece ser la implementación que ha hecho Nvidia, pues se valen directamente de EGL, haciendo uso de las extensiones EGLDevice y EGLStreams para manejar los buffers, mientras que la implementación oficial de Weston utiliza MESA GBM (Generic Buffer Manager). Si bien para algunos, incluida la propia Nvidia, esta aproximación supone un acercamiento más "agnóstico", en lugar de tener que desarrollar una versión alternativa de GBM para su línea de controladores, desde el otro lado sólo ven problemas con la alternativa propuesta por la californiana, al hacer uso de extensiones poco usuales o complicar/simplificar demasiado ciertos aspectos del renderizado. Aunque en principio esto no impide que entornos con compositores propios, como Enlightenment, Hawaii, Orbital, Orbment o incluso alguno de los más conocidos como KDE O Gnome, puedan dar soporte a Nvidia, implementándolo por cuenta propia en sus compositores, dentro del seno de Wayland y de cara al compositor Weston, por ahora las cosas están siendo discutidas de manera muy acalorada y no parece que veamos pronto ningún movimiento, al menos hasta que todos los pormenores hayan sido hablados y el código de Nvidia minuciosamente estudiado. https://lists.freedesktop.org/archives/wayland-devel/2016-March/027547.html
  14. Hola a todos. En mi trabajo tengo conenctado mi ordenador a un proyector, para enviar la imagen a una pantallalla más grande. El problema es que, cuando intento configurar la resolución de mi ordenador para que se vea bien en la pantalla, la imagen queda cortada: Es como si el equipo reconociera la anchura de pantalla que yo quiero, pero mantuviera el tamaño original del ordenador. Mi ordenador tiene instalado xubuntu 16.04 -x64. Tiene instalada una tarjeta gráfica nvidia gforce 8200M G, y uso los drivers privativos. Una cosa curiosa que he observado es que, cuando utilizas Nvidia x server settings, en opciones avanzadas, no me muestra más que la resolución normal del ordenador (1366 x 768), pero, cuando estoy en las opciones básicas, aparecen un montón de resoluciones. ¿Qué puedo hacer para cambiar la de mi ordenador, y que pueda proyectar correctamente en la pantalla? Muchas gracias a todos, por este magnífico blog Foto de nvidia settings ajustes básicos (muchas resoluciones) Foto de nvidia ajustes avanzados (sólo aparece la resolución inicial del ordenador) Foto de mi panel superior. Ahí faltan muchas opciones (widged del tiempo, captura de pantalla, calendario...) que se quedan ocultas en las franjas negras que aparecen en la pantalla de mi ordenador.
  15. Envuelto en un halo de secretismo nos llega este anuncio por parte de Nvidia, que prepara un evento virtual en streaming para mañana a las 2PM hora del pacífico, lo que para los que estamos al otro lado del charco significa tener que esperar hasta el Sábado a las 3 de la mañana Twitch será el escenario elegido por la Californiana para tan extraño evento del que no tenemos más detalles. Los rumores apuntan a la puesta en el mercado de sus gráficas con GPUs de arquitectura Pascal, o al menos dos de las más potentes, conocidas hasta ahora por los sobrenombres 1070 GTX y 1080 GTX. Esto supondría nuevos controladores y toda una avalancha de nuevas tecnologías asociadas, pero como ya he dicho, por ahora todo son conjeturas y realmente no tenemos ni idea de lo que pueden tener preparado para alegrarnos el fin de semana . https://www.twitch.tv/nvidia
  16. 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
  17. Desde hace ya algunos años y tras la compra por parte de Nvidia de Ageia, hemos visto en el mundo de los videojuegos tecnologías llegaban para mejorar la experiencia de los jugadores, a la vez que ponían en apuros a los desarrolladores por sus peculiaridades y carácter exclusivo. Quien más ha invertido en este tipo de tecnologías ha sido indiscutiblemente Nvidia, que empezó con Physx y ha terminado creando todo un ecosistema de efectos visuales bajo el nombre de Gameworks. Si esto bien ofrece un mundo de posibilidades a los desarrolladores a la hora de llevar más allá sus títulos, su carácter cerrado y exclusivo suponen una gran traba para todos. Durante el GDC de 2015 hizo un movimiento bastante sorprendente liberando el código de Physx, así como su kit de desarrollo. Siguiendo esta misma tendencia, pero yendo mucho más allá, AMD recientemente quiso "contraatacar" con GPUOpen, una iniciativa que busca ofrecer algo similar a la plataforma Gameworks de Nvidia, pero de carácter abierto. En la misma línea, probablemente influenciados por el lanzamiento de GPUOpen y, para no romper con la tradición, también durante el GDC, Nvidia ha comenzado a liberar los componentes Individuales de Gameworks, empezandoando porNvidia Volumetric Lighting y FaceWorks, a los que acompañan documentación y ejemplos. Al mismo tiempo también han asegurado que HairWorks, HBAO+ y NVIDIA WaveWorks seguirán el mismo camino muy pronto. Es esperanzador ver como el panorama general va cambiando y Nvidia, conocida antaño por sus políticas extremadamente cerradas y exclusivas, empieza a abrirse y a apostar por un nuevo modelo de negocio y AMD parece que también quiere abandonar sus costumbres "pasotas" e indiferentes para ponerse las pilas de una vez. https://developer.nvidia.com/content/introducing-nvidia-gameworks http://gpuopen.com/
  18. Hace ya tiempo que hablamos de GLVND (OpenGL Vendor-Neutral Driver) una ABI que permitiría la coexistencia de librerías gráficas de distintos fabricantes de manera simultánea, mediando y resolviendo las llamadas a la API OpenGL. Han pasado unos años, pero finalmente Nvidia ha liberado una nueva serie de controladores que, si bien con cuentan con otras novedades que nos hubiera gustado que incluyeran y aún se encuentran en estado beta, sí que dan una vuelta de tuerca al panorama de los controladores gráficos y OpenGL en GNU/Linux, gracias a libglvnd. Además de esto se corrige un bug de EGL, se actualiza el instalador de Nvidia y se eliminan definitivamente las librerías de Vdpau del instalador, pues a día de hoy, al ser libres, están incluidas en cualquier distribución. A priori estos controladores no supondrían un cambio en cuanto a rendimiento o desempeño, salvo en los casos donde esta nueva ABI sí que sea necesaria y marque la diferencia. https://devtalk.nvidia.com/default/topic/908423
  19. XCOM 2, secuela del afamado título de estrategia por turnos XCOM: Enemy Unknown, nos lleva 20 años después de que la humanidad perdiera la guerra contra los invasores alienígenas. Tras años escondido en la sombra, XCOM ha resurgido de sus cenizas y tratará de recuperar el planeta en el último intento que tiene la humanidad de poder vencer. Uno de los grandes títulos de este año, de los más esperados y prometedores, que ha cumplido con su promesa de llegar a todas las plataformas desde el primer día, gracias al buen trabajo, una vez más, de Feral Interactive. Siempre hay algún pero, tampoco vamos a engañarnos, y como ya expliqué en su día más profundamente, a día de hoy los títulos que llegan a GNU/Linux, aunque cada vez avanzamos más, no son realmente nativos sino ports hechos a posteriori, con todo lo que eso implica y no podemos esperar algo perfecto en cuanto a rendimiento sino un producto algo menos pulido que para el resto de plataformas. En ese sentido, este XCOM2 exige un hardware un poco más potente para poder jugarlo en GNU/Linux, pero según los primeros que lo han podido probar, se nota que la mano de Feral ha estado presente afinando el título al máximo para que podamos disfrutarlo como es debido. La invasión ha llegado a Europa y Asia antes que al resto del planeta, así que no será hasta mañana que los portales anglosajones del otro lado del charco se hagan eco del resurgir de XCOM y podamos tener una muestra más grande de revisiones y opiniones acerca del título y de su desempeño en la plataforma del Ñu y el Pingüino Como era de esperar, AMD se ha quedado de nuevo al margen y, aunque Feral lo ha intentado, sin la colaboración de los de Sunnyvale poco se ha podido hacer para que el título corra con GPUs de esta compañía, así que tenemos de nuevo el aviso de "Hardware AMD/Intel no soportado". En cuanto a las tarjetas gráficas integradas de Intel, dado su escaso potencial y la falta de soporte para muchas extensiones OpenGL recientes, es del todo lógico que no se recomiende su uso a la hora de correr este titulo, pero las tarjetas gráficas de AMD vuelven a dar la nota discordante. Michael Larabell, de Phoronix, ya ha hecho algunas pruebas preliminares y la cosa va más allá del pobre rendimiento, errores gráficos y demás fallos a los que estamos acostumbrados, esta vez el juego directamente no arranca, tanto con los controladores privativos Catalyst/Crimson como con las alternativas libres. Feral, al igual que otros estudios ya se han quejado en otras ocasiones por la falta de compromiso de la compañía para con los desarrolladores, quienes al intentar solventar los problemas que se les presentan por culpa del precario estado de los controladores gráficos contactando directamente con AMD, no han recibido más que excusas y promesas vagas y/o han sido completamente ignorados. Sabemos que AMDGPU sigue evolucionando, la promesa del cambio sigue en el aire y todo lo que escuchamos acerca del futuro de AMD suena muy prometedor, pero cuando bajamos al mundo real nos encontramos, un año más, con la misma situación de siempre, rendimiento pobre o nulo y un soporte más que cuestionable por parte de una empresa que parece que empieza a cambiar, pero que sigue muy por detrás del resto de alternativas que tenemos los linuxeros. Vulkan, que se presenta como la vuelta de tuerca definitiva para disfrutar de aplicaciones 3D en cualquier plataforma, está casi entre nosotros y no se ve ningún avance que nos indique que AMD llegue a tiempo para aprovechar los avances que ésta ofrece. Por ahora no me aventuro a decir nada acerca de lo que nos espera en el futuro con AMD, especialmente después de tantos años de decepciones. Esta vez quiero creer que por fin van a conseguirlo o al menos han dado por fin los primeros pasos en la dirección correcta. Lo que sí tengo claro es que aún falta mucho para que lo que tienen pensado ofrecernos llegue a materializarse.
  20. Aunque Nvidia no se caracteriza por ser la empresa más abierta, sí que nos suele sorprender a menudo con nuevas tecnologías, mejoras y soporte para cosas que ni conocíamos. La última gran sorpresa que nos llevamos fue la culminación de la nueva ABI OpenGL, que llevaba en el tintero varios años y que Nvidia puso en nuestras manos con la última serie de controladores 361.x En esta ocasión, Peter Messmer ha querido, a través del blog de desarrolladores de Nvidia, explicarnos cómo gracias al estándar EGL y los cambios que se han ido introduciendo en las últimas series de controladores de Nvidia, es muy sencillo desvincularse del servidor gráfico a la hora de renderizar contenido OpenGL. Si bien el principal objetivo se centra más en equipos y centros de desarrollo, en los que tener una sesión de las Xs abierta para renderizar contenido off-screen no es deseable, en el caso de los usuarios de a pié sí que nos permite imaginarnos las posibles aplicaciones de esto, especialmente en lo que podría suponer de cara a la inminente migración de X11 a Wayland. Por supuesto, no se limita únicamente al renderizado, sino que permite administrar los recursos de manera precisa, incluyendo configuraciones Multi-GPU. No seré yo quien explique el funcionamiento detallado, porque sinceramente hace rato que me he perdido, pero por lo poco que he podido entender, la cosa pinta muy, pero que muy interesante. gnulinuxvagos.es/index.php?app=forums&module=post&section=post&do=new_post&f=14
  21. 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
  22. 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/
  23. Nvidia sigue trabajando sin descanso para que sus controladores oficiales tengan pronto soporte completo para Wayland. Durante la serie anterior, la 355, ya dimos cuenta dew todas las mejoras en lo que respeta a EGL y la nueva forma de construir los módulos para el Kernel. Ahora, con la beta de la nueva serie 358 vemos otro paso más para acercarnos a Wayland. Esta vez se han centrado en la interconexión con DRM/KMS, añadiendo el nuevo módulo nvidia-nomodeset para trabajar en tandem con el módulo del kernel, usádolo como base para la interface mode-setting provista por el administrador de renderizado directo del kernel. lamentablemente y aunque son muy buenas noticias, esto sigue siendo un paso más y aún tendremos que esperar un poco más para que Wayland sea una pieza central de nuestra distribución GNU/Linux, al menos en el caso de utilizar una gráfica de Nvidia. Por supuesto, éste no ha sido el único cambio que vemos en los nuevos controladores: Se ha corregido una regresión que afectaba al rendimiento de OpenGL en configuraciones de X server sin monitor. Se ha corregido una fuga de memoria que se producía cuando se destruía una ventana GLX que seguía teniendo el contexto asociado. Se ha corregido un error que provocaba la creación de buffers de píxeles de EGL en el buffer frontal y el posterior en lugar de hacerlo únicamente en el posterior, como requiere EGL. Se ha añadido un nuevo módulo de kernel, nvidia-modeset.ko. Este nuevo componente del driver funciona en combinación con el módulo nvidia.ko para programar el motor de visualización de la GPU. nvidia-modeset.ko no proporciona ninguna funcionalidad visible para el usuario, ni interfaces con aplicaciones de terceros. Sin embargo, en una versión futura, este módulo servirá de base para la interfaz de configuración del modo de pantalla (modesetting) proporcionada por el gestor de renderizado directo (DRM) del kernel. Se han reducido los parpadeos y los retardos en las transiciones hacia o desde el modo G-SYNC. Como parte de este cambio, a partir de ahora los monitores que tengan indicadores de G-SYNC en la pantalla indicarán que se encuentran en modo G-SYNC. El indicador visual de G-SYNC en OpenGL puede activarse en nvidia-settings para señalar cuándo se está utilizando G-SYNC. El protocolo GLX de la siguiente extensión de OpenGL 3.0 ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB: GL_EXT_draw_buffers2 El protocolo GLX para los siguientes comandos de OpenGL 3.0: BindBufferRangeNV BindBufferBaseNV BeginTransformFeedbackNV EndTransformFeedbackNV GetTransformFeedbackVaryingEXT TransformFeedbackVaryingsEXT que forman parte de las siguientes extensiones: GL_NV_transform_feedback GL_EXT_transform_feedback ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB. Con los cambios anteriores, el protocolo GLX para OpenGL 3.0 ha pasado de ser un protocolo no oficial a tener la categoría de protocolo oficial para ARB. Se ha añadido un nuevo mecanismo de asignación de memoria para asignaciones de gran tamaño en el controlador de OpenGL. Este mecanismo permite liberar la memoria asignada al proceso cuando no se utiliza, lo que deja más espacio de direcciones virtuales disponible para la aplicación. Está activado de forma predeterminada en aplicaciones OpenGL de 32 bits con Linux 3.11+ y glibc 2.19+. La memoria asignada de esta manera consume espacio en /dev/shm. Esta función se inhabilita configurando la variable de entorno __GL_DevShmPageableAllocations con el valor 2. https://devtalk.nvidia.com/default/topic/884727/linux-solaris-and-freebsd-driver-358-09-beta-/?offset=1
  24. Hola, hace alrededor de 1 mes que vengo usando distintas distribuciones (Elementary,Fedora,Ubuntu y mi actual Ubuntu gnome 15.04) pero en todas lo que me a hecho retroceder a dejarlo como mi sistema principal es un problema con la resolución, tengo un monitor led con una resolución de 1080 (específicamente un Siragon HLT-24) conectado por un cable vga a una nvidia 9500 gt y uso los drivers nvidia privativos 340.93 pero no detecta ni mi monitor ni mi resolución máxima (1080) llegando a máximo 1360x768, intente forzarla mediante Xorg en varias ocasiones logrando mayores resoluciones y ejecutando la mayoría bastante bien excepto la 1080 que al ponerla o aparecía una franja negra a la izquierda o se veía como si la pantalla tuviera un zoom, quizás por tener mal los HorizSync y VertRefresh pero al poner los que me indica en el manual ni siquiera inicia el entorno gráfico. Después de mirar por días muchos tutoriales y sin lograr resultado esta es mi ultima esperanza para poder disfrutar normalmente de linux. Este es mi Xorg actual (sin modificar) # nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 346.59 (buildd@roseapple) Thu Apr 9 09:44:25 UTC 2015 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" # HorizSync source: builtin, VertRefresh source: builtin Identifier "Monitor0" VendorName "Unknown" ModelName "CRT-1" HorizSync 28.0 - 55.0 VertRefresh 43.0 - 72.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 9500 GT" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "Stereo" "0" Option "nvidiaXineramaInfoOrder" "CRT-1" Option "metamodes" "1360x768 +0+0" Option "SLI" "Off" Option "MultiGPU" "Off" Option "BaseMosaic" "off" SubSection "Display" Depth 24 EndSubSection EndSection
  25. Hace muy poco hablamos del lanzamiento de la nueva serie de controladores privativos de Nvidia y de cómo iba a suponer un gran cambio en cuanto a cómo se compilan y construyen los módulos del kernel. Hay ha sido liberada la primera beta y, además de lo que ya sabíamos, con ella han llegado grandes novedades. El soporte a EGL está totalmente acabado y se añade como "experimental, lo que nos hace estar a un paso de poder disfrutar de Wayland con soporte oficial por parte de Nvidia. Además, ya se dejan ver algunas librerías "sospechosas" como puede ser libnvidia-egl-wayland.so. Las mejoras para vdpau ocupan el tercer lugar en la lista de novedades destacadas de esta serie: Se ha corregido un error por el que los datos de nivel de textura podían sobrescribir los del nivel inmediatamente inferior en vistas que no incluyesen el más alto de los dos niveles. Se ha corregido un error que podía provocar el bloqueo del panel de control de nvidia-settings al actualizar la disposición de pantallas. Se han corregido algunos informes erróneos sobre el soporte de las extensiones GLX: según los informes, era posible usar algunas extensiones para renderizado GLX indirecto, cuando en realidad solo se admiten para renderizado directo. Se ha añadido soporte para las siguientes extensiones de EGL:EGL_KHR_swap_buffers_with_damage EGL_NV_stream_consumer_gltexture_yuv Se ha sustituido el sistema de compilación de los módulos de kernel de NVIDIA y se han actualizado el paquete de instalación y el programa nvidia-installer de forma que utilicen el nuevo sistema de compilación y organización del código fuente de los módulos. Para obtener más información sobre el nuevo sistema de compilación y organización del código, consulta el archivo README en la dirección:ftp://download.nvidia.com/XFree86/packaging/linux/new-kbuild-for-355/ Se ha añadido a EGL soporte completo de OpenGL de forma experimental. Se ha marcado la opción DeleteUnusedDP12Displays como obsoleta.La versión 1.5.0 de la especificación de RandR (Resize and Rotate) de X contiene una nota por la que las salidas generadas de forma dinámica no se destruyen. Por tanto, esta opción ha quedado obsoleta y se suprimirá en futuras versiones del controlador. Se ha añadido soporte para los perfiles de VDPAU incorporados a VDPAU 0.9:VDP_DECODER_PROFILE_H264_BASELINE VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE VDP_DECODER_PROFILE_H264_EXTENDED VDP_DECODER_PROFILE_H264_PROGRESSIVE_HIGH VDP_DECODER_PROFILE_H264_CONSTRAINED_HIGH Se ha corregido un error que impedía a más de una salida de RandR compartir modos añadidos por el usuario. Se ha corregido un error por el cual, al usar Xinerama, no se tenían en cuenta los intervalos de intercambio (swap) especificados en la aplicación para algunas pantallas. Se ha corregido un error por el que los modos de RandR suministrados por el usuario con combinaciones imposibles de los indicadores +HSync, -HSync, +VSync y -VSync dañaban la lista de modos. Se ha añadido la posibilidad de convertir un contexto de OpenGL (de la versión 3.0 adelante) en el contexto actual sin vincularlo a un objeto dibujable (drawable). https://devtalk.nvidia.com/default/topic/862392/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-355-06-beta-/
×