Ubuntu 26.10 Concept en Snapdragon X1 Elite: 44 de 74 benchmarks y las regresiones que duelen

Me encontré con una premisa que se repite mucho en la comunidad ARM de escritorio: “el Snapdragon ya está”. La realidad de la nueva ISO Concept de Ubuntu 26.10 para X1 Elite es otra: no es más rápida, es más inestable. Phoronix corrió la imagen de concepto 26.10 X1E contra el estado de Ubuntu 26.04 LTS en el mismo portátil Acer Swift 14 AI, y el resultado es que la versión nueva ganó 44 de las 74 comparaciones individuales, pero la media geométrica compuesta de todos los resultados se la quedó 26.04. Encima, la GPU volvió a caer en render por software, el equipo se identifica como si tuviera 8 núcleos en lugar de 12, la batería no reporta, el audio no suena y el WiFi se cuelga tras periodos largos de prueba hasta que reinicias.

Esto no convierte a la ISO en un experimento inútil: es el estado real del soporte de Linux en ARM de escritorio a días de la salida de Ubuntu 26.10. Si estás pensando en meter un Snapdragon en tu flujo de trabajo, lo que sigue te ahorra un fin de semana de diagnóstico.

Qué se comparó exactamente: la ISO Concept 26.10 contra 26.04 LTS

La pieza de Phoronix que sirve de base es la review publicada el 26 de octubre de 2026 por Michael Larabel, sobre el Acer Swift 14 AI con su número de modelo SF14-11T-X3RZ. La máquina lleva el Snapdragon X1 Elite en su variante X1E-78100, que es un bloque de 12 núcleos. El protocolo fue simple y por eso los resultados valen: se instaló la ISO Concept 26.10 X1E desde cero sobre el mismo equipo y se comparó contra el estado de Ubuntu 26.04 LTS X1E que ya estaba corriendo ahí.

Un detalle que cambia cómo lees las cifras: el salto de versiones entre ambas no es trivial, aunque parezca un simple cambio de versión. Del kernel 7.0 al 7.3, del compilador GCC 15.2 al 15.3, y un montón de actualizaciones de paquetes en el medio. Ubuntu 26.10 además trae GNOME 51 y ya usa dbus-broker como implementación de D-Bus por defecto.

Y ojo con el nombre, porque aquí es donde se cuelan las confusiones: la imagen que se midió no es la versión final de Ubuntu 26.10, sino una ISO de concepto construida sobre la beta de 26.10. La versión final salió el 15 de octubre de 2026 con kernel 7.3 y GNOME 51, y Canonical ya anunció que trabaja con Qualcomm en una imagen oficial y certificada para Snapdragon X2 apuntando a 2027. La ISO de concepto existe precisamente para llegar a la versión final y cazar errores antes.

cd ~/Descargas
wget https://people.canonical.com/~platform/images/ubuntu-concept/stonking-desktop-arm64+x1e.iso
sha256sum stonking-desktop-arm64+x1e.iso
ls -lh stonking-desktop-arm64+x1e.iso

Canonical publica las imágenes de concepto en el mismo directorio, con nombres que incluyen la fecha de compilación, más un enlace sin fecha que apunta a la última. Ojo con un detalle importante: no hay archivo SHA256SUMS para estas imágenes, a diferencia de las versiones normales de Ubuntu. El hash del comando de arriba te sirve para comparar contra otra descarga tuya o para archivarlo, pero no hay una referencia oficial contra la cual validarlo. Si la descarga se te corta, repite el wget con -c para retomar en vez de empezar de cero.

Los benchmarks: 44 victorias individuales y una media geométrica en contra

