1P by GN⁺ | ★ favorite | 댓글 1개
  • 이 저장소는 NVIDIA Linux 오픈 GPU 커널 모듈 소스 릴리스이며, README 기준 버전은 565.57.01
  • 빌드한 커널 모듈은 같은 565.57.01 드라이버 릴리스의 GSP 펌웨어와 사용자 공간 NVIDIA GPU 드라이버 구성요소와 함께 사용해야 함
  • 지원 대상은 x86_64aarch64이며, Linux 커널은 독점 NVIDIA 커널 모듈과 같은 범위를 지원하고 현재 기준 4.15 이상
  • 커널 모듈은 운영체제 독립 구성요소와 Linux 커널 인터페이스 계층으로 나뉘며, 대상 커널에 맞춰 커널 인터페이스 계층을 빌드해야 함
  • 호환 GPU는 Turing 이후 GPU이며, 표에는 NVIDIA GeForce RTX 4090을 포함한 여러 GeForce, RTX, A/H/L 시리즈 제품과 PCI ID가 나열됨

릴리스와 빌드 조건

  • 이 저장소는 NVIDIA Linux open GPU kernel modules의 소스 릴리스이며 버전은 565.57.01
  • 기본 빌드 명령은 다음과 같음
    • make modules -j$(nproc)
  • 설치 전에는 기존 NVIDIA 커널 모듈을 제거해야 하며, root 권한으로 다음을 실행함
    • make modules_install -j$(nproc)
  • 여기서 빌드한 커널 모듈은 대응되는 565.57.01 드라이버 릴리스의 GSP 펌웨어와 사용자 공간 NVIDIA GPU 드라이버 구성요소가 필요함
    • NVIDIA GPU 드라이버 .run 파일을 --no-kernel-modules 옵션으로 설치하는 방식이 예시로 제시됨

지원 아키텍처와 도구체인

  • 커널 모듈은 현재 x86_64 또는 aarch64용으로 빌드할 수 있음
  • 교차 컴파일 시 TARGET_ARCH=aarch64|x86_64와 함께 CC, LD, AR, CXX, OBJCOPY를 make 명령줄에서 지정함
  • GCC 또는 Clang의 비교적 최신 버전으로 빌드할 수 있음
  • 커널 모듈의 커널 인터페이스 계층은 대상 커널을 빌드할 때 사용한 도구체인으로 빌드해야 함
  • 지원 Linux 커널 버전은 독점 NVIDIA 커널 모듈이 지원하는 범위와 같으며, 현재 Linux kernel 4.15 이상

빌드 옵션

  • NV_VERBOSE=1은 실행되는 전체 명령을 출력함
    • 기본값에서는 간단한 CC 줄만 출력됨
  • DEBUG=1은 커널 모듈을 디버그 빌드로 컴파일함
    • 기본 빌드는 디버깅 정보 없이 컴파일됨
    • 이 옵션은 커널 모듈의 여러 디버그 로그 메시지도 활성화함

커널 모듈 구조

  • NVIDIA 커널 모듈 대부분은 두 구성요소로 나뉨
    • OS-agnostic 구성요소: 운영체제와 독립적인 부분
    • kernel interface layer: Linux 커널 버전과 설정에 특화된 부분
  • NVIDIA .run 설치 패키지에서는 OS-agnostic 구성요소가 바이너리로 제공됨
    • 이 구성요소는 크고 컴파일 시간이 오래 걸려, 매 드라이버 설치 때 사용자가 다시 컴파일하지 않도록 사전 빌드 버전이 제공됨
    • nvidia.ko의 해당 구성요소 이름은 nv-kernel.o_binary
    • nvidia-modeset.ko의 해당 구성요소 이름은 nv-modeset-kernel.o_binary
    • nvidia-drm.konvidia-uvm.ko에는 OS-agnostic 구성요소가 없음
  • 각 커널 모듈의 커널 인터페이스 계층은 대상 커널에 맞춰 빌드해야 함

