Publi

Configuración Nvidia Optimus con driver privativo y Bumblebee.

Dos monitores con Nvidia y Bumblebee

La semana pasada hablaba sobre el estado del soporte Optimus para gráficos híbridos Intel+Nvidia en GNU/Linux. Aunque tenemos varias formas de implementar ese soporte en nuestro sistema operativo, finalmente me he decantado por instalar Bumblebee que hará que sólo las aplicaciones que utilicen la gráfica discreta (la Nvidia) la activen y la utilicen, para todo lo demás, utilizaré la Intel que, no es mala tarjeta, funciona muy bien, y consume menos energía. Iba a publicar también mi configuración en ese post, pero vi que la cosa se empezó a alargar demasiado y decidí dividirlo en dos.

¿Yo? ¿Utilizando los drivers privativos? Le di una oportunidad a nouveau, pero en mi ordenador no va demasiado bien

Preámbulo e indignaciones varias

El problema, como en muchas ocasiones es la falta de soporte oficial de la tecnología en GNU/Linux. Nvidia, después de unos años sin dar señales de vida y no querer dar soporte oficial a la tecnología, a pesar de que este sistema operativo se utiliza mucho para el GPGPU. Vamos, que como supuestamente sólo somos un 2% y todos los ordenadores que se venden vienen con Windows, no merece la pena hacer un driver para esta tecnología.

Así que, si te comprabas un portátil hace 6 años, con los dos chips gráficos. Sólo te tocaba rezar para que la tarjeta Intel funcionara bien para tener entorno gráfico, mientras tenías una Nvidia que sólo valía para consumir energía porque no podías desactivarla.

Aunque poco a poco toda la comunidad se ha puesto en marcha y gracias a la ingeniería inversa de muchos, la paciencia de otros y la buena voluntad de cientos de desarrolladores, empezamos pudiendo activar y desactivar tarjetas, con lo que, aunque sólo tuviéramos una Nvidia, podíamos activarla y desactivarla, para utilizar aplicaciones GPGPU. Aunque no estábamos ni por asomo a la altura de Windows. Luego vino Bumblebee para finales de 2012, soporte en el driver nouveau y finalmente soporte oficial por parte de Nvidia, con Nvidia Prime y soporte en los drivers oficiales.

Repaso rápido a cada una de las tecnologías

Siempre me voy a centrar en portátiles que tengan la tecnología Optimus, que cuenten con una tarjeta gráfica integrada Intel y otra gráfica discreta Nvidia.

Con el driver Nouveau + Intel, tendremos un sistema con drivers libres. Eso está muy bien, y podremos utilizar las dos, que es lo ideal, sólo hace falta definir una variable antes de ejecutar un programa. Esa variable puede ser de entorno, por lo que todas las aplicaciones con dicha variable utilizarán la gráfica que le digamos.

Está bien, pero siempre irá por detrás. Con los últimos modelos de Nvidia no funcionará (los drivers de Windows siempre irán un paso o dos por delante). Incluso, aunque ha habido muchos avances en estos años, no es todo lo estable que me gustaría, ni consigo el rendimiento que me gustaría y no es tan fácil hacer funcionar cosas como CUDA.

Con Primus. Aunque se define como la opción que viene para quedarse, lo más estable y la única soportada oficialmente. Y, nos permite utilizar las dos gráficas. Pero tenemos que cerrar la sesión iniciada con Intel para empezar una nueva sesión con Nvidia y viceversa. Es decir, no podemos tener una aplicación usando Intel y otra Nvidia. Por lo que el ahorro de energía de Optimus se va al traste, ya que al final, terminamos iniciando siempre la sesión con Nvidia. Es más, en algunas máquinas, puede que por el kernel, por los propios drivers de Nvidia, o por algo desconocido que impide logear, a veces se puede congelar el sistema al hacer el cambio. Otras veces no, pero al final es una lotería. Puede que sea sólo de determinada CPU/placa base… pero mi equipo, a veces se cuelga al hacer 2 cambios, otras veces 3… así que lo más seguro es reiniciar. Con la pereza que conlleva.

