Source: https://manualinux.eu/nouveau02.html
Timestamp: 2020-06-06 11:12:35+00:00

Document:
Instalar Nouveau desde cero - 02
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
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.
# cat /boot/config-3.16.0-4-686-pae | grep 'CONFIG_DRM_NOUVEAU=m'
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.
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)
GRUB_CMDLINE_LINUX="video=VGA-1:1024x768@85"
Cuando hayamos guardado el archivo, actualizamos el cargador de inicio del kernel, con el comando correspondiente.
$ su -c "update-grub2"
2b) Lilo >> /etc/lilo.conf (Slackware)
append=" vt.default_utf8=0 video=VGA-1:1024x768@85"
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. 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.107.
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.
# The firmware changes fairly rarely. From a limited sample, when the
# firmware does change, the starts of the firmware remain the
# same. When changing the version though, one should double-check the
# sizes, which can be different.
# This is the list of tested versions that produce the same binaries
"319.17",
"319.23",
"319.32",
"325.08",
"325.15",
"340.107",
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:
$ mkdir NVIDIA; cd NVIDIA
$ wget http://us.download.nvidia.com/XFree86/Linux-x86_64/340.107/NVIDIA-Linux-x86_64-340.107.run
# sh NVIDIA-Linux-x86_64-340.107.run --extract-only
# sed -i '45s:340.32:340.107:' extract_firmware.py
# python extract_firmware.py
# mkdir -p /lib/firmware/nouveau
# cp -adf nv* vuc-* /lib/firmware/nouveau
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.
3) Configurar el ajuste automático del DPI y el Gamma de la pantalla
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.
[root@localhost log]# cat /var/log/Xorg.0.log | grep DPI
[ 37.313] (**) NOUVEAU(0): DPI set to (102, 102)
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.
[ 14901.194] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 14901.199] (II) NOUVEAU(0): NVEnterVT is called.
[ 14901.231] (II) NOUVEAU(0): Setting screen physical size to 507 x 285
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.
[jose@localhost ~]$ xrandr
HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
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:
$ xrandr --dpi 102/HDMI-1
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.
[jose@localhost ~]$ xdpyinfo | grep resolution
Una vez tenemos el comando correspondiente, vamos con el segundo apartado que Nouveau se pasaba por el forro.
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.
Gamma 0.50
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
/usr/bin/xrandr --dpi 102/HDMI-1 --output HDMI-1 --gamma 0.50:0.50:0.50
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.
/usr/bin/xrandr --dpi 102/HDMI-1
/usr/bin/xgamma -gamma 0.50
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:
xrandr --dpi 102/HDMI-1 --output HDMI-1 --gamma 0.50:0.50:0.50
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.
if [ -f /usr/share/mdk/backgrounds/default.png ] && [ -f /usr/bin/xloadimage ]; then
/usr/bin/xloadimage -onroot -fullscreen /usr/share/mdk/backgrounds/default.png &
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, al final del mismo.
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.
if test -x "/sbin/initctl" ; then
/sbin/initctl -q emit login-session-start DISPLAY_MANAGER=mdm
mdmwhich () {
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.
x_args = "-nolisten inet6 -deferglyphs 16 -nolisten tcp -br -dpi 102"
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.
xgamma -gamma 0.50
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.
;">E17)
El DPI se lo podemos pasar también al archivo de configuración global, /etc/slim.conf, en el apartado correspondiente.
default_path ./:/bin:/usr/X11R7/bin:/usr/bin:/usr/local/bin
default_xserver /usr/X11R7/bin/X
xserver_arguments -nolisten inet6 -deferglyphs 16 -nolisten tcp -dpi 102
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.
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.
[root@localhost log]# cat /var/log/Xorg.0.log | grep DRI3
[ 8275.850] (II) NOUVEAU(0): DRI3 on EXA enabled
Y en el caso de OpenGL, con el siguiente comando:
[jose@localhost ~]$ LIBGL_DEBUG=verbose glxinfo | grep DRI3
libGL: pci id for fd 4: 10de:128b, driver 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
[jose@localhost ~]$ dmesg | grep nouveau
[ 11.998383] fb: switching to nouveaufb from VESA VGA
[ 11.998521] nouveau 0000:02:00.0: NVIDIA GK208B (b060b0b1)
[ 12.109957] nouveau 0000:02:00.0: bios: version 80.28.b0.00.05
[ 12.110783] nouveau 0000:02:00.0: fb: 2048 MiB DDR3
[ 12.110789] nouveau 0000:02:00.0: priv: HUB0: 085014 ffffffff (1b70820b)
[ 12.772323] nouveau 0000:02:00.0: DRM: VRAM: 2048 MiB
[ 12.772324] nouveau 0000:02:00.0: DRM: GART: 1048576 MiB
[ 12.772328] nouveau 0000:02:00.0: DRM: TMDS table version 2.0
[ 12.772329] nouveau 0000:02:00.0: DRM: DCB version 4.0
[ 12.772331] nouveau 0000:02:00.0: DRM: DCB outp 00: 01000f02 00020030
[ 12.772333] nouveau 0000:02:00.0: DRM: DCB outp 01: 02011f62 00020010
[ 12.772334] nouveau 0000:02:00.0: DRM: DCB outp 02: 02022f10 00000000
[ 12.772336] nouveau 0000:02:00.0: DRM: DCB conn 00: 00001031
[ 12.772337] nouveau 0000:02:00.0: DRM: DCB conn 01: 00002161
[ 12.772338] nouveau 0000:02:00.0: DRM: DCB conn 02: 00000200
[ 12.837085] nouveau 0000:02:00.0: DRM: MM: using COPY for buffer copies
[ 13.078826] nouveau 0000:02:00.0: DRM: allocated 1920x1080 fb: 0x60000, bo ebb97000
[ 13.078882] fbcon: nouveaufb (fb0) is primary device
[ 13.629573] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device
[ 13.634984] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 0
2) Comprobar la carga del controlador gráfico para el servidor gráfico X
[jose@localhost ~]$ cat /var/log/Xorg.0.log | grep 'NOUVEAU driver'
[ 58.876] (II) NOUVEAU driver
[ 58.876] (II) NOUVEAU driver for NVIDIA chipset families :
3) Comprobar la carga del módulo GLX del servidor gráfico X que proporciona aceleración OpenGL por hardware al mismo
[jose@localhost ~]$ cat /var/log/Xorg.0.log | grep 'GLX:'
[ 58.786] (==) AIGLX enabled
[ 58.877] (==) NOUVEAU(0): GLX sync to VBlank enabled.
[ 60.321] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 60.321] (II) AIGLX: enabled GLX_ARB_create_context
[ 60.321] (II) AIGLX: enabled GLX_ARB_create_context_profile
[ 60.321] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
[ 60.321] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 60.321] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 60.321] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
[ 60.321] (II) AIGLX: enabled GLX_ARB_fbconfig_float
[ 60.321] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
[ 60.321] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 60.322] (II) AIGLX: Loaded and initialized nouveau
[ 60.322] (II) GLX: Initialized DRI2 GL provider for screen 0
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
[jose@localhost ~]$ vdpauinfo
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:
$ mplayer -nofs -vo vdpau -vc ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau ejemplo.mkv
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.
$ mplayer -v -nofs -vo vdpau:denoise=0.2:sharpen=0.3 \
-vc ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau ejemplo.mkv
5) Comprobar la disponibilidad de aceleración por hardware VA-API para la decodificación de vídeo con el comando vainfo
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.
export VAAPI_MPEG4_ENABLED=1
Cuando lo hayamos hecho, ejecutamos el comando correspondiente para comprobar el soporte de aceleración por hardware VA-API.
[jose@localhost ~]$ vainfo
vainfo: Driver version: Mesa Gallium driver 20.1.0 for NV106
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:
$ mpv --vo=vaapi --hwdec=vaapi archivo.mkv
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.
OpenGL core profile version string: 4.3 (Core Profile) Mesa 20.1.0
Para una comprobación visual podemos ejecutar cualquiera de los programas de ejemplo instalados con el paquete Mesa demos (glxgears, cuberender, etc.)
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.
[ 530.110057] nouveau 0000:02:00.0: gr: TRAP_PROP - TP 0 - 00000040 [RT_FAULT] - Address 0041a80000
[ 530.110062] nouveau 0000:02:00.0: gr: TRAP_PROP - TP 0 - e0c: 00000000, e18: 00000000, e1c: 00800080, e20: 00001800, e24: 00030000
[ 530.110065] nouveau 0000:02:00.0: gr: 00200000 [] ch 4 [001f939000 xine[3699]] subc 3 class 8297 mthd 1558 data 00000001
[ 530.110076] nouveau 0000:02:00.0: fb: trapped write at 0041a80000 on channel 4 [1f939000 xine[3699]] engine 00 [PGRAPH] client 0b [PROP] subclient 00 [RT0] reason 00000002 [PAGE_NOT_PRESENT]
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:
$ briquolo
$ LIBGL_ALWAYS_SOFTWARE=1 briquolo
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.
[jose@localhost ~]$ glxinfo | grep "renderer string"
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.
$ export pp_jimenezmlaa=16
$ export pp_jimenezmlaa_color=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:
mlaa () { export pp_jimenezmlaa=$1 ; }
mlaa_color () { export pp_jimenezmlaa_color=$1 ; }
alias mlaa_debug="export PP_DEBUG=1"
alias opengl_fps="export GALLIUM_HUD=fps"
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.
Entre paréntesis la versión con la que se ha instalado DRIconf para la elaboración de este documento.
PyGTK - (2.24.0)
* Xdriinfo - (1.0.5)
driconf-0.9.1.tar.gz | driconf-0.9.1_es.diff
$ tar zxvf driconf-0.9.1.tar.gz
$ cd driconf-0.9.1
$ patch -Np1 -i ../driconf-0.9.1_es.diff
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.
# install -m644 driconf.desktop /usr/share/applications
wget -c http://findicons.com/files/icons/1620/\
crystal_project/128/hardware.png -O $i/128x128/apps/driconf.png ; \
crystal_project/64/hardware.png -O $i/64x64/apps/driconf.png ; \
crystal_project/48/hardware.png -O $i/48x48/apps/driconf.png ; \
crystal_project/32/hardware.png -O $i/32x32/apps/driconf.png ; \
crystal_project/24/hardware.png -O $i/24x24/apps/driconf.png ; \
crystal_project/16/hardware.png -O $i/16x16/apps/driconf.png ; \
Estadísticas de Instalación de DRIconf
Ocupación de espacio en disco 216 KB
Consumo inicial de CPU y RAM de DRIconf
driconf 0 % 30,6 MB
~/.drirc Es el archivo de configuración personal de DRI en nuestro home, y es sobre el que trabaja DRIconf.
driconf-0.9.1-scripts.tar.gz
# tar zxvf driconf-0.9.1-scripts.tar.gz
# cd driconf-0.9.1-scripts
# ./Desinstalar_driconf-0.9.1
# ./Respaldar_driconf-0.9.1
# ./Restaurar_driconf-0.9.1
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.
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 GT 710 (nombre en código de la GPU: Kepler). Reseñar que con la anterior tarjeta, 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 configuración: 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:
# root@localhost:/# grep CONFIG_DEBUG_FS /boot/config-4.9.0-5-686-pae
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.
# mount /sys/kernel/debug
3) Comprobar el estado de las frecuencias de reloj de GPU y RAM soportadas por nuestra tarjeta gráfica
[root@localhost jose]# cat /sys/kernel/debug/dri/0/pstate
0f: core 653-954 MHz memory 1800 MHz
AC: core 405 MHz memory 810 MHz
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.
0f: core 653-954 MHz memory 1800 MHz AC DC *
AC: core 953 MHz memory 1800 MHz
Para volver a la frecuencia anterior, el modo Adaptive, ejecutamos el siguiente comando:
# echo 07 > /sys/kernel/debug/dri/0/pstate
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:
echo 07 > /sys/kernel/debug/dri/0/pstate
echo "Uso: nouveau-perf [opciones]
-p Activa el modo de máximo rendimiento de la tarjeta gráfica
-a Activa el modo predefinido de rendimiento de la tarjeta gráfica
-h Muestra este mensaje de ayuda"
Lo guardamos con el nombre nouveau-perf y lo instalamos en /usr/bin.
# install -m755 nouveau-perf /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.
Cmnd_Alias NOUVEAU = /usr/bin/nouveau-perf
USERS ALL = NOPASSWD: NOUVEAU
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.
[jose@localhost ~]$ sudo nouveau-perf -p
B) Activar el rendimiento predefinido de la tarjeta gráfica.
[jose@localhost ~]$ sudo nouveau-perf -a
07: core 405 MHz memory 810 MHz AC DC *
C) Mostrar las opciones de uso del script de shell
[jose@localhost ~]$ sudo nouveau-perf -h
Uso: nouveau-perf [opciones]
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
Name=Nouveau - Adaptive
Comment=Activa el modo predefinido de rendimiento de la tarjeta gráfica
Exec=sh -c 'sudo nouveau-perf -a | xmessage -file - -center'
nouveau-perfp.desktop
Name=Nouveau - Performance
Comment=Activa el modo de máximo rendimiento de la tarjeta gráfica
Exec=sh -c 'nouveau-perf -p | xmessage -file - -center'
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.
$ cp nouveau*.desktop ~/.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.
[exec] (Nouveau - Adaptive) {sudo nouveau-perf -a | xmessage -file - -center} </home/jose/.fluxbox/icons/nouveau.png>
[exec] (Nouveau - Performance) {sudo nouveau-perf -p | xmessage -file - -center} </home/jose/.fluxbox/icons/nouveau.png>
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:
sudo nouveau-perf -p
wine juego.exe
sudo nouveau-per -a
* 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.
* Permite utilizar resoluciones altas en el framebuffer, sincronizando la resolución de éste con la resolución del servidor gráfico X, incluido el control del gamma del monitor.
* Funciona en aplicaciones de Windows ejecutadas con Wine que no son compatibles con el controlador de NVIDIA. El rendimiento en éstas es sencillamente extraordinario.
* 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.
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.

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución