Driver hackeado de GPU Nvidia 4090 habilita P2P

 (github.com/tinygrad)
1 puntos por GN⁺ 2024-04-13 | 1 comentarios | Compartir por WhatsApp
  • Este repositorio es la publicación del código fuente de los módulos abiertos del kernel GPU de NVIDIA para Linux, y la versión según el README es 565.57.01
  • Los módulos del kernel compilados deben usarse junto con el firmware GSP y los componentes del driver NVIDIA GPU en espacio de usuario de la misma versión 565.57.01 del driver
  • Los objetivos compatibles son x86_64 y aarch64, y el kernel de Linux compatible cubre el mismo rango que el módulo propietario del kernel de NVIDIA, actualmente 4.15 o superior
  • Los módulos del kernel se dividen en componentes independientes del sistema operativo y una capa de interfaz del kernel de Linux, y esta capa debe compilarse para ajustarse al kernel de destino
  • Las GPU compatibles son las GPU Turing o posteriores, y la tabla enumera varios productos GeForce, RTX y series A/H/L, incluyendo la NVIDIA GeForce RTX 4090, junto con sus PCI ID

Lanzamiento y condiciones de compilación

  • Este repositorio es la publicación del código fuente de los NVIDIA Linux open GPU kernel modules y la versión es 565.57.01
  • El comando básico de compilación es el siguiente
    • make modules -j$(nproc)
  • Antes de la instalación se deben eliminar los módulos existentes del kernel de NVIDIA, y luego ejecutar lo siguiente con privilegios de root
    • make modules_install -j$(nproc)
  • Los módulos del kernel compilados aquí requieren el firmware GSP y los componentes del driver NVIDIA GPU en espacio de usuario de la versión correspondiente 565.57.01 del driver
    • Se presenta como ejemplo instalar el archivo .run del driver NVIDIA GPU con la opción --no-kernel-modules

Arquitecturas compatibles y toolchain

  • Actualmente los módulos del kernel pueden compilarse para x86_64 o aarch64
  • En compilación cruzada, se especifican TARGET_ARCH=aarch64|x86_64 junto con CC, LD, AR, CXX, OBJCOPY en la línea de comandos de make
  • Puede compilarse con versiones relativamente recientes de GCC o Clang
  • La capa de interfaz del kernel de los módulos debe compilarse con el mismo toolchain usado para compilar el kernel de destino
  • El rango de versiones de kernel Linux compatibles es el mismo que soporta el módulo propietario del kernel de NVIDIA, actualmente Linux kernel 4.15 o superior

Opciones de compilación

  • NV_VERBOSE=1 imprime todos los comandos ejecutados
    • En la configuración predeterminada solo se muestran líneas breves de CC
  • DEBUG=1 compila los módulos del kernel en modo debug
    • La compilación predeterminada se realiza sin información de depuración
    • Esta opción también activa varios mensajes de registro de depuración de los módulos del kernel

Estructura de los módulos del kernel

  • La mayoría de los módulos del kernel de NVIDIA se dividen en dos componentes
    • Componente OS-agnostic: parte independiente del sistema operativo
    • kernel interface layer: parte específica de la versión y configuración del kernel Linux
  • En el paquete de instalación .run de NVIDIA, el componente OS-agnostic se proporciona como binario
    • Como este componente es grande y tarda en compilar, se proporciona una versión precompilada para que el usuario no tenga que recompilarla en cada instalación del driver
    • El nombre de ese componente en nvidia.ko es nv-kernel.o_binary
    • El nombre de ese componente en nvidia-modeset.ko es nv-modeset-kernel.o_binary
    • nvidia-drm.ko y nvidia-uvm.ko no tienen componente OS-agnostic
  • La capa de interfaz del kernel de cada módulo debe compilarse para ajustarse al kernel de destino

Estructura de directorios e integración con Nouveau

  • Las funciones de los directorios principales son las siguientes
    • kernel-open/: capa de interfaz del kernel
    • kernel-open/nvidia/: capa de interfaz del kernel para nvidia.ko
    • kernel-open/nvidia-drm/: capa de interfaz del kernel para nvidia-drm.ko
    • kernel-open/nvidia-modeset/: capa de interfaz del kernel para nvidia-modeset.ko
    • kernel-open/nvidia-uvm/: capa de interfaz del kernel para nvidia-uvm.ko
    • src/: código OS-agnostic
    • src/nvidia/: código OS-agnostic para nvidia.ko
    • src/nvidia-modeset/: código OS-agnostic para nvidia-modeset.ko
    • src/common/: código utilitario usado por uno o más de nvidia.ko y nvidia-modeset.ko
    • nouveau/: herramientas de integración con el driver de dispositivo Nouveau
  • Los scripts de Python del directorio nouveau extraen algunas imágenes binarias de firmware codificadas en el código fuente y datos relacionados, y los guardan en archivos separados
  • Estos archivos se usan para que el driver de dispositivo Nouveau cargue y se comunique con el firmware GSP
  • El diseño de los archivos binarios se describe en nouveau_firmware_layout.ods, que está en formato OpenDocument Spreadsheet

Contribuciones y gestión de issues

  • Las contribuciones se realizan creando pull requests en el repositorio open-gpu-kernel-modules de NVIDIA
  • Al enviar un pull request se requiere aceptar el Contributor License Agreement
  • Esta base de código se comparte con el driver propietario de NVIDIA, y el código fuente público se genera aplicando varios procesos al código compartido
    • El repositorio de GitHub funciona principalmente como una instantánea de cada lanzamiento del driver
    • No es realista esperar un historial de revisiones de cambios individuales realizados en la base de código compartida de NVIDIA
    • Es muy probable que haya solo un commit de git por cada lanzamiento del driver
    • Es posible que las contribuciones individuales no se reflejen como commits separados en el repositorio de GitHub
    • Debido al proceso de preparación previo a la publicación, aplicar contribuciones a la base de código compartida requiere fusión manual
    • Los refactorings grandes pueden ser difíciles de fusionar y aceptar, por lo que se requiere contacto y coordinación previa
  • Los problemas relacionados con Open GPU Kernel Modules pueden reportarse en los Issues del repositorio de NVIDIA, en los foros para desarrolladores de NVIDIA o a linux-bugs@nvidia.com
  • Si se descubre una vulnerabilidad de seguridad, se debe consultar el documento separado SECURITY.md