Aquí conviene ser preciso, porque las cifras de este artículo de Phoronix no están en el texto plano sino dentro de gráficos SVG. Lo que sí es verificable es qué imagen ganó cada prueba, y eso da un conteo sólido. La ISO 26.10 se llevó 44 de las 74 comparaciones individuales; 26.04 se llevó las 30 restantes. Pero el gráfico final, que es la media geométrica compuesta de todos los resultados, lo ganó 26.04: la versión nueva salió ligeramente por detrás, y el propio artículo lo atribuye a la regresión de Sonic JSON más algunas pérdidas puntuales en casos de OpenVINO.

Familia de prueba	Gana 26.10	Gana 26.04	Lectura
OpenVINO (inferencia en CPU)	7	7	Empate técnico, con casos para cada lado
PyPerformance (Python 3.14)	6	8	Sin diferencias: ambas versiones usan Python 3.14
Sonic JSON	1	3	Regresión fuerte de 26.10, pesa en la media
OpenSSL	3	1	SHA256, AES-256-GCM y ChaCha20 favorecen a 26.10
Compilación (PHP, Wasmer, Erlang, ImageMagick, Godot, GDB)	2	4	26.10 compila más lento en cuatro proyectos grandes
OSPRay, C-Ray, Xcompact3d, ACES DGEMM, 7-Zip, nginx	14	0	Dominio absoluto de 26.10 en render y compresión
Coremark, Stockfish, QuantLib, SIMDjson, RocksDB, SVT-AV1, xfr, GROMACS	11	7	Resultado mixto, con ventaja de 26.10 en ajedrez y en códecs

La lectura honesta de esa tabla es que 26.10 no es una versión más rápida. Es una versión distinta. Donde más se nota la ventaja es en cargas de render y en las que dependen de bibliotecas de terceros que se actualizaron: OSPRay, C-Ray, y 7-Zip, que pasó de la versión 26.00 a la 26.02 dentro del archivo de 26.10. Donde pierde es en compilación de código fuente: Godot, GDB, ImageMagick y Erlang OTP tardaron más en 26.10, y el artículo atribuye eso al simple salto de GCC 15.2 a 15.3, un efecto que el autor dice haber visto también en portátiles x86_64 con la misma distribución.

Un matiz que vale la pena: 26.10 no trae GCC 16 como compilador por defecto, y por eso muchos benchmarks que compilan desde fuente quedaron prácticamente igual. SIMDjson es el ejemplo más claro: el rendimiento se mantuvo sin cambios entre las dos versiones para Linux AArch64. Si alguien te dice que 26.10 es más rápida porque trae un compilador nuevo, te está colando una beta vieja: el compilador por defecto sigue siendo GCC 15.3.

Las regresiones que sí van a afectarte el día a día

Un benchmark es una foto fija. Lo que a un sysadmin le genera un ticket de soporte son las reproducciones, la batería y el WiFi. Y acá es donde la ISO de concepto se pone fea. Estos cinco problemas están documentados en la review del Acer Swift 14 AI con la ISO 26.10 X1E recién instalada:

• La GPU cae a llvmpipe. El driver DRM MSM se queja de no poder encender la GPU. El resultado es que el render va por software. La parte incómoda: la gráfica Adreno funciona en otros portátiles Snapdragon X1 y funcionaba antes en ese mismo Acer, así que es una regresión, no una limitación del hardware.
• La batería no se reporta. El sistema no muestra el estado de carga ni los ciclos.
• El WiFi se cae. Funciona, pero tras periodos largos de prueba se desconecta y no vuelve hasta reiniciar el equipo.
• El audio no funciona. Sin salida de sonido en la imagen recién instalada.
• El equipo se identifica como de 8 núcleos. Este es el más importante y el más sutil. El X1E-78100 es de 12 núcleos, pero desde Ubuntu 26.04 el kernel lo reporta como un procesador de 8 núcleos. Es una regresión presente desde hace meses, así que está presente en las dos imágenes comparadas.

