Instalar Nouveau desde cero
| Copyright Copyright © José Luis Lara Carrascal 2016-2023  Sumario Introducción Libdrm Libglvnd Xf86-video-nouveau Libvdpau Libva Mesa GLU GLEW FreeGLUT Mesa demos Configurar el inicio de Nouveau Iniciamos Nouveau Incidencias de uso de Nouveau Aceleración 3D por software con LLVMpipe Configurar la aceleración 3D con DRIconf Activar el máximo rendimiento de la tarjeta gráfica Pros y contras de utilizar Nouveau Enlaces Configurar el inicio de Nouveau  1) Comprobar que el kernel ha sido compilado con el soporte de Nouveau 2) Establecer la resolución de pantalla óptima del framebuffer en monitores CRT 3) Extraer e instalar el firmware del controlador de gráficos original de NVIDIA 4) Configurar el ajuste automático del DPI y el Gamma de la pantalla 5) Activar el soporte de DRI3 en las opciones de configuración del controlador de gráficos 1) Comprobar que el kernel ha sido compilado con el soporte de Nouveau Tanto el código fuente original del kernel, cómo los que instalan las distribuciones, llevan activado por defecto el soporte del controlador nouveau del DRM. Basta ejecutar el siguiente comando en la terminal para ver que el kernel en curso, tiene compilado este soporte. Un ejemplo con Debian.
Si el comando no mostrara ningún resultado, es que no tenemos compilado el soporte. Y para asegurarnos más, nos vamos a /lib/modules/[versión del kernel]/kernel/drivers/gpu/drm, y comprobamos que no existe ningún directorio con el nombre nouveau. Como por ejemplo, era mi caso, con un kernel personalizado, con lo que tuve que recompilar el kernel, activando la compilación del módulo en la correspondiente sección de configuración, en la ruta Device Drivers >> Graphics support >> Nouveau (NVIDIA cards), como se muestra en la captura de pantalla.
2) Establecer la resolución de pantalla óptima del framebuffer en monitores CRT Cuando se carga el módulo nouveau al inicio del sistema, éste activa por defecto la resolución máxima permitida por el monitor en el framebuffer. Esto, que para los usuarios de monitores TFT no es un ningún inconveniente, porque la resolución máxima es siempre la resolución nativa y, por lo tanto, la recomendable para el uso del monitor. En monitores CRT supone un imprevisto bastante desagradable, porque la resolución máxima de un monitor CRT es siempre la peor posible para la salud visual del usuario. Para evita este inconveniente, editamos los archivos de configuración correspondientes de Grub y Lilo, según el cargador que estemos utilizando, y añadimos la resolución recomendable para nuestro monitor CRT. Sustituir 1024x768@85 por la resolución@refresco de pantalla, que cada usuario de estos fenecidos monitores tenga en el suyo. Pongo dos ejemplos, uno con Debian con Grub2, y otro con Slackware y Lilo. 2a) Grub2 >> /etc/default/grub (Debian)
Cuando hayamos guardado el archivo, actualizamos el cargador de inicio del kernel, con el comando correspondiente.
2b) Lilo >> /etc/lilo.conf (Slackware)
Cuando hayamos guardado el archivo, actualizamos el cargador de inicio del kernel, con el comando correspondiente.
3) Extraer e instalar el firmware del controlador de gráficos original de NVIDIA Firmware requerido a partir del modelo GeForce 6800 para poder hacer uso de la aceleración por hardware a través de la GPU de la tarjeta gráfica en la decodificación de vídeo (solo Kepler e inferiores). Lo primero que hacemos es irnos a la web de NVIDIA y comprobar cuál es el controlador soportado por nuestra tarjeta gráfica, hasta la versión 340.108. Cuando lo tengamos claro, nos descargamos el controlador adecuado, extraemos el paquete, y posteriormente nos descargamos este archivo en el mismo directorio raíz en el que hayamos extraído el paquete. Lo abrimos con un editor de texto y cambiamos el número de versión en la línea 45, para posteriormente ejecutarlo.
Finalmente copiamos los archivos correspondientes al directorio que previamente hemos creado, /lib/firmware/nouveau. A continuación muestro todo el proceso de descarga e instalación del firmware en un sistema de 64 bits multiarquitectura, utilizando el comando sed para modificar el número de versión. Los usuarios de sistemas de 32 bits sólo tienen que cambiar x86_64 por x86 en los comandos siguientes:
Actualizando esta sección tras haberme comprado una GeForce GT 710, reseñar que este script sólo es compatible como máximo con los archivos instaladores de la serie 340, y no superiores. Por lo tanto, sólo sirve con tarjetas gráficas que soporten este controlador en concreto o los inferiores incluidos en el script. Y reseñar también tras haberme pasado a una GeForce GTX 750 Ti, que la aceleración de vídeo por hardware sólo es compatible con las GPU de nombre en código Kepler e inferiores. 3) Configurar el ajuste automático del DPI y el Gamma de la pantalla a) DPI Nouveau hace caso omiso del DPI que establezcamos introduciendo las medidas de la pantalla de nuestro monitor en el archivo de configuración de Xorg, /etc/X11/xorg.conf, como voy a demostrar a continuación. Para saber el DPI de nuestro monitor, basta irse a este enlace, introducir la resolución nativa del mismo y el tamaño en pulgadas de la pantalla. Ejemplo: 1920x1080 + 21.5 pulgadas = 102.46 ppp. Que trasladado en milimetros al archivo de configuración de Xorg es un tamaño de monitor de 477mm x 268mm y un DPI redondeado (no se admiten decimales) de 102, cuya información nos mostrará el archivo de registro de inicio del servidor gráfico, si configuramos correctamente dicho archivo.
Y lo establecemos en la sección dedicada al monitor en el dicho archivo. Un ejemplo que pongo a continuación (lo que está en rojo).
Pero Nouveau omite el DPI que establezcamos en dicho archivo, dejándolo en 96 ppp. como muestra el mismo archivo de registro de ejecución de Xorg, cambiando posteriormente al haber establecido el DPI en el mismo proceso de inicio, el tamaño de la pantalla.
La única solución pasa por hacerlo de forma manual, e incluir el comando de ejecución de Xrandr en los scripts de inicio del servidor gráfico X, en unos casos, en otros se le puede pasar la opción -dpi "valor" al ejecutable Xorg. Con Qingy y SLiM lo podemos hacer de una manera muy fácil, pero aún así en estos casos concretos, la ejecución con el comando startx en el primero, también debería de tener el correspondiente comando de ejecución en el archivo personal ~/.xinitrc. Una vez sabemos el DPI, sólo nos queda saber el identificador de conexión de nuestro monitor. Abrimos una ventana de terminal y ejecutamos el comando xrandr sin ninguna opción añadida.
Como se puede ver en el ejemplo, el identificador en este caso, es HDMI-1, que es la entrada de la tarjeta gráfica a la que tengo conectado el monitor con un cable HDMI. Y ahora sólo queda configurar el comando de ejecución, que vamos a probar de forma directa, en la misma ventana de terminal:
Con el comando xdpyinfo, comprobamos el DPI que hemos establecido con el comando xrandr. Ejecutando un programa como MuPDF también lo podemos saber de forma visual, ya que en el título de la ventana del mismo nos muestra siempre el DPI actual de la pantalla, cuando abrimos un archivo PDF con el mismo.
Una vez tenemos el comando correspondiente, vamos con el segundo apartado que Nouveau se pasaba por el forro. b) Gamma En las últimas versiones de Xorg y Nouveau el gamma del monitor ya es configurable desde el archivo de configuración, /etc/X11/xorg.conf, cosa que no sucedía con versiones anteriores. Basta abrir dicho archivo y añadir la entrada correspondiente en la sección correspondiente. Tomando como valor los que obtengamos con el comando xgamma, por ejemplo xgamma -gamma 0.5 y, comprobando que el brillo sea el adecuado a la salud de nuestros ojos.
Para los usuarios que sigan teniendo problemas con esta configuración (desconozco si con tarjetas gráficas antiguas es también funcional) dejo la información que ya existía en esta sección, y que, entiendo no es nada recomendable quitar de este manual. Uno de los peores defectos que tenía Nouveau como controlador de gráficos era la omisión que hacía por defecto de la configuración del Gamma del monitor que teníamos establecida en el archivo de configuración, xorg.conf. Tampoco aceptaba los parámetros relativos al gamma que le pasábamos de forma directa al ejecutable Xorg. Esto nos obligaba a tener que hacer uso de la utilidad xgamma o xrandr (el primero es más sencillo de configurar), insertando el comando correspondiente en los scripts de inicio pertinentes del servidor gráfico X o en el caso de que utilicemos el comando startx para iniciar la sesión gráfica, en el correspondiente archivo ~/.xinitrc. Tener en cuenta que dichos archivos de ejecución suelen ser sustituidos cada vez que se actualiza Xorg y sus componentes a una nueva versión, con lo que, tendremos que volver a editarlos introduciendo el comando correspondiente en los mismos. Cuando tengamos claro el comando a utilizar para el nivel de brillo, procedemos a su inserción en función de la forma en que iniciemos la sesión gráfica. Un ejemplo con las distribuciones que tengo instaladas en mi ordenador, incluyendo también los administradores de sesiones cuya documentación se encuentra disponible en esta web. Configuramos el comando de ajuste de DPI y Gamma utilizando el comando según el script de inicio correspondiente. Los usuarios que no tengan problemas con la configuración del gamma en el archivo /etc/X11/xorg.conf omitirán toda la información relativa al mismo, en los comandos que se explican a continuación. DPI+Gamma con xrandr
O de forma separada con xrandr para el DPI y xgamma para el brillo. Los efectos vienen a ser los mismos, pero los comandos son menos liosos. Se utiliza la ruta completa al ejecutable porque en algunas distribuciones no se tiene en cuenta el PATH del sistema para la ejecución de comandos dentro de estos scripts de shell.
1) Para los que inician X desde terminal con el comando startx Editamos el archivo ~/.xinitrc que se encuentra en nuestro home, si no existe lo creamos, y añadimos lo que está en rojo antes del comando de ejecución del entorno gráfico:
2) XDM Editamos el archivo ~/.xsession que se encuentra en nuestro home, si no existe lo creamos, y añadimos lo que está en rojo antes del comando de ejecución del entorno gráfico:
3) OpenMandriva y PCLinuxOS Abrimos como root, con un editor de texto el script de shell, /usr/share/X11/xdm/Xsetup_0 y añadimos lo que está en color rojo. El contenido del script puede variar de una distribución a otra, pero el final del mismo es idéntico. Tener en cuenta que dichos archivos de ejecución suelen ser sustituidos cada vez que se actualiza Xorg y sus componentes a una nueva versión, con lo que, tendremos que volver a editarlos introduciendo el comando correspondiente en los mismos.
4) KDM en Slackware y derivados Abrimos como root, con un editor de texto el script de shell, /etc/kde/kdm/Xsetup y añadimos lo que está en color rojo.
5) LightDM en Debian Abrimos como root, con un editor de texto el script de shell, /etc/X11/Xsession y añadimos lo que está en color rojo, en las primeras líneas del archivo.
6) MDM en LMDE2 Abrimos como root, con un editor de texto el script de shell, /etc/mdm/Init/Default y añadimos lo que está en color rojo, al final del mismo.
7) Qingy Editamos el archivo de configuración de Qingy y añadimos lo que está en rojo en la línea correspondiente relativa a las opciones de inicio del servidor gráfico X.
Editamos los archivos de cada uno de los entornos gráficos que tengamos configurados en el directorio /etc/qingy/Xsessions, y añadimos lo que está en rojo antes del comando de ejecución del entorno. Un ejemplo.
8) SLiM Editamos el archivo .xinitrc de nuestro home previamente configurado para SLiM y añadimos el comando de ejecución al mismo. El problema de añadir el comando a este archivo, es que el brillo del administrador de sesión no lo podemos cambiar, sólo el de la sesión que utilicemos, por eso lo mejor y más recomendable es probar con los script de shell de ejecución del servidor gráfico X.
El DPI se lo podemos pasar también al archivo de configuración global, /etc/slim.conf, en el apartado correspondiente.
Tener en cuenta que el ajuste del DPI del monitor en lo que respecta al servidor gráfico X tiene que ir acompañado siempre de un ajuste global en entornos de escritorio que lo soporten, archivo de configuración ~.Xdefaults, etc. Un ejemplo de archivo de configuración que tendríamos que tener en cuenta al respecto para un monitor TFT. ~/.Xdefaults
3) Activar el soporte de DRI3 en las opciones de configuración del controlador de gráficos Activar el soporte de DRI3 en las opciones de configuración del controlador de gráficos, en el archivo de configuración de Xorg, /etc/X11/xorg.conf puede mejorar de forma significativa el rendimiento de nuestra tarjeta gráfica tanto en 2D como en 3D, siempre y cuando la misma lo soporte. Añadiendo la siguiente opción en la sección correspondiente del archivo de configuración de Xorg, haremos que el controlador intente utilizar DRI3 si la tarjeta gráfica lo permite, si no lo permite utilizará el predefinido DRI2. Tener en cuenta que el uso de DRI3 en nouveau es muy experimental y puede producir artefactos raros en ventanas y gráficos. Si experimentamos cualquiera de estas incidencias, quitaremos esta entrada del archivo de configuración, o simplemente la comentaremos.
Para comprobar en el siguiente inicio de sesión que estamos utilizando DRI3, ejecutamos los siguientes comandos en la terminal, aunque lo notaremos enseguida porque el inicio del servidor gráfico será más rápido y la apertura y cierre de las ventanas también será más rápido.
Y en el caso de OpenGL, con el siguiente comando:
Iniciamos Nouveau Finalmente reiniciamos el sistema y cuando se inicie el servidor gráfico X, comprobamos que todo funciona bien, realizando las pruebas pertinentes. 1) Comprobar la carga del módulo del kernel
2) Comprobar la carga del controlador gráfico para el servidor gráfico X
3) Comprobar la carga del módulo GLX del servidor gráfico X que proporciona aceleración OpenGL por hardware al mismo
Añadiendo la opción Option "AIGLX" "false" al archivo de configuración de Xorg en su correspondiente sección, la aceleración será por software, por si la primera nos da problemas.
4) Comprobar la disponibilidad de aceleración por hardware VDPAU para la decodificación de vídeo con el comando vdpauinfo (Kepler e inferiores) Si la sección Decoder capabilities: apareciera sin valor alguno, sabiendo nosotros que nuestra tarjeta sí soporta esto con el controlador de gráficos original de NVIDIA, significaría que no se ha cargado correctamente el firmware de la tarjeta gráfica, o existe un problema de otra índole. Para probar las bondades de dicha aceleración y compararla con la que teníamos con el controlador de gráficos original de NVIDIA, utilizaremos MPlayer con el siguiente comando:
Para hacerlo permanente, editamos el archivo de configuración de MPlayer y descomentamos la línea 162:
Podemos probar también las opciones de eliminación de ruido y ajuste de nitidez, que proporcionan el firmware de la tarjeta gráfica, aunque mi experiencia personal no es muy satisfactoria. Es evidente que el controlador de gráficos original funciona bastante mejor en este aspecto.
5) Comprobar la disponibilidad de aceleración por hardware VA-API para la decodificación de vídeo con el comando vainfo (Kepler e inferiores) Si nuestra tarjeta gráfica soporta aceleración por hardware para la decodificación de MPEG4 (lo sabremos ya con el comando vdpauinfo), tendremos que añadir la siguiente variable de entorno a nuestro archivo de configuración personal de Bash, ~/.bashrc, si no existe lo creamos.
Cuando lo hayamos hecho, ejecutamos el comando correspondiente para comprobar el soporte de aceleración por hardware VA-API.
MPlayer no soporta VA-API de forma nativa. Tendremos que utilizar VLC o mpv con SMPlayer. En línea de comandos con mpv sería lo siguiente:
6) Comprobar las capacidades OpenGL del sistema con el comando glxinfo
Avanzamos hacia abajo con las flechas direccionales para comprobar que el controlador Nouveau de Mesa está disponible para su uso.
Para una comprobación visual podemos ejecutar cualquiera de los programas de ejemplo instalados con el paquete Mesa demos (glxgears, cuberender, etc.) Incidencias de uso de Nouveau 1) Congelación temporal de la pantalla en procesos de uso intensivo de la CPU Una simple extracción de un archivo comprimido de gran tamaño, combinada con la descarga de un archivo desde internet a máxima velocidad, y tres o cuatro programas que tengamos abiertos o el simple intento de la ejecución de uno, y que intentemos manejar, puede llegar a provocar bloqueos temporales de la pantalla, incluyendo el manejo del puntero del ratón. Tener en cuenta que el bloqueo de la pantalla no equivale nunca a un bloqueo del sistema. Aunque la pantalla nos aparezca congelada de forma temporal, el sistema sigue funcionando sin ningún problema, es decir, ese archivo que nos estamos bajando desde internet no se va a corromper, cosa que sí sería factible y previsible, si el bloqueo fuera del sistema. Con el controlador original de NVIDIA esto también se produce, lo que sucede, es que el bloqueo no afecta nunca al puntero del ratón, que podemos mover sin ningún problema por la pantalla, aunque el resto de elementos no respondan de forma temporal. 2) Corrupción de las pseudotransparencias en aplicaciones, con la extensión Composite del servidor gráfico X desactivada Esto sí que me afecta de lleno. Los usuarios que tenemos desactivada esta extensión por el considerable ahorro de consumo de CPU que supone esta medida, nos encontramos con el uso de Nouveau, que las transparencias de los iconos de aplicaciones como Idesk, tienden a corromperse (no siempre) en el mismo momento que se coloca una ventana sobre los iconos o simplemente se hace clic en uno de ellos. Cuando se coloca la ventana por encima, cuando la retiramos, quedan restos del dibujo de la ventana grabados en la transparencia del icono, y a su vez, también sucede que restos del icono, queden grabados en la ventana. Teniendo que utilizar el comando xrefresh (que no siempre soluciona el tema) o reiniciando el programa haciendo clic con el botón central del ratón sobre los iconos. La corrupción siempre se produce por superposición de un elemento sobre otro, nunca de otro modo, ni al iniciar el programa. Es cierto, que con unos administradores de ventanas el efecto es mayor que con otros, con Fluxbox es simplemente escandoloso.
3) Bloqueo total del sistema reproduciendo un archivo WMV (WVC1) con VLC, utilizando VDPAU como salida de vídeo predefinida Es evidente que a este reproductor siempre se le han atragantado los archivos Windows Media Video y los Real Media Video, pero en este caso no es un atragantamiento cualquiera, es un empacho con salida a "no me queda más remedio que darle al botón de reset de la caja". 4) Mensajes de error del módulo nouveau del kernel al reproducir archivos de vídeo con Xine, utilizando VDPAU como salida de vídeo En beneficio de este programa, hay que decir, que hace tiempo que no se actualiza, por lo que los de los mensajes es hasta cierto punto compresible. Por otra parte, el archivo de ejemplo (MKV 1920x1080) se reproduce sin ningún problema y sin perder fotogramas, sin ningún tipo de retardo ni muestra de artefacto alguno cuando realizamos avances rápidos en la reproducción. En VLC, este mismo archivo de ejemplo, petardea mucho.
Aceleración 3D por software con LLVMpipe Una de las grandes ventajas de Nouveau y Mesa respecto al controlador original de NVIDIA es la posibilidad que nos ofrece de hacer uso de la aceleración 3D por software, lo que coloquialmente entendemos como "tirar de CPU", allí donde tengamos problemas de uso de la predefinida aceleración por hardware. A primera vista puede parecer contraproducente defender el uso de este tipo de aceleración, pero un simple ejemplo práctico, nos confirmará su beneficio indudable. La versión de 32 bits del editor de vídeo, Shotcut para Windows, se cuelga literalmente cuando utilizo la aceleración por hardware, al abrir un archivo de vídeo, y funciona sin ningún problema cuando hago uso de la aceleración por software. Para cualquier tipo de representación en 2D, normalmente nos referimos siempre a ventanas de visualización de vídeo o imagen, este tipo de aceleración nos puede venir muy bien, allí donde la otra nos dé problemas. En el caso de juegos, es evidente que no es la mejor opción posible. Si hemos compilado Mesa con las opciones de configuración establecidas en este manual, dispondremos de tres controladores Gallium para la aceleración por software: LLVMpipe, Softpipe y Swrast. El más potente y el que se carga de forma predefinida es LLVMpipe, que es capaz de aprovechar la capacidad multinúcleo de los procesadores modernos en combinación con LLVM. Está optimizado para sistemas de 64 bits, pero lo podemos utilizar también en sistemas de 32 bits sin ningún tipo de problema. 1) Establecer la aceleración 3D por software con la correspondiente variable de entorno Existen dos formas de establecer la aceleración por software mediante el uso de la variable de entorno definida para ello, una es mediante el uso del comando export antes de ejecutar la aplicación, la otra es escribiendo la variable de entorno justo delante del comando de ejecución de la aplicación, es decir esto:
Es lo mismo que esto:
Si tenemos pensado crear scripts de shell, basta incluir la variable antes del comando de ejecución del programa, un ejemplo:
Para comprobar que estamos utilizando la aceleración por software, utilizaremos el programa glxinfo para ello.
Configurar la aceleración 3D con DRIconf DRIconf es una interfaz gráfica de configuración para las opciones de aceleración 3D que soporte el controlador DRI de nuestra tarjeta gráfica. Entre otra serie de opciones, podremos hacer uso de los filtros de suavizado de bordes, lo que en inglés se denomina antialiasing, creados por el español Jorge Jiménez, con el nombre de Jimenez's MLAA e introducidos en las librerías Mesa a partir de la versión 8. Esto es lo más parecido que podemos encontrar al FSAA o FXAA original según modelos, de nuestra tarjeta gráfica. Si los queremos probar desde línea de comandos, o mediante scripts de shell, basta establecer las correspondientes variables de entorno, teniendo en cuenta que el valor establecido tendrá que estar comprendido entre 2 y 32, aunque por encima de 16, los efectos son inapreciables. Procurar también no utilizarlos al mismo tiempo, porque el resultado puede llegar a ser catastrófico para el rendimiento de la aplicación, aunque es la combinación de los dos la que mejor resultado da sin lugar a dudas. Donde no funcionan los dos juntos es en aplicaciones o juegos de Windows ejecutados con Wine, que utilicen Direct3D. Si utilizan OpenGL ningún problema. De los dos filtros disponibles, pp_jimenezmlaa y pp_jimenezmlaa_color, uno aplica el suavizado sobre la profundidad de la escena y el otro sobre el color, produciendo este último un efecto de borrosidad sobre el texto contenido en la misma. Tener en cuenta que cualquier aplicación de estos filtros, en determinadas condiciones, puede llegar a suponer una ralentización considerable en determinados juegos o aplicaciones. Un valor de 8 puede llegar a ser medianamente aceptable en la mayoría de los casos. En el caso de pp_jimenezmlaa_color, puede ser utilizado en representaciones en 2D. Para probarlos desde línea de comandos o mediante script de shell, establecemos las correspondientes variables de entorno, antes de ejecutar la aplicación correspondiente, en este caso estableceríamos el valor a 16.
Aunque siempre es mejor crear los correspondientes alias o funciones de Bash, para facilitarnos las cosas. En este caso añado también la variable de entorno de depuración de los filtros de postprocesado para que muestren más información de lo que están haciendo, y por último, añado un alias que activa un gráfico en la esquina superior izquierda de la pantalla del juego, que nos mostrará la velocidad de fotogramas de segundo del mismo. Abrimos con un editor de texto, el archivo de configuración de Bash, ~/.bashrc, si no existe lo creamos, y añadimos lo siguiente:
Ahora simplemente con escribir por ejemplo mlaa 16 ya estamos estableciendo la correspondiente variable de entorno de un filtro en concreto, y con un valor de 16. Lo mismo con mlaa_color 16, y para mostrar información de depuración, ejecutamos mlaa_debug. Y para comprobar el número de fotogramas por segundo en la misma pantalla del juego o de la aplicación, ejecutamos opengl_fps. Instalación Dependencias Herramientas de Compilación Entre paréntesis la versión con la que se ha instalado DRIconf para la elaboración de este documento. * Make - (4.2.1) * Gettext - (0.19.8.1) Intérpretes de Lenguaje de Programación * Python - (2.7.15) PyGTK - (2.24.0) Aplicaciones * Xdriinfo - (1.0.5) * Wget - (1.19.5) [1] [1] Requerido para poder descargarnos los iconos del archivo desktop desde internet. Descarga driconf-0.9.1.tar.gz | driconf-0.9.1_es.diff Extracción y Configuración
Explicación de los comandos patch -Np1 -i ../driconf-0.9.1_es.diff : Aplicamos este parche personal que completa y actualiza la traducción al español del programa. También modifica la ruta predefinida de instalación y el archivo desktop incluido en el paquete. Compilación
Instalación como root 
Borrar las locales adicionales instaladas con la utilidad BleachBit
Estadísticas de Instalación de DRIconf
Consumo inicial de CPU y RAM de DRIconf
Archivo de configuración personal
Desinstalación como root 1) MODO TRADICIONAL ********************** 2) MODO MANUALINUX driconf-0.9.1-scripts.tar.gz
Copia de Seguridad como root
Restaurar la Copia de Seguridad como root
Iniciamos DRIconf NOTA: Este programa no está actualizado a los cambios realizados respecto a la ubicación del archivo de configuración del sistema de DRI, que antes se ubicaba en /etc/drirc y ahora, se ubica en /usr/share/drirc.d/00-mesa-defaults.conf. Sólo nos queda teclear en una terminal o en un lanzador el comando driconf, y el programa aparecerá en la pantalla. La primera vez que se inicie creará el archivo de configuración personal de DRI a partir del archivo de configuración del sistema, ubicado en /etc/drirc. En la parte superior de la interfaz gráfica se establecen las opciones de aceleración 3D para todas las aplicaciones y en la parte inferior, se configuran de forma personalizada, añadiendo el usuario el binario ejecutable de la misma y el nombre de la aplicación que le quiera dar. No olvidar esto último, porque es el proceso lo que controla DRI, no el script de ejecución del mismo, en el caso de que lo utilicemos, ni tampoco el cargador, si por ejemplo, estamos utilizando Wine para ejecutar una aplicación de Windows. Las opciones de aceleración 3D que se establezcan mediante la edición del archivo de configuración personal de DRI, siempre serán sobreescritas por las variables de entorno que establezca el usuario, ya sea en línea de comandos, script de shell, o cualquier otro medio para lanzar la aplicación. En el caso de la aceleración 3D por software, es la variable de entorno descrita en este manual la encargada de establecerla, ya que a través de DRI no es posible activar este tipo de aceleración. El modo experto de DRIconf no añade más opciones de aceleración 3D, simplemente expande las soportadas por el controlador DRI de nuestra tarjeta gráfica.
Activar el máximo rendimiento de la tarjeta gráfica Los usuarios del controlador de gráficos de NVIDIA, disponen de 2 modos de ahorro de energía (3 los de Windows), uno es Adaptive (Adaptable) que es el predefinido de la tarjeta gráfica y es con el que funciona siempre de forma fija cuando utilizamos Nouveau como controlador de gráficos, y el otro es Performance (Máximo rendimiento permitido), en el que se utiliza la velocidad de reloj de GPU y RAM máxima permitida por la BIOS de la tarjeta gráfica. Si ejecutamos la herramienta de configuración proporcionada por NVIDIA, nvidia-settings, y nos vamos a la sección PowerMizer, comprobaremos insitu cómo va cambiando de un modo a otro de forma automática, en función de la demanda gráfica del sistema. Si estamos usando KDE, y tenemos los efectos visuales activados, basta desplegar el menú de inicio para que pase de forma automática al modo de máximo rendimiento. Es decir, los usuarios del controlador de gráficos de NVIDIA no tienen de qué preocuparse en lo que al rendimiento de la tarjeta gráfica se refiere, el controlador lo hace todo. Lamentablemente, los usuarios de Nouveau no podemos decir lo mismo, y a continuación voy a explicar cómo hacer uso del máximo rendimiento de la tarjeta gráfica, tomando como referencia la que tengo ahora, una GeForce GTX 750 Ti (nombre en código de la GPU: Maxwell). Reseñar que con una de las anteriores tarjetas que tenía, una GeForce 8400 GS, la ganancia era de 1 MHz. 1) Comprobar que el kernel ha sido compilado con soporte del sistema de archivos virtual, debugfs (CONFIG_DEBUG_FS=y) Esta opción viene activada por defecto en el kernel y resultaría difícil encontrar una distribución que no la tuviera activada. En mi caso la tuve que activar en la correspondiente sección de : Kernel hacking >> Compile-time checks and compiler options >> Debug Filesystem. Basta ejecutar el siguiente comando para saber si nuestra distribución lo tiene activado, un ejemplo con Debian:
2) Añadir la correspondiente entrada al archivo de configuración, /etc/fstab, para que debugfs se monte en el inicio del sistema Abrimos como root, el archivo de configuración /etc/fstab, con un editor de texto y añadimos justo detrás de la última entrada, lo siguiente:
Guardamos el archivo y montamos el sistema de archivos virtual, sistema que se montará de forma automática al inicio del sistema.
3) Comprobar el estado de las frecuencias de reloj de GPU y RAM soportadas por nuestra tarjeta gráfica Ejecutamos el siguiente comando como root:
07: es la frecuencia relativa al modo Adaptive y 0f: es la frecuenta relativa al modo Performance. AC es la frecuencia actual en uso, que como se puede ver es la Adaptive. 4) Activar el máximo rendimiento de la tarjeta gráfica con el comando echo Para activar el máximo rendimiento de la tarjeta gráfica ejecutamos el siguiente comando, siempre como root:
Cada vez que se activa uno de los dos modos, la pantalla parpadea durante 1 segundo. Ahora volvemos a comprobar que tenemos activada la máxima frecuencia permitida por la tarjeta gráfica.
Para volver a la frecuencia anterior, el modo Adaptive, ejecutamos el siguiente comando:
5) Automatizar todo esto con un script de shell El correspondiente script que nos haga la vida mejor no podía faltar y aquí lo dejo. Abrimos un editor de texto y copiamos lo siguiente:
Lo guardamos con el nombre nouveau-perf y lo instalamos en /usr/bin.
Posteriormente configuramos Sudo para poder ejecutar el script como usuario sin necesidad de usar contraseña alguna. Abrimos como root con un editor de texto, el archivo /etc/sudoers y añadimos lo que está en color rojo en la correspondiente sección. El contenido de dicho archivo puede variar en función de como lo tenga cada usuario, esto es un ejemplo.
Sustituir jose por el nombre de usuario de cada uno. Y ahora comprobamos todo lo que hemos hecho con los correspondientes comandos de usuario. A) Activar el máximo rendimiento de la tarjeta gráfica.
B) Activar el rendimiento predefinido de la tarjeta gráfica.
C) Mostrar las opciones de uso del script de shell
6) Crear los correspondientes archivos desktop y entradas de menú de aplicaciones en el caso de los administradores de ventanas Creamos los correspondientes archivos desktop para aquellos usuarios que lo quieran activar desde menús de aplicaciones compatibles con el estándar de freedesktop.org (MATE, LXDE, Fbpanel, etc.). Abrimos un editor de texto y creamos los archivos desktop que pongo a continuación: nouveau-perfa.desktop
nouveau-perfp.desktop
Los guardamos con la codificación de caracteres UTF-8 y el nombre correspondiente, y los copiamos en nuestro directorio personal en ~/.local/share/applications.
Cuando los seleccionemos en el menú correspondiente, nos mostrará una ventana de información con la misma salida estándar que muestra en la terminal, para que sepamos en todo momento cuál es el modo activo en curso. Los usuarios de administradores de ventanas basta con que añadan los comandos correspondientes adaptados al correspondiente formato de cada menú. Un ejemplo con Fluxbox:
También podemos crear scripts de shell, en los que podemos incluir dichos comandos, antes de iniciar el juego y después de finalizarlo. Esto es útil en aquellos juegos que tenemos configurados con un determinado grado de brillo de la pantalla, y para no estar constantemente ajustando antes de empezar el juego, lo metemos todo en un script de shell. Un ejemplo imaginario concreto con un juego de Windows ejecutado con Wine:
Pros y contras de utilizar Nouveau 1) Pros * Es la única forma posible de no tener que tirar nuestra tarjeta gráfica a la basura, cuando NVIDIA deje de dar soporte al controlador de la misma. * El sistema y sus aplicaciones, consumen mucha menos memoria que con el controlador de NVIDIA. * Por norma general, NVIDIA tarda en actualizar su controlador a los cambios realizados en el kernel y en el servidor gráfico X. Con Nouveau nos olvidamos de este inconveniente. * Posibilidad de hacer uso de la aceleración 3D por software, algo que el controlador de NVIDIA no soporta. * Funciona en aplicaciones de Windows ejecutadas con Wine que no son compatibles con el controlador de NVIDIA. El rendimiento en éstas es sencillamente extraordinario. 2) Contras * Su integración con el kernel provoca que un cuelgue del controlador lleve consigo un cuelgue general del sistema que nos recuerde que la caja del ordenador tiene un botón de reset. * No soporta CUDA ni el estándar abierto alternativo, OpenCL. Los usuarios que requieran de estas características para su trabajo diario se lo pensarán dos veces antes de utilizar este controlador. Tampoco soporta Vulkan, que será el sustituto de OpenGL en un futuro no demasiado lejano. * La decodificación de vídeo por hardware está dando muchos problemas con las últimas versiones del kernel. No es nada recomendable hacer uso de la misma a fecha de hoy. * El rendimiento 3D con juegos y, sobre todo, la calidad de imagen (nada de FSAA, FXAA, filtrado anisotrópico, etc), siempre será inferior al controlador de NVIDIA. * El desarrollo de las librerías Mesa está volcado en los controladores de AMD e Intel, siendo siempre los cambios relativos a Nouveau mucho menos significativos. Enlaces http://nouveau.freedesktop.org >> La web de Nouveau. http://dri.freedesktop.org >> La web de Libdrm. http://freedesktop.org/wiki/Software/VDPAU >> La web de Libvdpau. https://01.org/linuxmedia/vaapi >> La web de Libva. http://www.mesa3d.org >> La web de Mesa y GLU. http://glew.sourceforge.net >> La web de GLEW. http://freeglut.sourceforge.net >> La web de FreeGLUT. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
 |
 |
 |
 |
 |
