Para seguir con temas de IA y demás necesito verificar como se comporta el hardware con Linux, y si es posible, con un driver que haga su trabajo.
Y es que los drivers de Linux vienen configurados para que funcionen, pero no para que funcionen bien.
El problema que he visto desde hace mucho tiempo es el mismo.
Foros antes, ahora grupos de telegram donde los comedoritos tácticos de siempre que ni se han molestado en probar otra cosa más allá de su propio libro, se dedican a repetir lo que han leído, o lo que les han dicho, sin probarlo.
Y es que el driver de Intel para Linux, el i915, no es un driver completo de entrada.
Funciona lo justo para mostrar imagen, exponer la GPU lo justito para que no reviente por usuarios básicos y acabar decepcionando a los que sin ser usuarios avanzados quieren ser prosumers y no pueden.
¿Y eso se nota?
Pues claro, clamores desde grupos de telegram con “usa mejor una GPU de Nvidia”, “usa mejor una GPU de AMD aunque no sea tan buena como nVidia”, “usa mejor una GPU de Apple”, que no es que no tengan razón, pero es que no es la única opción sobre todo cuando estamos reciclando hardware como es el caso, e infinitos casos donde la respuesta es “mete una gráfica dedicada aunque sea externa”.
Como si la Señora María (C) Wintablet supiera de que le estamos hablando. Y la Señora María (C) Wintablet está haciendo cursos de IA agéntica para retocar y reparar fotos en local, o almacenar recetas de cocina y que se las cante en modo manoslibres.
Lo primero es que tenemos que entender que no todos los drivers van a estar completamente cargados. Nunca. Ninguna distro va a cargar todos los drivers de todas las piezas de hardware que hay en el mercado.
Y es que el driver de Intel para Linux, el i915, no es un driver completo.
Aquí nos va a faltar intel-media-driver y el de GPU.
Esto es lo que instala por defecto:
Mi víctima va a ser un fichero de tantos de uso libre, como el de la bola del mundo.
Lo he concatenado varias veces para hacer algo un poco más largo, en total de 5 minutos, para que se note la diferencia.
Y esto es lo que hace ffmpeg con el driver que viene por defecto:
El comando ha sido simple:
ffmpeg -i salida.mp4 -c:v libx265 -preset medium -crf 25 -an salida_h265.mkv
Con la intención de convertir el code de video, y ver su tiempo y tamaño de salida.
En este caso, 9010 frames en 171 segundos. No está mal, por encima de 52 frames por segundo, algo por debajo del un 2x.
Revisando el driver, está claro que no se ha usado la GPU, y que se ha hecho todo por CPU.
Con sudo vainfo podemos ver las capacidades, y sorprendentemente solo están cargadas las capacidades de reproducción, pero nada más avanzado.
Vamos a tunear un poco el driver de paso.
En el fichero del módulo i915, que es el driver de Intel, vamos a añadir un par de opciones para que se cargue con más capacidades.
Estará en /etc/modprobe.d/i915.conf o similar, dependiendo de la distro, y añadimos estas líneas según documentación:
options i915 enable_guc=3
options i915 enable_fbc=1
Yo soy mas chulo y solo añado la primera, que es la que se encarga de cargar el GuC, que es el microcontrolador de la GPU, y que es el que se encarga de gestionar las tareas de video.
La segunda opción es la de Frame Buffer Compression, que es una técnica de compresión de video que puede mejorar el rendimiento, pero que no es tan crítica para este caso. Quizás OBS la necesite, pero de momento no la voy a tocar.
¿No hace falta que diga como se instala un driver verdad?
Ni por qué quiero usar un kernel matched, ni por qué quiero usar los módulos y firmware de Intel.
Basta con instalar el paquete de Intel Media Driver, que es el que se encarga de exponer la GPU para tareas de video.
La lista y sus dependencias:
-
intel-media-driver
- libva-intel-media-driver
- intel-vpl-gpu-rt
- intel-gpu-firmware
- intel-audio-firmware
- intel-vsc-firmware
- intel-mediasdk
-
kernel-devel-matched
- kernel-modules
- kernel-modules-extra
Tras reiniciar el sistema, ya tenemos el driver cargado y listo para usar.
Vamos a codificar y luego hago una tabla resumen.
Primero el codificador de VAAPI que hace offload a la GPU, y que es por el que toca modificar el fichero de configuración del módulo, ya el que se encarga de usar el GuC para gestionar las tareas de video.
ffmpeg -vaapi_device vaapi=hw:/dev/dri/renderD128 -i salida.mp4 -vf `format=nv12,hwupload` -c:v hevc_vaapi -gp 25 -an salida_h265.mkv
Y ahora el codificador de QSV por GPU.
ffmpeg -init_hw_device qsv=hw:/dev/dri/renderD128 -filter_hw_device hw -i salida.mp4 -c:v hevc_qsv -global_quality 25 -an salida_h265.mkv
Las cosas quedan listas para sentencia:
| Método | Tiempo (s) | FPS | Tamaño (KB) | Factor |
|---|---|---|---|---|
| CPU | 171 | 52.7 | 13798 | 1,7x |
| VAAPI | 74 | 124 | 18531 | 4,2x |
| QSV | 105 | 86 | 14030 | 2,9x |
Vaapi tiene un rendimiento mayor en cuestión de tiempo pero no en cuestión de tamaño, y QSV tiene un rendimiento menor pero un tamaño más ajustado.
En cualquier caso, ambos métodos son mucho más rápidos que el método por CPU, y eso es lo que realmente importa.
Ahora podéis venir y contarme lo del contenedor de handbrake y por qué no tiene rendimiento de codificación, o el contenedor del jellyfin y cuanto puede transcodificar en tiempo real.
YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://wt.territoriolinux.es/rss/short.xml
Y sin más, os dejo los enlaces:
Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://feeds.ivoox.com/feed_fg_f1563806_filtro_1.xml y YouTube https://www.youtube.com/playlist?list=PLrnymu_aoVL6nk1-FcZ220P65tyHV6djV Canal de YouTube: https://youtube.com/@yovirtualizador
Enlaces afiliados:
Amazon: https://amzn.to/3gX3HmK
Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70
iVoox Plus: https://www.ivoox.vip/plus?affiliate-code=323d07d8569f044513746a1be4724b40
iVoox Premium: https://www.ivoox.vip/premium?affiliate-code=03d0efe2be3b55e4cd6df6dc3f6a6dbc
iVoox Premium anual: https://www.ivoox.vip/premium?affiliate-code=9feb8e44ecb4c97148e227100af9223b