Ese último punto tiene una implicancia práctica que el artículo menciona de paso y que conviene pesar: como la máquina ya se identifica como de 8 núcleos desde 26.04, las cifras de CPU de esta comparación no son comparables con las del hardware real. Estás midiendo 8 de los 12 núcleos. Por eso el conteo de 44 victorias individuales tiene que leerse con esa restricción encima.

Diagnóstico: cómo confirmar cada regresión en tu propio equipo

Antes de reportar nada a Launchpad, conviene confirmar el estado en tu máquina con comandos concretos. Estos son los que te van a dar la respuesta real, y funcionan igual en la ISO de concepto que en una instalación normal.

uname -a
lscpu | head -20
nproc
lsb_release -a

Con esto confirmas tres cosas de un vistazo: el kernel que corre realmente, la cantidad de núcleos que el sistema ve, y qué versión de la distribución tienes instalada. Si nproc te devuelve 8 en un equipo de 12 núcleos, tienes la regresión de detección de núcleos, y ningún ajuste de rendimiento la va a arreglar: es un problema del kernel, no de la configuración.

lsmod | grep -i msm
lspci -nnk | grep -A 3 -iE 'vga|3d|display'
sudo dmesg | grep -iE 'msm|adreno|gpu' | tail -30

El primer comando te dice si el módulo DRM MSM está cargado. El segundo te muestra qué driver está realmente en uso en el controlador gráfico. Si ves “Kernel driver in use” vacío o con un módulo de reserva, la GPU no se está usando. El tercero es el que da la evidencia dura: los mensajes del kernel sobre el intento de encendido de la GPU. Cuando el driver se queja de no poder encenderla, ese registro es el que necesitas adjuntar al reporte.

sudo apt install -y mesa-utils
glxinfo | grep -i 'OpenGL renderer'

Este es el test definitivo para la caída a software. Si la línea dice llvmpipe estás en render por software, con el impacto de rendimiento que implica para cualquier cosa que use la GPU. Si esperabas aceleración y te sale llvmpipe, ya tienes confirmado el error de la GPU.

Para la batería, UPower es la herramienta estándar, y el resultado es el que va a decirte la verdad:

upower -e | grep -i battery
upower -i /org/freedesktop/UPower/devices/battery_BAT0

Si el primer comando no devuelve nada, el sistema no está exponiendo ningún dispositivo de batería y el segundo va a responder que no encuentra el dispositivo. Eso no es un problema de permisos ni de UPower: es exactamente el síntoma del que habla la review.

Para el WiFi y el audio, el estado se ve en vivo en NetworkManager y en el servidor de sonido:

nmcli device status
nmcli -f IN-USE,SSID,SIGNAL device wifi
sudo journalctl -k -b | grep -iE 'wlan|wifi|firmware' | tail -40
aplay -l
pactl info | grep -iE 'Server Name|Server Version'

En el caso del WiFi el registro del kernel es el que documenta la desconexión: si la interfaz aparece en NetworkManager pero el registro muestra desconexiones repetidas del firmware, estás viendo el mismo patrón que la review. Con el audio, aplay -l te dice si el sistema siquiera detecta una tarjeta de sonido: si la lista sale vacía, el problema es de detección de hardware y no de configuración del servidor de sonido.

El paso que casi nadie se salta: extraer el firmware de Qualcomm

Este es el punto que define la experiencia completa con ARM en estos portátiles. Canonical no puede distribuir los bloques de firmware que necesitan ciertos drivers porque todavía no están bajo una licencia que le sirva para incluirlos en Ubuntu. La solución oficial es extraerlos de la partición de Windows 11 del propio portátil, y la herramienta se llama qcom-firmware-extract.

sudo apt update
sudo apt install -y qcom-firmware-extract
sudo qcom-firmware-extract
sudo reboot