Con Bumblebee. Es una forma no soportada oficialmente, casi sin mantenimiento, pero se basa en algo sencillo: tu sesión es con la tarjeta integrada, pero si quieres una aplicación con la tarjeta discreta, se inicia una sesión X virtual y se copiará la ventana a tu sesión con la integrada. Por lo tanto el tema de actualizaciones en Bumblebee tampoco es tan tan importante si se actualiza el servidor X y los drivers. Lógicamente el transporte gastará algo de memoria, CPU y bajará el rendimiento, pero en la práctica se puede conseguir algo bastante decente. A veces, hay alguna aplicación que no va bien con la tarjeta discreta (aunque iniciando con Primus funciona bien), pero por lo general va bien.

Configurando Bumblebee

Aunque actualmente estoy con Linux Mint 18.2 (Sonya), esta configuración es válida para Ubuntu y derivados y, si me apuras, para Debian. Os detallo mi configuración:

Consideraciones ante cuelgues y bloqueos

Puede que haya que reiniciar el ordenador en algunos pasos. Por lo que puedes mirar la guía desde el móvil e ir haciendo los pasos si lo deseas. Y también es posible que el ordenador no arranque bien al hacer algunos pasos o no hacerlos completos. En fin, es muy fácil quedarte a oscuras y que no arranque el ordenador. En mi caso, muchas veces el ordenador no respondía al iniciar el sistema gráfico, por lo que cuando el ordenador está arrancando pulso Shift o Escape para que salga el diálogo de grub. Con la tecla e edito el arranque que voy a utilizar y en la línea de argumentos del kernel (que suele poner quiet splash) añado “single” por lo que entraré en un modo de recuperación que podré utilizar en consola. También podemos eliminar quiet splash para que, en lugar de salir la pantalla bonita de espera, veamos todos los mensajes que se van generando en el arranque. A lo mejor alguno nos puede dar una pista.

Instalar driver Nvidia

Vamos a instalar los drivers de Nvidia. Ahora mismo tengo instalada la versión 384.69 sin problemas. Aunque debería funcionar con versiones más nuevas. Para instalar los últimos drivers:

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-384

Podríamos instalar los drivers desde el administrador de controladores. Se instalarán más cosas, como Nvidia Prime, que no pasa nada si lo tenemos instalado (en modo Intel).
Administrador de controladores Nvidia
Y los drivers para CUDA que, si los necesitamos, lo podremos instalar con:

sudo apt-get install nvidia-cuda-toolkit

Algo recomendado, aunque no obligatorio, es quitar los drivers nouveau antes que nada. Aunque muchas veces, el driver oficial de Nvidia lo elimina:

sudo apt-get purge xserver-xorg-video-nouveau

Instalar Bumblebee

En las últimas versiones de Ubuntu este paquete viene actualizado. Aunque para versiones anteriores (y para Linux Mint), debemos añadir un nuevo PPA. Aunque el sistema nos permite utilizar ese paquete, personalmente me ha funcionado mejor el que viene del PPA:

sudo add-apt-repository ppa:neon1ks/bumblebee
sudo apt-get update
sudo apt-get install bumblebee bumblebee-nvidia

Esto debería instalar primus, que es como el Nvidia Prime libre, luego veremos por qué estos nombres tan raros… aunque algunos ya habréis encontrado la relación. Si vemos que primus no está instalado:

sudo apt-get install primus

Luego veremos cómo podremos instalar otro modo de transporte.

Configuración de Bumblebee

La configuración de Bumblebee está en /etc/bumblebee/bumblebee.conf :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# Configuration file for Bumblebee. Values should **not** be put between quotes