디렉터리 구성과 Nouveau 연동

  • 주요 디렉터리 역할은 다음과 같음
    • kernel-open/: 커널 인터페이스 계층
    • kernel-open/nvidia/: nvidia.ko용 커널 인터페이스 계층
    • kernel-open/nvidia-drm/: nvidia-drm.ko용 커널 인터페이스 계층
    • kernel-open/nvidia-modeset/: nvidia-modeset.ko용 커널 인터페이스 계층
    • kernel-open/nvidia-uvm/: nvidia-uvm.ko용 커널 인터페이스 계층
    • src/: OS-agnostic 코드
    • src/nvidia/: nvidia.ko용 OS-agnostic 코드
    • src/nvidia-modeset/: nvidia-modeset.ko용 OS-agnostic 코드
    • src/common/: nvidia.konvidia-modeset.ko 중 하나 이상에서 쓰는 유틸리티 코드
    • nouveau/: Nouveau 장치 드라이버 연동 도구
  • nouveau 디렉터리의 Python 스크립트는 소스 코드에 인코딩된 일부 펌웨어 바이너리 이미지와 관련 데이터를 추출해 별도 파일로 저장함
  • 이 파일들은 Nouveau 장치 드라이버가 GSP 펌웨어를 로드하고 통신하는 데 사용됨
  • 바이너리 파일 레이아웃은 nouveau_firmware_layout.ods에 설명되어 있으며, 이 파일은 OpenDocument Spreadsheet 형식임

기여와 이슈 처리

  • 기여는 NVIDIA의 open-gpu-kernel-modules 저장소에 pull request를 만드는 방식으로 진행함
  • pull request 제출 시 Contributor License Agreement 수락이 요구됨
  • 이 코드베이스는 NVIDIA 독점 드라이버와 공유되며, 공개 소스는 공유 코드에 여러 처리를 거쳐 생성됨
    • GitHub 저장소는 주로 각 드라이버 릴리스의 스냅샷처럼 동작함
    • NVIDIA 공유 코드베이스에서 이뤄진 개별 변경의 revision history 제공은 기대하기 어려움
    • 드라이버 릴리스마다 git commit이 하나만 있을 가능성이 큼
    • 개별 기여가 GitHub 저장소에서 별도 git commit으로 반영되지 못할 수 있음
    • 공개 전 처리 과정 때문에 기여를 공유 코드베이스에 적용하려면 수동 병합이 필요함
    • 큰 리팩터링은 병합과 수용이 어려울 수 있어 사전 연락과 조율이 필요함
  • Open GPU Kernel Modules 관련 문제는 NVIDIA 저장소의 Issues, NVIDIA 개발자 포럼, linux-bugs@nvidia.com으로 전달할 수 있음
  • 보안 취약점을 발견한 경우 별도 SECURITY.md 문서를 확인해야 함

호환 GPU 범위

  • NVIDIA 오픈 커널 모듈은 Turing 이후 GPU에서 사용할 수 있음
  • 기능 지원과 제한 사항의 세부 내용은 NVIDIA GPU driver end user README의 kernel_open.html 문서를 참조하도록 되어 있음
  • vGPU 지원은 vGPU Host Package에 포함된 README.vgpu를 참조해야 함
  • 호환 GPU 표는 제품명과 PCI ID를 함께 나열함
    • 세 개의 ID가 있는 경우 첫 번째는 PCI Device ID, 두 번째는 PCI Subsystem Vendor ID, 세 번째는 PCI Subsystem Device ID
    • 표에는 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, NVIDIA L40S 등 여러 제품이 포함됨

댓글과 토론

