Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'controladores'.

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

  1. Hace poco mi ratón ergonómico, que ya llevaba unos cuantos años de servicio a cuestas, pasó a mejor vida y, aunque traté de revivirlo, llegó un momento en que había más estaño que ratón y tuve que asumirlo. Tocaba un cambio. Buscando un poco en en aras de optar por un hardware "Linux-friendly", no sólo en la parte que corresponde estrictamente al funcionamiento, sino por el apoyo del fabricante hacia GNU/Linux, me decanté por Roccat, una compañía que se dedica casi en exclusiva al diseño de periféricos destinados a gamers. Como tampoco soy un jugador muy exigente y no era cuestión de empeñar un riñón para unos pocos ratos que paso jugando, el elegido fue uno de sus modelos más básicos (entiéndase barato ) el Roccat LUA. Muy ligero, preciso, tres botones y alguna pijería con leds azules ¿Para qué más? En realidad, los controladores libres para dispositivos Roccat fueron desarrollados hace ya unos años por el germano erazor_de e incluidos en Linux en 2010, si no me equivoco. Por tanto, a estas alturas, nada más conectar el ratón al equipo debería cargarse el módulo correspondiente para lidiar con este tipo de hardware ¿Verdad? shiba@Shiba87:~$ lsmod | grep roccat hid_roccat_lua 2626 0 hid_roccat_common 4383 1 hid_roccat_lua Como se puede ver, en mi caso ya he dicho que se trata del modelo LUA, por tanto el módulo que me muestra cargado es el específico para ese tipo de ratones. Ocurriría lo mismo si habláramos de un Arvo, un Kova, un Pyra o cualquier otro Roccat. Siendo así creo que nos podemos saltar la parte de cómo instalar los controladores libres, que aunque no están desarrollados por Roccat, cuentan con su apoyo y los podemos encontrar en su web oficial, funcionan perfectamente y salvo que tengamos una versión de Linux anterior a la 2.6.35, debería ser completamente "Plug & Play". Lo que nos interesa ahora es una herramienta para poder aprovechar al máximo las capacidades de este tipo de ratones/teclados. Lamentablemente, por el lado de las herramientas libres no vamos a encontrar nada tan vistoso y profesional como el software oficial, pero su equivalente OpenSource tampoco se queda corto y funciona bastante bien, así que ¿Para qué complicarse cuando incluso ellos mismos lo recomiendan? Arch Debian Ubuntu Compilar manualmente Uso y configuración Antes que nada y como mera formalidad, vamos a añadir nuestro usuario al recientemente creado grupo "roccat", para que los permisos no nos den problemas luego, especialmente aquellos que decidieron compilar manualmente. Lo habitual sería que ahora tuviéramos una flamante entrada en el menú de nuestro entorno, pero en cualquier caso podemos lanzar el configurador que nos interese roccat_keyboard_launcher o roccat_mouse_launcher Sólo debemos tener en cuenta si es ratón o teclado. El configurador concreto que nos hace falta se abrirá automáticamente en función del modelo que detecte conectado. O, en mi caso, con un modelo de ratón muy básico, un asistente acorde a las circunstancias
  2. 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.
  3. Aunque fue lanzado en la madrugada del Lunes, ya que estamos en verano me van a permitir tomarme una pequeña licencia a la hora de escribirlo, porque con este calor... ya se sabe Una vez más, Linus Torvalds, junto a otros muchos desarrolladores de todo el mundo que trabajan en el kernel Linux (Que no en el kernel DE Linux, ya que eso es un sinsentido ), nos traen una nueva versión cargada de novedades y características la mar de interesantes. Se incluye soporte inicial para la arquitectura GPU Polaris de AMD, lo que incluye a la última RX 480 Al mismo tiempo, AMDGPU recibe mejoras de rendimiento con GPUVM, optimizaciones de PowerPlay, así como otras muchas mejoras de carácter general. En el caso de Nouveau, se incluye soporte para las Maxwell GM108, junto con mejoras para el sensor de consumo energético ARM incluye nuevas plataformas, como el primer LG ARM (LG1312), Aspeed, OXNAS-MPS2 y algunos nuevos SoC adicionales. Con la llegada de ACPI 6.1 se añade Schedutil como controlador principal de la frecuencia de la CPU. Éste se diferencia de los administradores utilizados hasta ahora, principalmente, en que toma la información provista por el administrador directamente para la toma de decisiones, no teniendo que hacer el seguimiento por si mismo y puede invocar controladores para un mejor ajuste del rendimiento de la CPU. Nuevo controlador PMC (Power Manager Control) para los procesadores Intel Reporte de energía acumulada para las APU AMD Carrizo En cuanto a sistemas de archivos, tenemos un gran número de correcciones para Ext4, así como también para Btrsf, F2FS y XFS En periféricos tampoco nos quedamos atrás, añadiendo soporte para ratones y teclados Corsair K70R, K95RGB, M65RGB, K70RGB y K65RGB Valve nos trae soporte para el mando Xbox One Elite de Microsoft, ya incluido en Steam OS durante el pasado Junio Más soporte HDMI para Skylake, nuevo chip Realtek y mucho más hardware de Audio que se añade a la lista. Soporte para la creación de controladores de unidades USB virtuales en USB/IP Histograma de eventos en ftrace Como siempre, para conocer al detalle la interminable lista de novedades, lo mejor es dirigirse a Kernel Newbies y, si no podemos esperar a compilar esta nueva versión de Linux con nuestras propias manos, siempre podemos obtener el código fuente en Kernel.org
  4. Pasadas las fiestas, volvemos a la carga con una nueva versión de Linux, que llega, como siempre, con interesantes novedades, mejoras y correcciones. Entre las novedades destacadas de la 4.4 tenemos: Soporte para las futuras APUs de AMD Stoney Graphics Comienzan los trabajos para integrar el nuevo controlador AMDGPU para gráficas Carrizo, Tonga y Fiji, habilitando el planificador AMDGPU por defecto, añadiendo nuevos opcodes AtomBIOS, aunque aún sin administrador de energía. Controlador KMS para Raspberry Pi, gracias al trabajo de Eric Anholt, de Broadcom. Desafortunadamente aún no es capaz de lidiar con la aceleración gráfica 3D o la administración de energía Código para VirtiO VirGL en Gallium 3D Mejoras en la administración de la memoria Un dispositivo de bucle más delgado y más rápido que soporta entradas y salidas asíncronas y directas Mejoras en estabilidad y Re-Clocking para los controladores Nouveau. El controlador MSM Freedreno nos brinda soporte para el nuevo socket de Qualcomm, el Snapdragon 820 Mejoras y correcciones para el controlador DRM de Intel para GPUs Skylake y Broxton Mejoras en el soporte UEFI 2.5, incluyendo EFI ARM64 y AArch64 Soporte para los nuevas tarjetas Wifi Realtek rtl8xxxu Soporte para programas eBPF No-Root Soporte para mapas/programas persistentes con eBPF Soporte para sonido Lewisburg de Intel Mejor soporte para los touchpads de precisión Skylake de Win8, el nuevo teclado Corsair Vengeance K90 y soporte para el volante Logitech G29 Soporte para el cntrol remoto de la TV Goole Fiber Mejor soporte para los portátiles Toshiba Numerosos cambios para KVM x86 Mejor soporte TPM 2.0 (Trusted Platform Module 2) Actualizaciones para la plataforma Chrome, que incluye trabajos para el Pixel 2015 Manejo espacial para dar soporte a la tecla ESC de los nuevos portátiles Lenovo Importantes correcciones para la encriptación de sistemas de ficheros EXT4 Más correcciiones para RAIDs 5/6 Btrfs Mejor estabilidad y rendimiento de Flash-Friendly File-System (F2FS) Soporte para SSD Open-Channel a través de LightNVM El código de ensamblado de x86 continúa siendo reescrito en C Soporte SHA Optimizado utilizando las extensiones SHA de Intel La utilidad Kconfig de ha sido portada a QT5 El código fuente, como es habitual, está disponible en Kernel.org, para todos aquellos que quieran echarle un vistazo o empezar a trastear con él inmediatamente
  5. 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
  6. Mucho se ha hecho de rogar, pero finalmente tenemos lo que tanto hemos esperado. Nvidia acaba de liberar una nueva serie de sus controladores oficiales que traen, como siempre, muchas novedades interesantes, pero es que esta vez son más que eso. La nueva serie 364 culmina lo que comenzó con la serie experimental 355 y nos brinda soporte oficial estable para la nueva API gráfica de Khronos, Vulkan, en su actual versión 1.0.6, además de completar el proceso de adopción de EGL introduciendo las primeras librerías que dan soporte completo al servidor gráfico Wayland. Se cambia el patrón de instalación para hacer uso de las librerías GLVND GLX en lugar de las librerías GLX antiguas Se añade soporte inicial para DRM KMS (Direct Rendering Manager Kernel Modesetting) Esto significa la inclusión de un nuevo módulo nvidia-drm.ko, que se inscribe tanto con soporte PRIME como DRM KMS Se añade soporte para numerosas extensiones EGL EGL_EXT_platform_waylandencargada de hacer que aplicaciones Wayland corran en la implementación EGL de Nvidia EGL_WL_bind_wayland_displayencargada de hacer que compositores Wayland corran en la implementación EGL de Nvidia EGL_EXT_device_drm EGL_EXT_output_drm EGL_EXT_stream_consumer_egloutputPara permitir que los compositores Wayland muestren su contenido a través de EGLDevice, EGLOutput y EGLstreams. Se añade la librería libnvidia-egl-wayland.so, que permite a los compositores Wayland el uso de EGLDevice, EGLOutput y EGLstreams para compartir el buffer de EGL con las aplicaciones Wayland Suporte estable para la API Vulkan 1.0 Se mejora la precisión de X colormap desde 8 bits significativos a 11 en GPUs Geforce Se añade una nueva característica RandR, CscMatrix, la cual especifica una matriz de conversión de espacio de color de 3x4. Esta matriz se aplica después de X colormap y antes de gamma ramp. Es compatible con GPUs GF119 o más recientes. Así mismo se mejora el manejo de X gamma ramp en GPUs GF119 o más recientes. RandR gamma ramp cuenta siempre con 1024 entradas y ahora se aplica al cursor, VDPAU capas de estaciones de trabajo como añadido a la ventana de root de las Xs. Los registros del controlador de Nvidia han sido rediseñados con el nuevo subsistema DRM de Linux para dar soporte a PRIME. Como consecuencia de esto, es necesario contar con Linux 3.13 o superior para instalar esta nueva serie de controladores. Se mejora la interacción de aplicaciones que utilizan el cursor de hardware mientras G-SYNC está activo. Se incluye también soporte para nuevas GPUs GeForce 920MX GeForce 930MX Y, por supuesto, numerosos parches y correcciones Sobra decir que al margen de la ingente cantidad de novedades y mejoras, tanto Wayland como Vulkan son dos cosas que llevábamos mucho tiempo esperando y que por fin tenemos a nuestro alcance para sacarle todo su potencial. Nos queda aún el sabor agridulce por la falta de soporte a gráficas Fermi, esperemos que finalmente de parecer, pero igualmente hay que reconocer que, si bien no como a todos nos gustaría, Nvidia sigue siendo única a la hora de ofrecer soporte a los linuxeros más exigentes.
  7. 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
  8. 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/
  9. Muchos están aún de resaca tras el puente de todos los santos y otros aún están de fiesta, Linus Torvalds parece que no lo ha tenido en cuenta y hoy no es un Lunes como todos los demás, hoy es el día en que Linux 4.3 ha llegado para, como siempre, traernos grandes mejoras e interesantes novedades. Sin embargo, a pesar de que algunos ya se aventuraron a decir que hoy también es el día en que ha salido el kernel DE Linux 4.3, eso no es cierto. No existe ningún subkernel dentro del kernel ni ningún Linux dentro de Linux, únicamente ha salido una nueva versión del kernel, de nombre Linux, desarrollado inicialmente por Linus Torvalds, que en este caso es la 4.3, todo lo demás son conspiraciones pingüinescas (o pingüineras) en las que no vamos a meternos Ahora hablemos de novedades, porque esta vez Tux nos trae más de una sorpresa: Los controladores libres Nouveau para gráficas Nvidia han sufrido una reconstrucción casi completa, lo que supone mejor soporte DRM, re-clocking, carga de firmware de Nvidia, soporte para Tegra X1, entre otras cosas. Soporte para los Intel Skylake (Gen 9), la nueva arquitectura de microcontroladores, tanto para la parte que corresponde a la CPU, pero sobre a las GPU integradas, que es lo que nos faltaba, además del soporte para Audio. Soporte inicial para las AMD R9 "Fury", aunque por ahora sin administración de energía ni re-cloking Grandes cambios en lo que respecta a gráficos en general y DRM. Además de las anteriores, se incluye soporte para hardware Matrox, HDCP y soporte para Freedreno MSM para hardware Qualcomm Soporte OpenGL 3.3 para Vmware (VMWgfx) Ext3 ha sido eliminado definitivamente del kernel. El controlador Ext4 puede también manejar sistemas de ficheros este tipo así que no tiene sentido seguir manteniéndolo. Mejoras para el citado Ext4, XFS, F2FS y correcciones para el TRIM en RAID 5 y 6 para Btrfs Introducción del subsistema de controladores MOST (Media Oriented Systems Transport) Grandes cambios en el planificador que podría afectar a la carga de trabajo SMP (Symmetric Multi-Processing) prara mejor (o eso se espera ) Varias optimizaciones para el arranque de sistemas x86, que incluyen la eliminación de código "muerto" y la ganacia de, al menos 600 microsengundos. Mejoras para la arquitectura MIPS que implican al Octeon CN68XX, I6400 de 64 bits MIPS, el soporte Uprobes y MSA, entre otras cosas. Se añaden características ARMv8.1 Mejoras en el soporte de portátiles Toshiba Mejoras para los controladores Wacom Aunque en otras ocasiones los he remitido a Kernel Newbies para un informe más detallado de todos los cambios, me temo que en esta ocasión van algo retrasados y aún no muestran siquiera los de la anterior 4.2 Pero eso sí, todos los valientes que tengan un rato libre para probar por su propia cuenta las novedades de esta versión de Linux, encontrarán su código fuente, como siempre, en https://Kernel.org https://lkml.org/lkml/2015/11/1/202
  10. 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
  11. 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
  12. 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-/
  13. A pesar de encontrarnos aún en temporada estival, parece que el incansable grupo de desarrolladores que trabajan en el kernel libre que Linus Torvalds compartió con el mundo hace ya casi un cuarto de siglo, no descansan ni para mojarse los tobillos en la orilla del mar, porque Linux 4.2 ya está con nosotros. Aunque muchas cosas han quedado pendientes para la próxima versión 4.3, nos encontramos ante una versión del kernel como muchas e interesantes novedades tanto en el apartado gráfico como en sistemas de ficheros, criptografía y otrso muchos aspectos. El driver AMDGPU DRM por fin ha sido incluido, con soporte para las Radeon R9 285 "Tonga" y las que aparecerán en el futuro, incluyendo las APUs Carrizo. Codificación de vídeo VCE1 para el controlador Radeon DRM Numerosos cambios más relacionados con DRM Atomic mode-setting Mejor manejo de DisplayPort MST Soporte para Adreno A306por parte del driver MSM DRM [*]Driver VirtIO GPU [*]Soporte inicial para los Intel Broxton Atom [*]El código relacionado con x86 sigue su preparación para ser reescrito en C, con miles de microoptimizaciones y mucha limpieza de código [*]Soporte para nuevos procesadores y placas ARM Freescale i.MX7D ZTE ZX296702 HiSilicon hi6220 [*]Soporte para la arquitectura del microcontrolador Renesas H8/300 [*]Por fin se incluye qspinlocks (queue spinlocks) gracias al trabajo de HP [*]Mejoras en el compensado NUMA y planificador deadline [*]Numerosas mejoras para KVM (Kernel-based Virtual Machine), incluyendo, write combining, virtualized performance counters en AMDo la integración VFIO en ARM. [*]Soporte para los procesadores ARCv2 y HS38 [*]Mejoras en encriptación Akcipher (Asymmetric Key Interface) soporte para algoritmos Chacha20, Poly1305 y RFC7539 DRBG es ahora la API criptográfica RNG por defecto Nueva implementación RSA Jitter entropy RNG Soporte para SHA-512 acelerado en ARM64, [*]Mejoras en NCQ TRIM y habilitación/&deshabilitación automática para SSDs con peor soporte [*]Mejoras de rendimiento para GFS2 [*]Numerosas correcciones para EXT4 [*]F2FS per-file encryption [*]Actualizaciones y mejoras para BTRFS [*]Soporte DAX para XFS [*]Comienzan los trabajos para mejorar la scalabilidad de FUSE [*]Soporte para ACPI 6 NV-DIMM (Non-Volatime Memory Device) y otras mejoras en el manejo de energía [*]Soporte para nuevos periféricos: Logitech M560 Sony Motion Controller Sony Navigation Controller de PlayStation 3/4 Weida WDT87XX touch-screen Ahora duncionan correctamente los LEDS del controlador inalámbrico de Xbox [*]Soporte para UEFI ESRT (EFI System Resource Table) [*]Mejoras de rencimiento para NBN (non-transparent bridging) Como siempre, el código fuente está ya disponible en Kernel.org Y una lista más detallada de los cambios y mejoras estará disponible en breve en Kernel Newbies
  14. Después del cambio de numeración en las versiones del kernel engendrado por el finlandés Linus Torlvalds y que nos llevó de la 3.x a la 4.0, ya tenemos una nueva e interesante versión, la 4.1, que, como siempre, nos trae novedades, grandes mejoras y numerosas correcciones. Entre lo más destacado de Linux 4.1 tenemos: Aumento significativo de rendimiento para ciertos componentes de hardware, especialmente los Intel Atom y los AMD Bulldozer Mejora en el consumo energético y eficiencia del hardware de Intel, con los cambios de P-State para los Bay Trail y Cherry Trail Mejoras en el controlador libre Nouveau, que ahora cuenta con soporte para las Geforce 750 Soporte para Intel XenGT vGPU Soporte para Radeon DisplayPort MST Encriptación del sistema de ficheros EXT4 llevada a cabo por Google en un intento de añadir niveles de cifrado Ext4 en Android Mejoras en el soporte para RAID 5/6 con MD RAID Mejoras generales para los portátiles de todos los fabricantes, pero en especial de los Chromebook Pixel 2, Dell y Toshiba. Se sigue trabajando en el soporte para Intel Skylake, que será lanzado a finales de año Soporte ACPI para arquitecturas AArch64 y ARM 64 Introducción de vGEM (virtual GEM graphics driver) Se añade TraceFS al kernel Soporte para la "Lightbar" de Chrome OS Soporte para Force feedback / rumble para el gamepad de xbox One Nuevo driver PMEM Soporte para Wacom HID Mejoras sustanciales para los sistemas de ficheros F2FS, XFS y BTRFS Modernización del sistema de sonido con un bus estándar para ALSA en el secuenciador y el núcleo de HD-audio code Como siempre, podemos descargar el código fuente desde Kernel.org Y consultar con más detalle todos los cambios que se han producido en esta versión en Kernel newbies
  15. Linus Torvalds y su alergia a los números grandes han hecho que tras Linux 3.19 nos encontremos ante una salto de versión hasta la 4.0, que como era de esperar, no es sólo un número, viene con un gran número de mejoras y nuevas características, además de un nombre en clave bastante desconcertante. Linux 4.0 (Hurr durr I'ma sheep.) nos trae: Live kernel patchin. Gracias al trabajo de Red Hat en Kpatch y SUSE en kGraft, tenemos la posibilidad de aplicar parches en vivo . El controlador Radeon DRM cuenta ahora con soporte para audio sobre DisplayPort y mejor control de los ventiladores El controlador AMDKFD para soporte HSA empieza a dar soporte a las APU Carrizo Soporte inicial para el hardware gráfico Intel Skylake Los controladores Nouveau incluyen ahora soporte básico para re-clocking soporte para la GPU Tegra GK20A y se fusiona con el código para ARM, además de otros muchos cambios internos. En el caso del controlador DRM para las NVIDIA Tegra se añade soporte para atomic mode-setting y se mejora el desempeño al la suspender y restaurar alguno de estos dispositivos. Soporte para pNFS block server Mejora a la hora de crear RAID 5 y 6 con Btrfs Nueva funcionalidad OverlayFS Soporte para Intel Quark SoC Soporte para nuevo hardware ARM Soporte para IBM z13 Mejora en el soporte para los portátiles Toshiba Mejoras en el soporte de los dispositivos Logitech HID++ Como es habitual podemos descargar el código fuente de esta nueva versión desde Kernel.org y consultar en detalle todos los cambios a través del portal Kernel Newbies
  16. El pasado viernes 27 de febrero, se actualizaron las cabeceras y librerias del kernel 3.16 en mi Ubuntu 14.10 de 64bits. Lo tenía con los controladores 331 privativos pero testados para mi Nvidia Gforce GTX560. En un momento dado el escritorio lanzó un error y desapareció el dash, barra de iconos, etc. para nunca volver. Después de seguir varias lineas de investigación, cambiar a los nouveau, desinstalar todo lo que huela a nvidia y volver a instalar, etc. Desinstalando Uniy y provocando que ya no podía volver a entrar con mi usuario... Terminé pensando que tardaría menos reinstalando 14.10 en mi partición del sistema aunque luego tuviera que volver a instalar las diez o doce (no más) aplicaciones que uso. Y ..¡¡oh!!... ¡¡¡sorpresa!!.. termina la instalación y sale la misma pantalla sin Unity, ni barra y con el mismo fondo de escritorio que tenía cuando lanzó el fallo. ¿¿¿???? Pero si he reinstalado formateando la partición de sistema / ¿¿??? Este no sabe con quién se las está jugando ;-)). Arranco con Gparted y me "fusilo" la partición del sistema. Eliminada, creada, formateada y vuelvo a instalar Ubuntu 14.10, formateando / y respetando /home en el otro disco. Arranco y la misma situación, no tengo acceso al dash. ¿Qué está pasando?, ¿donde guarda Ubuntu la configuración de mi escritorio?, ¿tal vez debería haber borrado los ficheros ocultos y demás carpetas de la configuración de unity en mi home? ...Posiblemente, pero no caí en ese momento. Con el rabo entre las piernas y bastante mosqueado, instalo mi querido y estable Xubuntu 14.04 que, en este caso si, elimina lo que hubiera mal y ya arranca con xfce y todo OK. Además actualizo esta vez bien, a los drivers 340 propietarios que mueven razonablemente bien Borderlans en Steam o Nexuiz, con lo que no necesito más aceleración. La duda que me corroe es, ¿se arregló al borrar ficheros ocultos de home?, lo que de confirmarse, sería un nuevo paso imprescindible para futuras reinstalaciones. O bien, ¿se trata de alguna partición (me extraña que Gparted no la mostrara) usada por Systemd, Grub2, o sistema de inicio similar?. Se agradecerán, ideas, sugerencias o pésames....
  17. "Diseased Newt" que es como ha sido apodada la última versión estable del kernel Linux, ha sido lanzada hoy mismo, convirtiéndose en la primera versión estable en ser liberada este año. Como es habitual, viene cargado de correcciones, pero sobre todo de novedades que incluyen soporte para gran cantidad de hardware nuevo: Intel Soporte inicial para la arquitectura Skylake (Aún no a la venta) Se corrigen varios problemas con el chip gráfico i830M PPGTT (Per-Process Graphics Translation Tables) función que permite el aislamiento de los procesos de la GPU en arquitecturas Ivy Bridge, Haswell y Broadwell, vuelve a estar habilitado por defecto. Se unifica los trabajos de suspensión, hiber, despertar e hibernar. Se añade la posibilidad de rotar cursores 180º Mejoras en el soporte de Cherryview en los Atoms de nueva generación. Se ha iniciado la eliminación del soporte para DRI1 y UMS. Mejoras en el control de la retroiluminación para el Dell Vostro 3546. Soporte de MPX (Memory Protection Extensions System Architecture) para x86. AMD Mejoras de rendimiento en la gestión de memoria TTM (Translation Table Manager). Parches para la gestión de energía en modelos actuales. Se incorpora finalmente el controlador AMDKFD que da soporte a HSA (Heterogeneous System Architecture). Se añade la posibilidad de habilitar el control de ventiladores para las arquitecturas South Islands y Sea Islands. Mejoras en el rendimiento GPUVM multi-ring. Se solucionan algunos problemas con los cursores. Nvidia Soporte para el control de tensión en los Tegra K1. Soporte para el chip GM204. Mejoras en el control de cambio de frecuencia de la memoria en los modelos GM21x. Otros fabricantes El controlador libre para las GPUs de Qualcomm Adreno incluye ahora soporte para la serie A4. El controlador para los gráficos de STMicroelectronics ahora tiene soporte para la selección del adaptador HDMI por i2c. Dispositivos de entrada y salida Soporte para más dispositivos multitáctiles. El controlador para dispositivos Logitech ahora soporta el protocolo específico del fabricante HID++. Soporte para el modelo Wireless Touchpad T650 de Logitech. Soporte para el Surface Pro 3 Type Cover de Microsoft. Mejoras en el soporte de RMI. Mejoras en el controlador para dispositivos Wacom. Se añaden dos nuevos controladores para el touchpad I2C y la pantalla táctil que se encuentran muchos Chromebooks y otros dispositivos. Se incluye un controlador para el panel tactil Goodix. Sistemas de archivos El sistema de archivos OverlayFS, un servicio del kernel que da la posibilidad de montar varios sistemas de archivos distintos a la vez aparentando ser un sólo sistemas de archivos. Mejoras en F2FS Ext4 gran cantidad de correcciónes. Además se optimiza la utilización de la CPU. XFS recibe cambios relacionados con el formato del encabezado. Se han movido a la biblioteca libxfs algunas estructuras compartidas con el espacio de usuario. Btrfs, se ha mejorado el soporte para RAID 5 y 6. SquashFS ahora cuenta con soporte para compresión con LZ4. CephFS, soporte para datos inline. Se han solucionado también algunos fallos. Gestión de energía Se introduce una interfaz unificada para acceder a las propiedades de los dispositivos que ofrece el firmware. De esa forma, los controladores no tienen que preocuparse sobre de dónde vienen dichas propiedades. Se inluye soporte para P-States en el controlador intel_pstate de Linux 3.19. Usará CPUID para detectar si el procesador soporta la característica y en cuyo caso, se habilita por defecto. P-States se puede deshabilitar manualmente. Esta técnica para regular la frecuencia en procesadores recientes de Intel, consigue un rendimiento superior frente al clásico método ofrecido por CPUfreq. Mejoras en la gestión de energía de las plataformas de Intel Baytrail-T y Baytrail-T-CR. Soporte para _DEP. El controlador para los ventiladores de ACPI ahora crea interfaces de dispositivos de refrigeración con nombres que reflejan las identificaciones de los dispositivos ACPI a los que están asociados. Otros Dispositivos Mejoras de rendimiento en controladores RAID6 en device mapper. Soporte para el audio de los nuevos SoCs x86 de Intel y los adaptadores USB de audio de Focusrite Scarlett, Digidesign Mbox1, los DACs de Denon/Marantz y Zoom R16/24. También se añade soporte para los auriculares con ASoC TI TS3A227E. La arquitectura MIPS recibe una gran cantidad de cambios entre los que destacan la mejora de las trazas inversas en sistemas multiprocesador, cambio a la plataforma ATH79 para usar la biblioteca del firmware, mejoras en la documentación de GIC, mejoras en el código de la plataforma Loongson 3, arreglo de fallos en la plataforma Loongson 1B, optimizaciones en el soporte para microMIPS, se añade soporte para plataformas ATH25 y muchos otros cambios. El controlador thinkpad-acpi soluciona problemas relacionados con el silenciado del audio y ahora se realiza mediante software. El controlador dell-laptop para portátiles dobla su tamaño para dar soporte a la retroiluminación del teclado. Se solucionan numerosos fallos en los codecs de HD-audio de Realtek. Otros cambios Se incluye soporte completo para dispositivos no coherentes en ARM. En las máquinas virtuales x86 PVHVM, se usa APIC para las interrupciones si se han virtualizado por hardware. Como es habitual, a través de http://kernel.org, aquellos que no se resistan a compilarlo con sus propias manos pueden obtener el código fuente de esta nueva versión Y en Kernel newbies tendremos en detalle todos y cada uno de los cambios introducidos en Linux 3.19
  18. AMD tiene interesantes planes de futuro para GNU/Linux, algo que tras muchos años de tenernos técnicamente como usuarios de segunda es de agradecer Alex Deucher ha sido el encargado de sorprendernos en el XDC 2104 anunciando una nueva estrategia de unificación Open-Source para sus controladores, que para entendernos es una estrategia de unificación de esfuerzos entre los desarrollos libre y privativo, aunque eso sí, con algunos matices. Este nuevo controlador para LInux, por ahora denominado "amdgpu" es un cambio de estrategia que planea unificar esfuerzos y consolidar las ventajas que ofrecían, hasta ahora por separado, los controladores actuales. Las tecnologías TTM, DRM, GBM, DRI, y GLAMOR continuarán siendo utilizadas por los controladores libres Radeon y ahora también serán aprovechadas por los Catalyst, los cuales, y aquí es donde viene el primer matiz, NO serán liberados en modo alguno. Este punto es algo más confuso ya que nos encotramos ante tres facetas o niveles, All Open, Non-Pro y Pro. El nivel intermedio sería en el que entrarían en juego los controladores privativos para aplicaciones OpenGL, OpenCL y multimedia y un nivel más allá, es decir, el Pro, ofrecería además algunos addons Firepro Para no liarnos demasiado, ya que los esquemas tampoco son demasiado claros, digamos que hablamos de un nuevo controlador que tendrá partes que corresponden al actual controlador Radeon y partes que forman parte de los controladores privativos Catalyst trabajando en sintonía, o al menos esa parece ser la idea. El actual xf86-video-ati será relevado por el nuevo xf86-video-amdgpu DDX, que tratará de lidiar con todo ese hardware que ofrecerá AMD y como están viendo en las imágenes, también nos recuerdan una y otra vez que aunque se aprovechará el código de los controladores libres, no piensan liberar nada de sus equivalentes privativos. Esto plantea también una serie de retos tanto en lo referente a la documentación como en lo que respecta a los desarrolladores que trabajan con los controladores privativos (los que quedan) que necesitarán formación extra para lidiar con la tarea que se les viene encima Pero no por ello dejan de hacer hincapié en lo que aportarán los Blobs a la mezcla Otro de los matices que nos plantea esta nueva estrategia es que está planteada única y exclusivamente pensando en el hardware que veremos en el futuro y no para las generaciones actuales o pasadas de AMD. El trabajo ha comenzado con las Sea Island a modo de prototipo pero no será hasta las futuras Pirate Island las que veremos gráficas con soporte amdgpu Aún con todas las cosas que no sabemos y que quedan en el aire y todos esos "matices" que hacen que desluzca un poco, la estrategia no suena nada mal. Es sin duda un paso adelante que esperábamos desde hace mucho tiempo, quizá no de esta manera, pero es un inicio para cambiar una situación que se prolonga ya demasiado y, quien sabe, quizá la clave que nos dará por fin controladores de calidad para poder disfrutar de nuestras gráficas rojas en GNU/Linux http://www.x.org/wiki/Events/XDC2014/XDC2014DeucherAMD/amdgpu_xdc_2014_v3.pdf
  19. El XDC2014 nos está dejando grandes cosas y una de ellas es la conferencia de Nvidia en donde por fin nos han dejado claros sus planes de futuro de cara al nuevo servidor gráfico Wayland. Andy Ritger hizo públicos en Bordeaux los futuros planes que tiene la empresa de cara al futuro centrándose en algo que hasta ahora había sido una gran incógnita a la par que un secreto a voces. Dichos planes parten de lo que ya venían incorporando las últimas versiones de sus controladores, el cada vez mejor soporte para EGL en detrimento de GLX. Actualmente trabajan en el soporte a la infraestructura KMS (Kernel Mode-Setting), permitiendo así que su implementación de EGL opere fuera de X11, además de proponer algunas extensiones avanzadas de EGL que podrían hacer la transición más fácil para todos. Los Blobs de Nvidia actualmente no están utilizando directamente la API KMS, pero su código de visualización está trabajando registrarse con DRM y para que su controlador para el kernel soporte el uso de KMS ioctls. Con esto, mientras hacen uso de su propia implementación de KMS permiten la compatibilidad con DDX, dejando vía libre a otros clientes KMS para utilizar directamente el controlador de Nvidia. Lo que está tomando tanto tiempo no es realmente esta parte sino el conseguir implementar todas estas mejor sin que eso afecte a otras de sus tecnologías como G-Sync, FrameLock, Stereo, o el renderizado SLI. La serie de controladores 346.xx y su implementación EGL, completamente funcional sin necesidad de X11, son la punta de la lanza, aunque aún tardaremos un tiempo en ver su versión personalizada de KMS terminada. Uno de los puntos a destacar es que mientras los controladores libres Mesa hacen uso de GBM (Generic Buffer Manager), Nvidia propone un enfoque más generalizado para lidiar con los buffers utilizando EGLStreams. Aunque sin una fecha clara, son noticias esperanzadoras y probablemente el empujón definitivo que necesitamos para dejar por fin atrás el vetusto X11 y empezar a pensar en servidores gráficos más acordes a las exigencias actuales. Wayland está a punto de llegar, y esta vez de verdad, no como lo que venimos oyendo desde hace unos años, así que dentro de poco nos tocará ponernos las pilas para lidiar con una nueva transición (y van...) que supondrá un gran paso adelante para el sistema del Ñu y el Pingüino http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerEGLNonMesa/nvidia-and-compositors.pdf
  20. Hace un par de semanas Nvidia comenzó a trabajar en una nueva línea de controladores 343.x que hasta ahora se encontraba en estado Beta. El reciente lanzamiento de la nueva línea de tarjetas gráficas, la segunda generación Maxwell, concretamente la Geforce 980 GTX y la Geforce 970 GTX, han hecho posible que ya podamos disfrutar de la versión estable de los nuevos controladores y, en esta ocasión, incluso antes que para otros sistemas operativos. Esta nueva línea de controladores se caracteriza, aparte de por las nuevas características que incorporan, por ser el punto de inflexión en el soporte de hardware "antiguo" de Nvidia pues partir de esta serie sólo habrá soporte para las gráficas Geforce 400 o más recientes, quedando las anteriores relegadas a la serie de controladores 340.x que tendrán soporte prolongado. Evidentemente, el primer cambio a destacar será la inclusión de las dos nuevas GPUs de la compañía: Se ha añadido soporte para las siguientes GPUs:GeForce GTX 970 GeForce GTX 980 Se ha corregido un error que hacía que el ajuste "sync to vblank" no se respetase en las aplicaciones EGL. Se ha corregido un error por el que algunos programas OpenGL encontraban un problema de falta de memoria al cambiar de modo. Se ha corregido un error que impedía al controlador OpenGL de NVIDIA respetar el valor de la variable de entorno __GL_SHADER_DISK_CACHE_PATH. Se ha corregido un error por el que, en ciertas consultas y asignaciones efectuadas en la interfaz de línea de comandos de nvidia-settings, las pantallas inhabilitadas se incluían implícitamente como destinos seleccionados a falta de una selección explícita de destinos. Se ha añadido un nuevo atributo a la API NV-CONTROL para consultar el uso que se está haciendo del motor de descodificación de vídeo. Se ha corregido un error por el que la opción de intercambio de ojos izquierdo/derecho de nvidia-settings no funcionaba en determinadas configuraciones estereoscópicas. Se ha solucionado un problema de sombreadores de Unigine Heaven 3.0 que podía producir anomalías en la imagen si se activaba el teselado mediante la implementación de un perfil de aplicación que utilizase el parámetro "GLIgnoreGLSLExtReqs". Véase la documentación de la variable de entorno __GL_IGNORE_GLSL_EXT_REQS para obtener más información. Se ha corregido una fuga de memoria que se producía al destruir superficies de EGL. Se ha añadido soporte para varias pantallas EGL simultáneas. Se ha retirado el soporte de las GPUs G8x, G9x y GT2xx, así como de los chips de placa base diseñados con ellas. Las versiones antiguas del controlador 340.* seguirán incluyendo soporte para nuevos kernels de Linux y servidores X (así como correcciones para errores críticos) hasta finales de 2019. Se ha corregido un error por el que nvidia-installer podía tratar de borrar sin éxito el directorio que contiene las interfaces del módulo kernel en paquetes preparados con --add-this-kernel. Se ha modificado nvidia-installer para que registre la desinstalación en un archivo distinto del registro de instalación y para que intente eliminar las versiones anteriores del controlador utilizando el programa de desinstalación de dichas versiones, si está disponible. Como es habitual, podremos obtener el instalador oficial de dichos controladores a través de la web de Nvidia para cualquiera de los sistemas *nix soportados GNU/Linux x86 GNU/Linux x86_64 GNU/Linux ARM Solaris FreeBSD x86 FreeBSD x86_64
  21. HSA (Heterogeneous System Architecture) es una tecnología de Amd que mejora la respuesta de la GPU en conjunción con la CPU, compartiendo recursos de manera más eficiente. Esta característica, propia de las tarjetas Radeon con chip Sea Islands, pretense ser no sólo beneficiosa para el hardware de AMD, sino servir para todo el hardware compatible con HSA. El código está diseñado para soportar múltiples CPUs conectadas con sus respectivas GPUs, aunque la implementación actual esta enfocada en soporta una única APU Kaveri/Berlin APU, y trabajar a través del controlador gráfico Radeon (kgd). Las GPUs AMD GPUs diseñadas para hacer uso de HSA (Sea Islands) comparten algunas funcionalidades de hardware entre el cómputo HSA y el cómputo regular gfx(memoria, interrupciones, registros), mientras otras funcionalidades han sido añadidas específicamente para el cómputo HSA. Todo el hardware compartido es administrado por el controlador gráfico radeon, y una interfaz entre kfd y kgd permite a kfd hacer uso de los recursos compartidos, mientras que las funcionalidades específicas de HSA son manejadas directamente por kfd mediante el suministro paquetes en una cola de comandos específica de HSA (HIQ). http://lkml.iu.edu/hypermail/linux/kernel/1407.1/02923.html http://developer.amd.com/resources/heterogeneous-computing/what-is-heterogeneous-system-architecture-hsa/
  22. El pingüino sigue avanzando y ya tenemos en nuestras manos una nueva versión recién salida del horno. Linux 3.15 llega con fuerza y cargado de novedades, entre las que destacan: Soporte para el modo mixto EFI pensado para correr sistemas de 64bits en sistemas UEFI de 32 bits. Tiempos de suspensión y restauración más rápidos. Soporte inicial para GPUs Nvidia Maxwell. Soporte para codificación VCE 2.0 para gráficas Radeon recientes. Soporte para el DualShock 4 de Sony. Soporte para las extensiones de CPU AVX-512 y RDSEED. Se ha mejorado los controladores de sonido, además de añadir soporte DPCM para Intel Haswell y Bay Trails. Mejoras de rendimiento para Btrfs. Dejan de tener soporte las siguientes plataformas x86: SGI Visual Workstation Sequent Computer Systems NUMAQ IBM Summit/EXA Unisys ES7000 Soporte para DisplayPort a 5.4 Ghz. Soporte Fastboot para procesadores Haswell y Broadwell. Soporte las APUs Mullins de AMD Soporte el chipset WiFi Realtek RTL8723AU Se deshabilita la gestión de energía para las GPUs RV770 AMD. Como es habitual, todos los cambios están recogidos en el portal de Kernel Newbies Y podemos obtener el código fuente desde: Kernel.org https://lkml.org/lkml/2014/6/8/70
  23. GTX Titan Z es el nombre de la última, a falta de una palabra peor, MONSTRUOSIDAD (sí, sí, con mayúsculas) de NVidia. Si hace algún tiempo nos sorprendieron con la Titán, la gráfica mononúcleo para Gaming más potente y cara del mercado y posteriormente subieron aún más el listoón con su versión renovada, la Titán Black, ahora se les ha ido completamente la cabeza y con la Titan Z han unido dos GPUs GK110 (Los de la Titan Black) en una misma placa, dando lugar así a algo que no sé bien como definir, pero monstruosidad se queda corto. Titán Z cuenta con 12GB de Memoria GDDR5 con un bus de 768 bits y una tasa de transferencia de 7 Gbps, 5.760 núcleos CUDA todo en una PCB de 269 x 111 x 53 milímetros, con un peso total de 1.364 gramos, un TDP de 375 W y aseguran que su refrigeración por aire es tan eficiente y silenciosa como la de su antecesora. Su precio es aún más monstruoso si cabe y será sólo accesible para un reducido grupo que sean más que entusiasmas del Gaming, pues es de al menos 2800€ http://www.geforce.com/whats-new/articles/introducing-nvidia-geforce-gtx-titan-z Y una vez nos hemos quedado ojipláticos con algo que no nos podríamos permitir ni en nuestros sueños más húmedos, hablemos de la nueva serie de controladores gráficos de Nvidia, que han sido lanzados para domar a semejante bestia. Los nuevos controladores 337.25 añaden soporte para las nuevas tarjetas gráficas GeForce GTX TITAN Z GeForce GT 740 GeForce 830M GeForce 840M GeForce 845M GeForce GTX 850M Se habilita el soporte para utilizar UBB (Unified Back Buffer) y 3D Stereo con la extensión de composición en las tarjetas Quadro Se incluye soporte para las siguientes extensiones EGL EGL_EXT_buffer_age; EGL_EXT_client_extensions; EGL_EXT_platform_base; EGL_EXT_platform_x11 Nueva extensión GLX_NV_delay_before_swaphttp://www.opengl.org/registry/specs/NV/glx_delay_before_swap.txt Soporte para Under/overclock para tarjetas de nuevas series (a partir de la 400) Soporte X.Org Server 1.16 (xserver ABI 18), que integra XWayland Actualizado la pantalla de configuración de nvidia-settings para identificar inequívocamente los monitores DisplayPort 1.2 mostrando la GUIDs de los mismos. Se elimina la opción "OnDemandVBlankInterrupts" se las opciones de configuración de las Xs Y, por supuesto, numerosas correcciones y parches Para aquellos que no puedan esperar a que sean empaquetados e incluidos en los repositorios de su distribución, pueden descargarlos, como es habitual, desde la página de Nvidia Linux x86 Linux x86_64 Linux ARM Solaris FreeBSD x86 FreeBSD x86_64 https://devtalk.nvidia.com/default/topic/748536
  24. Como hemos venido anunciando durante los últimos meses, nvidia se ha ido acercando cada vez más más al lado del Open Source y ya no sólo para sus procesadores Tegra sino también para sus gráficas de escritorio Geforce, ofreciendo su colaboración para con el proyecto Nouveau, llegando a liberar algunas especificaciones de su Hardware Los desarrolladores de Nouveau siguen trabajando en el soporte para administración de energía y "re-clocking" para el correcto ajuste de velocidad de la GPU y la memoria para varias generaciones de tarjetas Geforce, algo en lo que Nvidia parece haberse inmiscuido y aparte de responder a las cuestiones planteadas por los desarrolladores y posiblemente enviar parches y más documentación, la compañía ha decidido enviar tarjetas gráficas de muestra para que los desarrolladores tengan con qué trabajar, empezando con la recién lanzada Nvidia Geforce Gtx 750 Ti y la primera en dar el salto de la arquitectura Kepler a Maxwell Aunque todo sea dicho, este acercamiento no nos asegura que la liberación total de las especificaciones o Drivers llegue a ocurrir y desde la propia compañía han asegurado que el desarrollo en relación a los procesadores Tegra y el que corresponde a las gráficas de escritorio son asuntos completamente distintos y que serán tratados por separado. http://www.phoronix.com/scan.php?page=news_item&px=MTYwNzY
  25. Y para no variar llega cargado de novedades, mejoras y correcciones Soporte para Nvidia Tegra Prime Soporte para las GPU NVIDIA GK110 Se han terminado por fin los controladores gráficos para Intel Broadwell, que ya no están marcados como experimentales AMD Radeon DPM (dynamic power management) Soporte RadeonSI UVD (Unified Video Decoder) soporte para Intel Merrifield Soporte genérico CPU Boost Xen PVH Mejoras para KVM PowerPC AMD CCP (AMD Cryptographic Coprocessor) Soporte dentro de la plataforma ARM EFM32 ARMv7m HiSilicon SoC Marvell Berlin SoCs The Moxa ARM industrial platform Freescale's i.MX50 SoC Soporte para los núcleos MIPS interAptiv y proAptiv Soporte SMTP para arquitectura Xtensa El programador Deadline ha sido incluido en la línea principal del kernel TCP auto corking Soporte para los Pads Logitech Dual Action Nuevas funciones para Btrfs Mejoras de rendimiento para F2FS Kernfs ha sido incluido en la línea principal del kernel Como es habitual y si no queremos esperar a que aparezca la versión que corresponde en los repositorios de nuestra distribución, podemos obtenerlo desde Kernel.org Para conocer en más detalle el resto de cambios, pronto tendremos la lista completa en Kernel newbies http://lkml.iu.edu/hypermail/linux/kernel/1403.3/03023.html
×
×
  • Crear Nuevo...