## Server options. Any change made in this section will need a server restart
# to take effect.
[bumblebeed]
# The secondary Xorg server DISPLAY number
VirtualDisplay=:8
# Should the unused Xorg server be kept running? Set this to true if waiting
# for X to be ready is too long and don't need power management at all.
KeepUnusedXServer=false
# The name of the Bumbleblee server group name (GID name)
ServerGroup=bumblebee
# Card power state at exit. Set to false if the card shoud be ON when Bumblebee
# server exits.
TurnCardOffAtExit=false
# The default behavior of '-f' option on optirun. If set to "true", '-f' will
# be ignored.
NoEcoModeOverride=false
# The Driver used by Bumblebee server. If this value is not set (or empty),
# auto-detection is performed. The available drivers are nvidia and nouveau
# (See also the driver-specific sections below)
Driver=nvidia
# Directory with a dummy config file to pass as a -configdir to secondary X
XorgConfDir=/etc/bumblebee/xorg.conf.d
# Xorg binary to run
XorgBinary=/usr/lib/xorg/Xorg

## Client options. Will take effect on the next optirun executed.
[optirun]
# Acceleration/ rendering bridge, possible values are auto, virtualgl and
# primus.
Bridge=auto
# The method used for VirtualGL to transport frames between X servers.
# Possible values are proxy, jpeg, rgb, xv and yuv.
VGLTransport=proxy
# List of paths which are searched for the primus libGL.so.1 when using
# the primus bridge
PrimusLibraryPath=/usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus
# Should the program run under optirun even if Bumblebee server or nvidia card
# is not available?
AllowFallbackToIGC=false


# Driver-specific settings are grouped under [driver-NAME]. The sections are
# parsed if the Driver setting in [bumblebeed] is set to NAME (or if auto-
# detection resolves to NAME).
# PMMethod: method to use for saving power by disabling the nvidia card, valid
# values are: auto - automatically detect which PM method to use
#         bbswitch - new in BB 3, recommended if available
#       switcheroo - vga_switcheroo method, use at your own risk
#             none - disable PM completely
# https://github.com/Bumblebee-Project/Bumblebee/wiki/Comparison-of-PM-methods

## Section with nvidia driver specific options, only parsed if Driver=nvidia
[driver-nvidia]
# Module name to load, defaults to Driver if empty or unset
KernelDriver=nvidia-384
PMMethod=auto
# colon-separated path to the nvidia libraries
LibraryPath=/usr/lib/nvidia-384:/usr/lib32/nvidia-384:/usr/lib/nvidia-384/vdpau:/usr/lib32/nvidia-384/vdpau
# comma-separated path of the directory containing nvidia_drv.so and the
# default Xorg modules path
XorgModulePath=/usr/lib/nvidia-384/xorg,/usr/lib/xorg/modules
XorgConfFile=/etc/bumblebee/xorg.conf.nvidia

## Section with nouveau driver specific options, only parsed if Driver=nouveau
#[driver-nouveau]
#KernelDriver=nouveau
#PMMethod=auto
#XorgConfFile=/etc/bumblebee/xorg.conf.nouveau

Básicamente tenemos que decir que:

  • Driver=nvidia
  • KernelDriver=nvidia-384
  • LibraryPath=rutas donde está el driver de nvidia. Podemos verlo con $ sudo dpkg-query -L nvidia-384
  • XorgModulePath=rutas donde están los drivers para Xorg

Está bien echar un rato a ver para qué valen las demás opciones, sobre todo TurnCardOffAtExit y NoEcoModeOverride que nos pueden ayudar a solucionar problemas en nuestro ordenador.

Ahora, muy importante, añadir a nuestro usuario al grupo bumblebee:

sudo gpasswd -a usuario bumblebee

Adicionalmente, tenemos que indicar las bibliotecas que se utilizarán para ejecutar programas que requieran gráficos. Las configuraciones a modificar son:

  • i386-linux-gnu_gl_conf
  • x86_64-linux-gnu_egl_conf
  • x86_64-linux-gnu_gl_conf