La consecuencia práctica es incómoda pero no negociable: tienes que mantener la partición de Windows 11 en el disco. No es un residuo que puedas formatear después. Hay algunos portátiles Snapdragon de Dell y Lenovo que sí traen parte de sus bloques de firmware dentro de linux-firmware.git, lo que facilita el mantenimiento, pero el Acer de esta prueba no está en ese grupo. Si borras Windows esperando liberar espacio, te quedas sin GPU y con soporte de hardware incompleto.

Snapdragon X2: la parte que sí viene en camino

Conviene separar el hardware que ya funciona del que está por llegar. La semana anterior a esta review, Phoronix publicó benchmarks de Snapdragon X2 usando un ASUS Zenbook A16 con X2 Elite Extreme. Eso se hizo de forma remota con ayuda de un lector, y la buena noticia es que Qualcomm ya envió una unidad de review para que las pruebas siguientes se hagan sobre el equipo. La ISO de concepto 26.10 para Snapdragon es además la primera con soporte para X2 en el ASUS Zenbook A14 y A16, el Lenovo Yoga Slim 7 y el HP EliteBook X G2q, y suma máquinas X1 nuevas como el Lenovo IdeaPad Slim 3, el Lenovo Ideacentre Mini 01q8x10 y el HONOR MagicBook Art 14.

La hoja de ruta oficial ya está publicada. Qualcomm anunció una vista previa para desarrolladores de Linux en la serie Snapdragon X2, con el NPU Hexagon mediante fastRPC y el soporte de GPU con los drivers libres Freedreno, Turnip y Rusticl, usando systemd-boot como gestor de arranque UEFI. El trabajo se validó sobre un espacio de usuario de Debian 13 con un kernel propio, así que sigue siendo un entorno poco madurado. Canonical y Qualcomm han anunciado por separado una imagen oficial, certificada y optimizada para X2 apuntando a 2027, con hasta 18 núcleos Oryon a 5.0 GHz, NPU de hasta 80 TOPS, memoria LPDDR5x de hasta 228 GB/s, Wi-Fi 7 y 5G opcional, y hasta 15 años de mantenimiento de seguridad para las versiones LTS mediante Ubuntu Pro.

Eso significa que la comunidad ARM de Linux ya no es un experimento de nicho. Es la dirección en la que van los portátiles de desarrollo. Y cuando llegue la imagen certificada, buena parte del dolor de firmware que acabas de leer se habrá resuelto en el kernel o en el propio paquete de firmware.

Vale la pena o no: para quién tiene sentido esto

Si tu Snapdragon es el portátil de un desarrollador que compila en el tren, el valor de esta ISO no es que sea más rápida. Es que el entorno completo de herramientas funciona en el mismo equipo donde ya tenías todo. Eso ya es más de lo que ofrecen la mayoría de las distribuciones ARM en el escritorio.

Pero no la instales en tu máquina principal todavía. El número de regresiones abiertas en el mismo equipo de prueba es alto, y dos de ellas, la GPU en software y la identificación de 8 núcleos, tocan la base del rendimiento y no los detalles. Mi recomendación concreta: mantén el equipo en 26.04 LTS mientras tanto, usa la ISO de concepto en un disco externo si puedes, y reporta errores con los registros de los comandos de arriba. Cada reporte bien documentado es lo que acerca la imagen certificada de 2027.

Y si estás por comprar un Snapdragon hoy, mira primero la lista de equipos que traen parte de sus bloques de firmware en linux-firmware.git. Te va a ahorrar el paso de conservar la partición de Windows, que es el peaje real de esta plataforma hoy.

Preguntas frecuentes

Lee también

• Soporte de Trip Points en Linux para Snapdragon X Series de Qualcomm
• Linux 7.3 RC5: 7 cambios clave que verás en Ubuntu 26.10
• Linux 7.2 vs 7.3 en AMD Ryzen AI Max+ 395: qué mejora y qué no
• Stonking Stingray: el codename de Ubuntu 26.10 y por qué debería importarte
• GNOME 51 «A Coruña»: frame scheduling y fin del driver NVIDIA legacy