Hacker News 의견들
  • 대단함. 이게 가능한지 궁금했는데, 이제 로컬 LLM용 4x4090 장비를 막는 건 만들 시간뿐임
    텐서 병렬화가 되면 추론에서는 H100 SXM보다 훨씬 싸고 빠를 것 같음. 다만 tinybox가 왜 GPU 6개 구성을 택했는지는 아직 이해가 안 됨. 많은 작업은 4개나 8개에서만 잘 돌아가는데, 지금은 6개 값을 내고 4개만 쓰거나 8개가 아닌 애매한 구성이 된 듯함

    • tinygrad는 불균등 분할을 지원함. 4개나 8개여야 할 근본적인 이유는 없고, 소프트웨어가 좋으면 어떤 GPU 개수에서도 작업은 거의 완전히 병렬화될 수 있음
      6개를 고른 이유는 PCIe 레인이 128개, 즉 x16 포트 8개가 있기 때문임. NVMe에 1개, 네트워크에 1개를 쓰면 GPU 6개를 풀 패브릭으로 연결할 수 있음. 4개만 쓰면 PCIe를 낭비하고, 8개를 쓰면 USB3 몇 개 말고는 외부 연결 여지가 없어짐
    • GPU 6개인 이유는 빠른 저장장치가 필요하고 그게 PCIe 레인을 쓰기 때문임
      목표도 70B FP16 모델 실행이었고, 대략 VRAM 140GB가 필요함. 6*24GB = 144GB라서 맞아떨어짐
    • 6개는 합리적으로 보임. ThreadRipper의 128레인 중 일부는 네트워크와 NVMe에 써야 함
      예를 들어 NVMe 4개면 x16 레인, 10G 네트워크면 또 x4 레인이 필요함
    • 얼마 전 공개된 NVIDIA SXM2 자료를 찾아봤는데, SXM2/NVLink 2.0도 6-way 시스템처럼 보였음
      NVIDIA SXM은 이후 3, 4 버전으로 갱신됐고 이 구성은 그 기반도 아니지만, 6-way가 합리적인 이유가 뭔가 더 있을지도 모름
    • 생각 중인 빌드 세부사항을 공유해줄 수 있으면 좋겠음. 연구실 서버가 필요한데 선택지가 너무 많아서 감이 잘 안 잡힘
  • 정말 좋은 소식임. 학계에 있다 보니, 4090 여러 장으로 장비를 만들었다가 Nvidia가 카드 간 P2P 통신을 막아둔 걸 몰랐던 연구실을 여럿 알고 있음
    내 작업에는 훨씬 저렴했지만 4090을 사지 않은 이유 중 하나도 그거였음. 이건 NVLink는 아니지만, Nvidia가 최상위 카드 말고는 NVLink를 거의 없애버렸으니 없는 것보단 나음. 작년 말 NVLink H100 4장짜리 견적을 받았는데 납기가 13개월이었고, 비NVLink 제품은 4개월이면 받을 수 있었음. 지금은 연구실을 버티게 하려고 L40S 4장을 샀지만, 공급망 문제와 엄청난 가격 인상 때문에 연구가 매우 어려워짐. 박사과정 6명과 학부생 여럿을 지원하기엔 턱없이 부족함
    2015~2018년 예전 대학에서는 GPU 2장에 NVLink가 달린 장비를 대당 5천 달러에 만들어 학생마다 책상 밑에 하나씩 넣어줄 수 있었는데, 그때가 훨씬 쉬웠음

    • 그 전에도 Nvidia는 서버에 넣을 수 있던 소비자용 카드의 블로어형 설계를 단계적으로 없애면서 우리 삶을 더 어렵게 만들었음
      연구실 입장에선 MTBF가 절반이더라도 가격이 1/4인 카드를 언제든 고를 것 같음
    • GPU 클라우드 업체들과 비교하면 비용이 어떻게 됨?
  • 여기서 P2P가 무슨 뜻임? 검색해보니 peer to peer 같긴 한데, 그래픽 카드 맥락에서는 그게 뭘 의미함?

  • 더 많은 하드웨어 회사가 문서를 공개하고 나머지는 커뮤니티가 알아내게 해줬으면 좋겠음
    초기 IBM VGA에서 벌어진 일과 비슷함. "Mode X"나 BIOS가 아닌 하드웨어의 실제 모드들, 심지어 800x600x16도 찾아보면 됨. 안타깝게도 대부분은 제품 사용의 모든 측면을 꽉 통제해서 사용자층에서 돈을 더 뽑아내려는 쪽을 선호하는 것 같음. 개인적으로 PC가 가장 생산적이던 시기는 가장 개방적이던 시기이기도 했다고 봄

    • 그러면 같은 하드웨어를 두고 고객마다 다른 가격을 받을 수 없게 됨. 모두에게 이득인 건 아님
    • 내가 하드웨어 제조사이고 제품 기능의 소프트웨어 잠금이 안 통한다면, 대신 하드웨어 잠금으로 바꿀 것임
      그러면 제품 가격은 그냥 더 비싸질 것임
    • 개방성은 분명 훌륭했지만 사실 필수는 아니었음. 사람들은 폐쇄 시스템도 다루는 법을 알아낼 수 있음
      적대적 상호운용성(adversarial interoperability)은 흔했고, 제조사가 원하든 말든 역공학으로 소프트웨어를 돌아가게 만들었음. 예전엔 드물었지만 지금은 흔해진 게 소프트웨어·하드웨어 잠금임. 암호학은 우리에게 힘을 주는 기술이어야 했는데, 결국 우리 자신의 기계에서 우리를 배제하는 데 쓰이게 됨. 이제 우리는 운전석에 있지 않음. 운영체제조차 더 이상 시스템을 운영하지 못함. 자유로운 Linux 시스템도 제조사가 알 수 없는 독점 펌웨어와 실리콘을 섞어 만든 덩어리 안에서는 그냥 "사용자 OS"일 뿐이고, 진짜 동작에서 샌드박스 처리되는 작은 부품에 가까움
    • Nvidia의 소프트웨어가 그들의 해자
  • Nvidia가 소비자용 라인업에서 NVLink를 제거하면서 내세운 원래 명분은 PCIe 5면 충분히 빠를 것이라는 거였음
    그런데 40xx 시리즈는 PCIe 5도, P2P 지원도 없이 출시했음. 이제 그 절반이라도 채워지는 건 좋지만, 다음 세대 펌웨어에서도 이걸 허용할 거라고는 상상하기 어려움

  • 이건 소비자용 카드에서 시장 분리를 위해 비활성화된 기능 중 하나임?

    • 어느 정도는 맞음
      완벽하진 않은 비유로, 집 15채쯤 되는 작은 동네가 공사 중이라고 해보자. 보통은 모퉁이에 200kVA 변압기를 두고 전력망에서 적정 전력을 공급함. 그런데 변압기 부족으로 시공사가 상업용 1250kVA 변압기를 설치함. 필요한 것보다 훨씬 많은 집에 전력을 댈 수 있어서 용량을 한참 남기고 동작함. 어느 날 한 주민이 대규모 재배장을 시작하고 싶어져서 자기 집에만 그 여분 변압기 용량을 활성화하는 방법을 찾아냄. geohot이 찾은 게 바로 그 "활성화"에 해당함
    • 반대표가 많이 나올 것 같지만, 소비자 기기에서 이런 관행은 금지하거나 아주 무겁게 과세했으면 함
    • 소비자용 GPU에 이 기능을 구현하고 테스트할 유인이 전혀 없음. 게임용 멀티 GPU 구성은 제대로 잘 돌아간 적이 거의 없었음
  • 예전부터 George Hotz의 해킹 능력에 늘 감탄했음. 개인 프로젝트에도 큰 영감을 줬음

    • 그의 개발 과정을 보면 정말 흥미로움. 그렇게 공유해주는 관대함도 짚고 넘어갈 만함
      더 지식이 많은 엔지니어라면 덜 어렵게 느낄 얕고 임의적인 문제에 자주 막힘. 정말 나쁜 코드나 심지어 틀린 코드를 쓰는 모습도 자주 보임. Twitter 관련 장면이 좋은 예임. 그런데도 혼자서 끈질기게 반복하면서 그만큼 자주 놀라운 개선을 만들어냄. 배울 만한 좋은 예임
    • 그의 스트림에서 큰 자극을 받음. 집중과 노력은 좋은 결과의 핵심이고, 명확한 비전과 전략까지 더하면 성공도 이룰 수 있음
      geohot과 tinygrad/comma 기여자 모두에게 축하를 보냄
    • 장거리 비행 중인 군 조종사 같은 집중력이 있음
    • 그의 Xbox360 노트북은 내 십대 시절 동기부여의 핵심이었음
  • README를 훑어보니, 궁금한 사람을 위해 말하면 이건 NVLink가 아니라 PCIe 위의 P2P

    • RTX 40은 PCB에 NVLink가 없지만, 같은 계열 일부 카드가 지원하니 실리콘에는 들어있을 것임. 아마 퓨즈로 꺼놨을 거라고 봄
    • 알기로 4090은 PCIe 5.0을 지원하지 않아서 PCIe 4.0 속도로 제한됨. 그래도 개선이긴 함
  • 앞으로의 아키텍처에서는 이걸 펌웨어에서 잠그기 시작할 테니, 지속되는 동안은 좋을 것임

    • 맞지만, 어차피 언젠가는 그렇게 될 일이었음
      그러니 아예 없는 것보다는 한 세대라도 쓸 수 있는 편이 낫다
  • George 본인이 한 건지, 아니면 tinycorp가 걸어둔 보상금을 노린 사람이 한 건지 궁금함
    그리고 PCI 하위 시스템을 잘 아는 사람에게 묻고 싶은데, 이건 NVIDIA가 적극적으로 막으려 했다기보다는 신경 쓰지 않았던 것처럼 보이지 않음?

    • PCI 장치는 항상 공유 주소 공간을 읽고 쓸 수 있었음. IOMMU의 제약은 받지만, 보통은 시스템 RAM으로의 DMA에 가장 자주 쓰였을 뿐 그걸로 제한되지는 않음
      그래서 장치를 건드려 전체 VRAM을 주소 공간에 넣도록 구성하는 건 합리적임. resizable BAR 지원이 있거나, 고정 크기 BAR가 충분히 크면 됨. 또 한 카드에 다른 카드의 VRAM으로 매핑된 주소를 읽고 쓰라고 지시하는 것도 합리적임. PCIe 스위칭 용량이 병목이 될지, 아니면 지점 간 링크와 VRAM이 병목이 될지 궁금함. 어느 쪽이든 시스템 RAM을 거치는 왕복을 줄이는 건 도움이 될 것임
    • 커밋이 geohot 명의라서 George 본인이 한 것으로 보임
    • tinygrad Discord에도 진행 상황을 기록해뒀음