Y podemos modificarlo con:

sudo update-alternatives --config i386-linux-gnu_gl_conf
Existen 3 opciones para la alternativa i386-linux-gnu_gl_conf (que provee /etc/ld.so.conf.d/i386-linux-gnu_GL.conf).
Selección   Ruta                                      Prioridad  Estado
------------------------------------------------------------
0            /usr/lib/nvidia-384/alt_ld.so.conf         8604      modo automático
* 1            /usr/lib/i386-linux-gnu/mesa/ld.so.conf    500       modo manual
2            /usr/lib/nvidia-384-prime/alt_ld.so.conf   8603      modo manual
3            /usr/lib/nvidia-384/alt_ld.so.conf         8604      modo manual
Press  to keep the current choice[*], or type selection number:

Y marcar la opciónn 1 a mano. El objetivo es no utilizar nvidia aquí.

O podemos hacerlo del tirón de la siguiente forma:

sudo update-alternatives --set i386-linux-gnu_gl_conf /usr/lib/i386-linux-gnu/mesa/ld.so.conf
sudo update-alternatives --set x86_64-linux-gnu_egl_conf /usr/lib/x86_64-linux-gnu/mesa-egl/ld.so.conf
sudo update-alternatives --set x86_64-linux-gnu_gl_conf /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf

Configuración de xorg

A estas alturas de la vida, Xorg es lo suficientemente listo como para configurarse solo. Al encontrar solamente el driver de Intel cargado en el kernel, será la Intel la única que cargue. De todas formas es interesante tener un fichero /etc/X11/xorg.conf en el que basarnos para una configuración detallada.

Debemos, en principio ver dónde están las tarjetas enchufadas con:

lspci | egrep ‘VGA|3D’
00:02.0 VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 06)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev ff)

Vemos que la Nvidia está en 01:00.0 y la Intel en 00:02.0 . Lo primero será buscar en /etc/bumblebee/xorg.conf.nvidia la línea BusID y asegurarnos de que apunta al puerto correcto: “PCI:01:00:0” como vemos aquí:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Section "ServerLayout"
    Identifier  "Layout0"
    Option      "AutoAddDevices" "false"
    Option      "AutoAddGPU" "false"
EndSection

Section "Device"
    Identifier  "DiscreteNvidia"
    Driver      "nvidia"
    VendorName  "NVIDIA Corporation"

#   If the X server does not automatically detect your VGA device,
#   you can manually set it here.
#   To get the BusID prop, run `lspci | egrep 'VGA|3D'` and input the data
#   as you see in the commented example.
#   This Setting may be needed in some platforms with more than one
#   nvidia card, which may confuse the proprietary driver (e.g.,
#   trying to take ownership of the wrong device). Also needed on Ubuntu 13.04.
    BusID "PCI:01:00:0"

#   Setting ProbeAllGpus to false prevents the new proprietary driver
#   instance spawned to try to control the integrated graphics card,
#   which is already being managed outside bumblebee.
#   This option doesn't hurt and it is required on platforms running
#   more than one nvidia graphics card with the proprietary driver.
#   (E.g. Macbook Pro pre-2010 with nVidia 9400M + 9600M GT).
#   If this option is not set, the new Xorg may blacken the screen and
#   render it unusable (unless you have some way to run killall Xorg).
    Option "ProbeAllGpus" "false"

    Option "NoLogo" "true"
    Option "UseEDID" "false"
    Option "UseDisplayDevice" "none"
EndSection

Y, si queremos, podemos crear un fichero /etc/X11/xorg.conf que contenga lo siguiente (aunque no es obligatorio, crearlo. Es más, lo podemos borrar, o renombrarlo para que Xorg tome sus decisiones):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Section "ServerLayout"
    Identifier "layout"
    Screen 0 "intel"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0@0:2:0"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"     
EndSection

Y podemos añadir o eliminar características desde ahí.

Blacklists de módulos

