El conocido sistema operativo libre, FreeBSD, quiere ejecutar IA y simulación avanzada con gráficas AMD y ha decidido importar la pila que faltaba. Según el status report del segundo trimestre de 2026 publicado en julio, un intern de la Foundation ya compila toolchain y runtime y deja el driver amdkfd a punto de su primera suma vectorial.
Si usas FreeBSD para servidores, laboratorios o infraestructura crítica, este movimiento cambia una ecuación histórica: hasta ahora, quien necesitaba computación paralela en GPU tenía que mirar a Linux.
¿Qué es ROCm y por qué FreeBSD lo necesita ahora?
ROCm es la plataforma abierta de AMD para computación en GPU, el rival directo de CUDA de NVIDIA. Esta plataforma incluye compilador, runtime, librerías matemáticas y capas como HIP, que permiten escribir código portable entre AMD y NVIDIA, sin reescribirlo todo.
En Linux, ROCm sostiene desde entrenamiento de modelos hasta simulación de fluidos y análisis de datos a gran escala. La versión 6.4, publicada el 11 de abril de 2025, trajo contenedores optimizados para vLLM y SGLang, mejoras en atención para LLMs y un driver modular, según las release notes de AMD. La rama ha seguido hasta la 6.4.3 de agosto de 2025 y la serie 7.2 de 2026.
El punto es; que FreeBSD no soportaba ROCm ni a nivel de toolchain ni de driver, como reconoce el propio status report Q2 2026. Las únicas vías para cómputo en GPU eran Vulkan y OpenCL , útiles para gráficos y parte del ML, pero con menos control fino que ROCm o CUDA para tareas de HPC. Eso sin contar que son pilas de software con carencias graves de momento, para estas tareas.
La diferencia es importante. Sin ROCm, FreeBSD quedaba fuera del circuito donde hoy se decide el rendimiento de IA y HPC. Con ROCm, podría competir donde más importa: inferencia local de LLMs, simulación científica y procesamiento de datos masivo sin salir del ecosistema BSD.
El trabajo que anuncia FreeBSD en 2026
El anuncio de FreeBSD Foundation es un trabajo técnico en curso documentado en el status report. El protagonista es Sourojeet Adhikari, estudiante de Física Matemática en la Universidad de Waterloo y becario de la Foundation en el verano de 2026. Su misión, tutelada por Ed Maste y parte del equipo de gráficos de FreeBSD, es portar todo el stack ROCm desde Linux a FreeBSD y hacerlo de forma nativa, no emulada.
A principios de verano, el proyecto ya mostraba avances concretos. Según el resumen de Phoronix del 16 de julio, el intern había logrado compilar los componentes open source y validar que rocminfo arranca sin errores, aunque aun sin detectar GPU por la ausencia de amdkfd.
El 30 de agosto, se confirmó que el port está a punto de completar su primer hito real: una suma vectorial simple sobre GPU, como recoge su reporte de cierre de internship. No es espectacular en sí mismo, pero es la prueba que válida toda la cadena HIP hasta el hardware.
5 herramientas de ciberseguridad en Linux que debes dominar
¿Cómo se está construyendo el port y qué falta?
Pero portar ROCm no es copiar un paquete y ya está. Esta tarea exige tocar tres capas a la vez y mantenerlas coherentes.
En primer lugar, se debe asegurar el port completo del compilador. AMD mantiene un fork de LLVM para ROCm y ese fork no compilaba en FreeBSD sin parches. Sourojeet mapeó CLOCK_MONOTONIC_FAST a CLOCK_MONOTONIC_RAW, corrigió el manejo de environ y ya ha llevado esos cambios upstream, lo que permite construir el toolchain ROCm en FreeBSD. De ser aceptados los cambios, FreeBSD podría tener soporte oficial de ROCm por parte de AMD, algo que facilitaría la actualización futura de este soporte.
La segunda es el runtime. El componente rocr-runtime, es el corazón que habla con el driver, requiere de libdrm y libnuma. FreeBSD tiene libdrm equivalente, pero no libnuma, porque gestiona NUMA a nivel de proceso y no por rangos de memoria virtual como Linux. Para sortear esto, el intern creó un shim propio y reescribió cerca de 1.542 líneas, con cambios en kfd_ioctl.h, CMakeLists.txt, amd_hsa_loader y un nuevo os_freebsd.cpp, como documenta en detalle en racha.ca.
La pesadilla del driver
La tercera es el driver. FreeBSD ya porta el driver de display amdgpu desde Linux DRM, donde actualmente se soporte el DRM 6.12.85, todo ello gracias a la capa LinuxKPI que traduce interfaces del kernel Linux a FreeBSD. Lo que falta es amdkfd, el driver de cómputo que expone /dev/kfd. Ahí el trabajo se hace en un fork drm-kmod-rocm, donde Sourojeet ha portado funciones como kthread_use_mm a la semántica de hilos de FreeBSD y ha resuelto panics debido a la diferencia de manejo entre el kernel Linux y el de FreeBSD.
Conviene matizar que el estado actual no es usable para usuarios finales. El runtime compila, el driver enlaza y carga, /dev/kfd aparece y la comunicación es parcial, pero la ejecución completa de kernels aún requiere pulir ioctl, gestión de memoria y soporte para Heterogeneous Memory Management (HMM), que será la siguiente fase.
Esto último es un trabajo que se puede mejorar, ya que FreeBSD Foundation tiene entre sus objetivos hacer de DRM una pieza base del kernel FreeBSD, con lo que el módulo drm-kmod desaparecería tal como está, y mucho del trabajo de Sourojeet, pasaría a formar parte del propio kernel FreeBSD, transformando la integración en un desarrollo de primer nivel. Esto, sin embargo, es un trabajo en progreso, y no hay fecha clara definitiva para tal objetivo.
FreeBSD quiere entrar al mundo de la IA y simulación
Por que hoy, quien quiere GPU compute en FreeBSD tiene dos atajos imperfectos: emular Linux o encapsular en Podman. NVIDIA sí distribuye driver propietario para FreeBSD, pero no soporta oficialmente CUDA en la plataforma, aunque hay una pequeña trampa para activarlo. Pero en el caso de AMD, no había siquiera atajo, ROCm simplemente no existía.
Con ROCm nativo, FreeBSD podría ofrecer un flujo completo sin salir del sistema. Eso significa compilar con amdclang, lanzar kernels HIP y usar librerías como rocBLAS o MIOpen directamente sobre la GPU, con la estabilidad y el modelo de licencias que caracterizan al proyecto.
Eso significa que un nodo FreeBSD con una Radeon 780M (RDNA3, GFX 11.0.1) o una Strix Halo APU del Framework Desktop usado en las pruebas podría, a medio plazo, ejecutar inferencia de LLMs con vLLM, fine-tuning con PyTorch o simulación CFD sin cruzar a Linux. No mañana, pero la base queda trazada y, una vez resuelta en FreeBSD, servirá de plantilla para otros BSD.
Aun así, habrá que esperar a ver el ritmo. AMD ha acelerado ROCm a un ciclo de seis semanas desde su evento Advancing AI del 23 de julio de 2026, lo que obliga a FreeBSD a mantener el port sincronizado. La ventaja es que cada sincronización de DRM, estrecha la brecha que debe salvar el runtime.
Las 5 distribuciones Linux perfectas para dar tus primeros pasos
Un movimiento que devuelve a FreeBSD a la conversación sobre GPU
El calendario para la llegada de ROCm en todo caso es prudente. El internship de verano de 2026 concluye con vector addition casi listo y con el driver cargando, pero con trabajo pendiente en memoria y estabilidad, como confirma la Foundation.
Los siguientes pasos, según el propio Sourojeet y la discusión abierta en ROCm/rocm-systems #6792, son limpiar los parches de rocr-runtime para upstream en piezas pequeñas, decidir si se encapsulan en os_freebsd.cpp o vía macros, y abordar HMM en el kernel de FreeBSD. También se han creado ports sysutils/rocr y sysutils/roct (ROCm 1.9.1) limitados a amd64, pensados como compañeros de amdkfd cuando este esté listo, aunque aún no funcionales.
En paralelo, la base DRM seguirá avanzando y FreeBSD 15.1 ya cuenta con drivers más modernos. Pero habrá que ver si el esfuerzo consigue tracción más allá de un intern. La Foundation ha dejado claro que el trabajo continuará y Sourojeet ha señalado que quiere seguir vinculado, pero el mantenimiento a ritmo de ROCm exigirá recursos continuos. Si se consolidan los upstream y se estabiliza amdkfd, 2027 podría traer las primeras pruebas de inferencia real en FreeBSD con AMD. Si no, el proyecto quedará como una prueba de viabilidad que demuestra que el camino existe, aunque falte asfaltarlo.