Rango de GPU compatibles

  • Los módulos abiertos del kernel de NVIDIA pueden usarse en GPU Turing o posteriores
  • Para los detalles de soporte de funciones y limitaciones, se indica consultar el documento kernel_open.html del README para usuarios finales del driver NVIDIA GPU
  • El soporte de vGPU debe consultarse en README.vgpu, incluido en el paquete vGPU Host
  • La tabla de GPU compatibles enumera el nombre del producto junto con el PCI ID
    • Si hay tres ID, el primero es el PCI Device ID, el segundo el PCI Subsystem Vendor ID y el tercero el PCI Subsystem Device ID
    • La tabla incluye varios productos como NVIDIA GeForce RTX 4090, NVIDIA GeForce RTX 4090 D, NVIDIA GeForce RTX 4080 SUPER, NVIDIA GeForce RTX 4070 Ti SUPER, NVIDIA H100, NVIDIA H200, NVIDIA GH200 y NVIDIA L40S

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-13
Opiniones de Hacker News

  • Increíble. Me preguntaba si esto era posible; ahora lo único que impide armar un equipo 4x4090 para LLM locales es el tiempo que tome construirlo.
    Si se logra la paralelización de tensores, para inferencia parece que sería mucho más barato y rápido que una H100 SXM. Aunque todavía no entiendo por qué tinybox eligió una configuración de 6 GPU. Muchas cargas solo funcionan bien con 4 u 8, y ahora parece que pagas por 6 pero usas solo 4, o quedas con una configuración intermedia que no llega a 8.

    • tinygrad soporta particionado desigual. No hay una razón fundamental para que tengan que ser 4 u 8; con buen software, la carga se puede paralelizar casi por completo con cualquier cantidad de GPU.
      La razón por la que eligieron 6 es que hay 128 líneas PCIe, es decir, 8 puertos x16. Si usas 1 para NVMe y 1 para red, puedes conectar 6 GPU con un fabric completo. Si usas solo 4, desperdicias PCIe; si usas 8, prácticamente no queda margen para conexiones externas salvo algunos USB3.
    • La razón de que sean 6 GPU es que se necesita almacenamiento rápido, y eso usa líneas PCIe.
      El objetivo también era ejecutar un modelo 70B FP16, que requiere aproximadamente 140 GB de VRAM. 6*24 GB = 144 GB, así que encaja justo.
    • 6 parece razonable. Parte de las 128 líneas de ThreadRipper tiene que usarse para red y NVMe.
      Por ejemplo, 4 NVMe requieren x16 líneas, y una red 10G necesita otras x4 líneas.
    • Estuve revisando documentación de NVIDIA SXM2 publicada hace poco, y SXM2/NVLink 2.0 también parecía un sistema de 6 vías.
      NVIDIA SXM luego se actualizó a las versiones 3 y 4, y esta configuración ni siquiera se basa en eso, pero quizá haya alguna otra razón por la que 6 vías tenga sentido.
    • Sería bueno si pudieras compartir los detalles de la build que estás considerando. Necesitamos un servidor para el laboratorio, pero hay tantas opciones que cuesta orientarse.

  • Es una excelente noticia. Como estoy en la academia, conozco varios laboratorios que armaron equipos con varias 4090 sin saber que Nvidia había bloqueado la comunicación P2P entre tarjetas.
    Esa fue una de las razones por las que no compré 4090, aunque para mi trabajo eran mucho más baratas. Esto no es NVLink, pero como Nvidia prácticamente eliminó NVLink salvo en sus tarjetas de gama más alta, es mejor que nada. A fines del año pasado pedí una cotización para 4 H100 con NVLink y el plazo de entrega era de 13 meses; los productos sin NVLink podían llegar en 4 meses. Ahora compré 4 L40S para mantener a flote el laboratorio, pero los problemas de la cadena de suministro y los enormes aumentos de precio están dificultando muchísimo la investigación. Es claramente insuficiente para apoyar a 6 doctorandos y varios estudiantes de pregrado.
    En mi universidad anterior, entre 2015 y 2018, podíamos armar equipos con 2 GPU y NVLink por 5 mil dólares cada uno, y ponerle uno debajo del escritorio a cada estudiante; en esa época todo era mucho más fácil.

    • Incluso antes de eso, Nvidia ya nos había complicado la vida al eliminar gradualmente los diseños tipo blower de las tarjetas de consumo que podían ponerse en servidores.
      Desde la perspectiva de un laboratorio, creo que siempre elegiríamos una tarjeta que cueste 1/4 aunque tenga la mitad del MTBF.
    • ¿Cómo quedan los costos en comparación con proveedores de GPU en la nube?

  • ¿Qué significa P2P aquí? Buscando parece ser peer to peer, pero ¿qué significa eso en el contexto de tarjetas gráficas?

    • Significa que al enviar datos desde la memoria de una GPU a otra GPU no hace falta pasar por la RAM del sistema. https://xilinx.github.io/XRT/master/html/p2p.html
    • Se refiere al acceso a memoria compartida entre GPU Nvidia.
      https://developer.nvidia.com/gpudirect
    • El término preciso, y como probablemente se le habría llamado antes en la mayoría de los casos, es bus mastering.
    • Es un término tonto. Es como llamar peer to peer a un enlace RS-232.

  • Ojalá más empresas de hardware publicaran documentación y dejaran que la comunidad descubriera el resto.
    Es parecido a lo que pasó con las primeras IBM VGA. Basta con buscar "Mode X" o los modos reales del hardware que no eran del BIOS, incluso 800x600x16. Lamentablemente, parece que la mayoría prefiere controlar estrictamente todos los aspectos del uso de sus productos para exprimir más dinero de su base de usuarios. Personalmente, creo que la época en que la PC fue más productiva también fue la época en que fue más abierta.

    • Entonces no podrían cobrar precios distintos a distintos clientes por el mismo hardware. No es algo que beneficie a todos.
    • Si yo fuera fabricante de hardware y el bloqueo por software de funciones del producto no funcionara, lo cambiaría por bloqueo por hardware.
      Entonces el precio del producto simplemente sería más alto.
    • La apertura fue sin duda excelente, pero en realidad no era indispensable. La gente puede aprender a manejar sistemas cerrados.
      La interoperabilidad adversarial era común, y mediante ingeniería inversa se hacía funcionar el software, quisiera o no el fabricante. Lo que antes era raro y ahora se volvió común es el bloqueo de software y hardware. La criptografía debería haber sido una tecnología que nos diera poder, pero terminó usándose para excluirnos de nuestras propias máquinas. Ya no estamos al volante. Ni siquiera el sistema operativo opera realmente el sistema. Incluso un sistema Linux libre, dentro de una masa hecha de firmware propietario y silicio desconocido para el fabricante, es apenas un "SO de usuario", más parecido a una pequeña pieza aislada en un sandbox respecto del funcionamiento real.
    • El software de Nvidia es su foso defensivo.

  • La justificación original de Nvidia al quitar NVLink de su línea de consumo fue que PCIe 5 sería lo suficientemente rápido.
    Pero la serie 40xx salió sin PCIe 5 ni soporte P2P. Me alegra que al menos ahora se cumpla la mitad de eso, pero me cuesta imaginar que permitan esto también en el firmware de la próxima generación.

  • ¿Esta es una de esas funciones desactivadas en tarjetas de consumo por segmentación de mercado?

    • En cierta medida, sí
      Como analogía imperfecta, imaginemos que se está construyendo un barrio pequeño de unas 15 casas. Normalmente se pondría un transformador de 200 kVA en la esquina y se suministraría la energía adecuada desde la red. Pero por falta de transformadores, la constructora instala uno comercial de 1250 kVA. Puede alimentar muchas más casas de las necesarias, así que funciona con muchísima capacidad de sobra. Un día, un vecino quiere montar una gran operación de cultivo y descubre cómo activar solo para su casa esa capacidad sobrante del transformador. Lo que encontró geohot equivale justamente a esa “activación”
    • Seguro me van a llover votos en contra, pero me gustaría que estas prácticas en dispositivos de consumo se prohibieran o se gravaran con impuestos muy altos
    • No hay ningún incentivo para implementar y probar esta función en GPU de consumo. Las configuraciones multi-GPU para juegos casi nunca funcionaron realmente bien

  • Desde hace tiempo siempre me ha impresionado la capacidad de hackeo de George Hotz. También fue una gran inspiración para mis proyectos personales

    • Ver su proceso de desarrollo es realmente fascinante. También vale la pena destacar lo generoso que es al compartirlo
      A menudo se queda trabado en problemas superficiales y arbitrarios que a un ingeniero con más conocimientos le parecerían menos difíciles. También se lo ve con frecuencia escribiendo código muy malo o incluso incorrecto. Las escenas relacionadas con Twitter son un buen ejemplo. Aun así, insistiendo solo una y otra vez, logra mejoras sorprendentes con la misma frecuencia. Es un buen ejemplo del que aprender
    • Sus streams me motivaron mucho. La concentración y el esfuerzo son clave para obtener buenos resultados, y si se suman una visión y una estrategia claras, también se puede alcanzar el éxito
      Felicitaciones tanto a geohot como a los colaboradores de tinygrad/comma
    • Tiene una concentración como la de un piloto militar en un vuelo de larga distancia
    • Su laptop Xbox360 fue una pieza clave de motivación en mi adolescencia

  • Mirando por encima el README, para quien tenga curiosidad: esto es P2P sobre PCIe, no NVLink

    • La RTX 40 no tiene NVLink en el PCB, pero como algunas tarjetas de la misma familia lo soportan, probablemente esté incluido en el silicio. Supongo que lo habrán desactivado con fusibles
    • Según entiendo, la 4090 no soporta PCIe 5.0, así que queda limitada a velocidades de PCIe 4.0. Aun así, es una mejora

  • En arquitecturas futuras empezarán a bloquear esto desde el firmware, así que será bueno mientras dure

    • Es cierto, pero de todos modos era algo que tarde o temprano iba a pasar
      Así que es mejor poder usarlo al menos durante una generación que no tenerlo en absoluto

  • Me pregunto si lo hizo el propio George o si fue alguien buscando la recompensa que tinycorp había ofrecido
    Y quisiera preguntarle a alguien que conozca bien el subsistema PCI: ¿no parece que esto fuera más algo a lo que NVIDIA no le prestó atención, en vez de algo que intentó bloquear activamente?

    • Los dispositivos PCI siempre han podido leer y escribir en un espacio de direcciones compartido. Están sujetos a las restricciones del IOMMU, pero normalmente se han usado más que nada para DMA hacia la RAM del sistema, aunque no están limitados a eso
      Por eso tiene sentido manipular el dispositivo para configurarlo de modo que toda la VRAM quede dentro del espacio de direcciones. Basta con que haya soporte para resizable BAR o que el BAR de tamaño fijo sea lo suficientemente grande. También tiene sentido indicarle a una tarjeta que lea y escriba direcciones mapeadas a la VRAM de otra tarjeta. Me pregunto si el cuello de botella será la capacidad de conmutación de PCIe o los enlaces punto a punto y la VRAM. En cualquier caso, reducir el viaje de ida y vuelta pasando por la RAM del sistema debería ayudar
    • Como el commit está a nombre de geohot, parece que lo hizo el propio George
    • También dejó registrado el progreso en el Discord de tinygrad