Debemos asegurarnos de que todo se ha instalado bien y se han anulado ciertas cosas:

cd /etc/modprobe.d/
egrep ‘nouveau’ *

Debe aparecer por algún lado la línea

blacklist nouveau

Seguramente por parte del driver de Nvidia. Si no aparece, podemos crear un archivo llamado “nonouveau.conf” con esa línea y listo.

Por otro lado, tendremos un archivo llamado bumblebee.conf en ese directorio al que debemos añadir (si no están) las siguientes líneas:

1
2
3
4
5
6
blacklist nvidia-384
blacklist nvidia-384-updates

blacklist nvidia_drm
blacklist nvidia_modeset
blacklist nvidia_uvm

Es importante introducir en la blacklist la versión de nvidia que estemos utilizando.

Cuando hagamos un cambio en algún fichero dentro de este directorio debemos ejecutar:

sudo update-initramfs -u

Configurar el kernel

En muchos ordenadores tal vez funcione todo tal cual. Y podremos reiniciar sin miedo. Aunque en otros portátiles tendremos que jugar un poco con la configuración del kernel. No sólo si usamos Bumblebee, si usamos Prime también. Algunas de las causas pueden ser cuelgues o kernel panics (que ni con REISUB se arreglan).

Esto tendremos que investigarlo un poco. Si tenemos comportamientos extraños, debemos buscar nuestro modelo de portátil por Internet a ver si alguien ha dado con la clave. Aunque también podemos investigarlo un poco nosotros. Eso sí, si buscamos la solución por Internet, debemos darle una vuelta nosotros, puede que muchas cosas no sean necesarias o que, con una actualización del kernel, no hagan falta o hayan cambiado. Tendremos que ver para qué versión del kernel son dichas configuraciones y qué versión tenemos nosotros.

Lo más común es modificar acpi_osi (en los parámetros de línea de comandos del kernel), que modifica el tipo de soporte ACPI de nuestro sistema. Para ello, editamos el archivo /etc/default/grub como root y modificamos la línea que empieza como GRUB_CMDLINE_LINUX_DEFAULT (línea que suele tener sólo quiet splash), añadiendo dentro de las comillas acpi_osi=xxxx.

En mi caso, para un ASUS GL552VW debo dejarlo así:

1
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=! acpi_osi=\"Windows 2009\""

En este caso el \” lo ponemos para escapar las comillas. Es decir, como el parámetro va entre comillas dobles, si ponemos unas comillas dobles entre medias, esto se interpretará como fin del parámetro, pero queremos que se interpreten las propias comillas, y que, por tanto, el kernel reciba las comillas. Como normalmente los ordenadores suelen venir con Windows, podemos pensar en la versión de Windows que venía con el portátil, o al menos, la versión de Windows más antigua compatible, en este caso “Windows 2009” es Windows 7.
En mi caso, a partir del kernel 4.8 no tendremos que preocuparnos de los sleep modes ni nada para estos modelos. Pero podemos probar con otras configuraciones para ver si funciona mejor. Más información sobre parámetros del kernel aquí. Se puede utilizar acpi_backlight=native si tenemos problemas de brillo de pantalla y la opción idle=nomwait si tenemos problemas de rendimiento.

Otras cosas que no están de más, por ejemplo es desactivar el gpu manager de Ubuntu. Para ello, en la misma línea de configuración de antes podemos añadir nogpumanager dejándola así:

1
GRUB_CMDLINE_LINUX_DEFAULT="nogpumanager quiet splash acpi_osi=! acpi_osi="Windows 2009""

Así desactivamos la detección automática de GPU de Ubuntu, carga automática de módulos y demás.

Tras ello debemos ejecutar:

sudo update-grub

Probar configuración

Hecho esto podremos reiniciar nuestro equipo. Y deberíamos poder utilizar Optimus sin problema. Lo primero es asegurarnos de que no estamos ejecutando prime en modo Nvidia (si lo hemos instalado), para ello ejecutamos:

prime-select query
Intel

Si estamos en modo Nvidia podemos ejecutar:
prime-select intel

O hacerlo desde nvidia-settings. Cuando estemos en modo Intel, modemos desinstalar nvidia-prime con apt-get remove si queremos. Así no cambiamos de modo gratuitamente.

Una vez en modo gráfic con la tarjeta Intel, otra prueba que podemos hacer es ejecutar xrandr, veremos cómo los nombres de los dispositivos de salida son más normales (en modo Nvidia tendríamos nombres como HDMI-1-1, HDMI-1-2…) ahora tendremos algo como:

xrandr
Screen 0: minimum 320 x 200, current 3000 x 1920, maximum 8192 x 8192
eDP-1 connected primary 1920×1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
1920×1080     60.00*+  59.93
1680×1050     59.95    59.88
1600×1024     60.17
1400×1050     59.98
1280×1024     60.02
1440×900      59.89
1280×960      60.00
1360×768      59.80    59.96
1152×864      60.00
1024×768      60.04    60.00
960×720       60.00
928×696       60.05
896×672       60.01
960×600       60.00
960×540       59.99
800×600       60.00    60.32    56.25
840×525       60.01    59.88
800×512       60.17
700×525       59.98
640×512       60.02
720×450       59.89
640×480       60.00    59.94
680×384       59.80    59.96
576×432       60.06
512×384       60.00
400×300       60.32    56.34
320×240       60.05
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)

Ya estamos preparados para ejecutar, por ejemplo glxgears con nuestra tarjeta Nvidia:

optirun glxgears

Aunque glxgears no es una herramienta para hacer una prueba de velocidad ni nada ya que no sólo genera gráficos sino que genera un tráfico GPU-CPU considerable y desaprovecha muchos recursos. Es más, en ocasiones puede conseguir un framerate mayor con la tarjeta Intel, más que nada porque la copia de datos entre GPU y CPU será más rápida (recordemos que la GPU intel está integrada dentro de la CPU).

Si tenemos algún problema al arrancar ahora podemos arrancar en modo single y desactivar el demonio bumblebee para depurar:

systemctl disable bumblebeed

También podemos probar iniciarlo a mano cuando arranque el entorno gráfico. Y asegurarnos de que los drivers de nvidia no se carguen automáticamente antes del demonio. Debe ser Bumblebee el que los cargue y descargue cuando lo vea necesario.

Por otro lado, es importante no utilizar directamente primusrun. Aunque optirun utilizará por debajo primusrun, este segundo puede dar algún problema en la imagen. Dejemos que optirun haga lo que tenga que hacer.

Mayor rendimiento con la tarjeta integrada

Puede que no tengamos un framerate decente con la tarjeta Intel porque los renders en pantalla están sincronizados con el monitor o el panel del portátil (sincronización vertical). Esto lo podemos solucionar haciendo:

vblank_mode=0 glxgears

Si ahora tenemos muchos más fps ya tenemos el problema. Para hacerlo permanente, tendremos que editar (o crear) un archivo llamado .drirc en nuestro $HOME con lo siguiente:
1
2
3
4
5
<device screen="0" driver="dri2">
    <application name="Default">
        <option name="vblank_mode" value="0"/>
    </application>
</device>

VirtualGL como medio de transporte

Aunque Bumblebee funciona muy bien con Primus, en ocasiones otro medio como VirtualGL funcionará mejor. Es más, nos vale para experimentar y ver cómo va todo. Este medio de transporte será el que lea el display virtual (con la tarjeta discreta) y nos traiga los datos al display principal (con la tarjeta integrada). Además, con VirtualGL podremos modificar muchos aspectos del transporte y, luego podremos utilizarlo para muchas cosas, como utilizar aplicaciones gráficas en red, cosa muy interesante.

VirtualGL no viene en los repositorios oficiales, y los PPA que he encontrado son algo antiguos. Así que lo mejor sería descargar el .deb (afortunadamente lo tenemos y no tenemos que compilar). Lo podemos descargar desde sourceforge yendo a la versión que queremos descargar (siempre es mejor usar la última), y desde ahí descargar la versión para i386 o amd64. Una vez descargada, la podemos instalar con dpkg:

sudo dpkg -i virtualgl_2.5.2_amd64.deb

VirtualGL, instalará una aplicación que vale mucho más para hacer benchmarking y probar el rendimiento de las dos tarjetas. Y que, nos permitirá hacer pruebas de los métodos de transporte y ver qué va mejor en nuestro sistema. glxspheres. Podemos hacer:

optirun /opt/VirtualGL/bin/glxspheres64

glx spheres. Benchmark 3D.

Una vez que estamos aquí, podemos ejecutar aplicaciones utilizando VirtualGL de la siguiente forma:

optirun -b virtualgl /opt/VirtualGL/bin/glxspheres64

Y, dentro de VirtualGL podemos utilizar varios sistemas de compresión de datos para el transporte: proxy, jpeg, rgb, xv y yuv; cada uno de ellos aumentará o disminuirá el rendimiento, funcionará mejor con algunas aplicaciones y también hará más o menos uso de CPU. El objetivo es probarlas y ver la que mejor nos funciona. Incluso podemos tener varias aplicaciones cada una utilizando un método de transporte diferente.

Para cambiar el método de transporte podemos hacer:

optirun -b virtualgl -c [metodo_de_transporte] /opt/VirtualGL/bin/glxspheres64

Y, si nos resulta mucho más útil VirtualGL que Primus, podemos definirlo en /etc/bumblebee/bumblebee.conf y ponerlas por defecto.

Ejecutar nvidia-settings

Si tenemos el driver de nvidia. ¡Qué menos que poder acceder a la configuración! Podemos hacerlo así:

optirun nvidia-settings -c :8

nvidia-settings

Ejecutar aplicaciones CUDA

Si queremos utilizar aplicaciones que utilicen CUDA. Además de tener nvidia-cuda-toolkit instalada, en el fichero /etc/bumblebee/bumblebee.conf , en el apartado KernelDriver, en lugar de cargar KernelDriver=nvidia-384 debemos cargar:

1
KernelDriver=nvidia-384-uvm

Con esto, el driver nvidia-384 se cargará automáticamente y si la aplicación que cargamos con optirun necesita CUDA, lo detectará y podrá usarlo sin problema. Probemos con Blender:

optirun blender

Blender Optirun

Información de la ejecución

Aunque tenemos varios applets para nuestros entornos de escritorio (y alguna aplicación para gestionar optirun, que sí que no se mantiene ya), me voy a centrar de herramientas en consola. La primera, será para ver el estado de la tarjeta discreta:

cat /proc/acpi/bbswitch
0000:01:00.0 OFF

Lo podemos cambiar a mano, escribiendo “ON”, “OFF” en el fichero como root, aunque Bumblebee se encargará de gestionar esto. Esta información nos vale para indicarnos si algo se ha quedado pillado o un programa que usa GPU no se ha cerrado del todo.

Lo siguiente será pedir información a optirun de la sigiente forma:

optirun --status
Bumblebee status: Ready (3.2.1). X is PID 18490, 4 applications using bumblebeed.

Y luego podemos conocer las aplicaciones que están utilizando este sistema con un simple ps:

ps ax | grep optirun

Más información y enlaces

También podría interesarte...

There are 2 comments left Ir a comentario

  1. Pingback: Configuración Nvidia Optimus con driver privativo y Bumblebee. | PlanetaLibre /

  2. nasciiboy /
    Usando Mozilla Firefox Mozilla Firefox 55.0 en Fedora Linux Fedora Linux

    gracias por la entrega, aun habiendo manoceado configuraciones esto parece demasiado esoterico y farragoso

Leave a Reply