1 poin oleh GN⁺ 2024-04-13 | 1 komentar | Bagikan ke WhatsApp
  • Repositori ini adalah rilis sumber NVIDIA Linux open GPU kernel modules, dan versinya menurut README adalah 565.57.01
  • Modul kernel yang dibangun harus digunakan bersama firmware GSP dan komponen driver GPU NVIDIA ruang pengguna dari rilis driver 565.57.01 yang sama
  • Yang didukung adalah x86_64 dan aarch64, dan kernel Linux yang didukung mencakup rentang yang sama dengan modul kernel NVIDIA proprietari, yaitu saat ini 4.15 atau lebih baru
  • Modul kernel dibagi menjadi komponen yang independen dari sistem operasi dan lapisan antarmuka kernel Linux, dan lapisan antarmuka kernel harus dibangun sesuai dengan kernel target
  • GPU yang kompatibel adalah GPU Turing dan yang lebih baru, dan tabelnya mencantumkan berbagai produk GeForce, RTX, serta seri A/H/L termasuk NVIDIA GeForce RTX 4090 beserta PCI ID-nya

Rilis dan syarat build

  • Repositori ini adalah rilis sumber NVIDIA Linux open GPU kernel modules dan versinya adalah 565.57.01
  • Perintah build dasarnya adalah sebagai berikut
    • make modules -j$(nproc)
  • Sebelum instalasi, modul kernel NVIDIA yang ada harus dihapus, lalu jalankan berikut ini dengan hak root
    • make modules_install -j$(nproc)
  • Modul kernel yang dibangun di sini memerlukan firmware GSP dan komponen driver GPU NVIDIA ruang pengguna dari rilis driver 565.57.01 yang sesuai
    • Sebagai contoh ditunjukkan cara memasang file .run driver GPU NVIDIA dengan opsi --no-kernel-modules

Arsitektur dan toolchain yang didukung

  • Modul kernel saat ini dapat dibangun untuk x86_64 atau aarch64
  • Saat cross-compiling, tentukan TARGET_ARCH=aarch64|x86_64 bersama CC, LD, AR, CXX, OBJCOPY pada baris perintah make
  • Build dapat dilakukan dengan versi GCC atau Clang yang relatif baru
  • Lapisan antarmuka kernel dari modul kernel harus dibangun dengan toolchain yang digunakan saat membangun kernel target
  • Versi kernel Linux yang didukung sama dengan rentang yang didukung modul kernel NVIDIA proprietari, yaitu saat ini Linux kernel 4.15 atau lebih baru

Opsi build

  • NV_VERBOSE=1 mencetak seluruh perintah yang dijalankan
    • Pada nilai bawaan, hanya baris CC singkat yang dicetak
  • DEBUG=1 mengompilasi modul kernel sebagai build debug
    • Build default dikompilasi tanpa informasi debugging
    • Opsi ini juga mengaktifkan berbagai pesan log debug dari modul kernel

Struktur modul kernel

  • Sebagian besar modul kernel NVIDIA dibagi menjadi dua komponen
    • Komponen OS-agnostic: bagian yang independen dari sistem operasi
    • kernel interface layer: bagian yang spesifik terhadap versi dan konfigurasi kernel Linux
  • Dalam paket instalasi NVIDIA .run, komponen OS-agnostic disediakan dalam bentuk biner
    • Komponen ini besar dan waktu kompilasinya lama, sehingga disediakan versi pra-build agar pengguna tidak perlu mengompilasinya ulang setiap kali memasang driver
    • Nama komponen terkait dalam nvidia.ko adalah nv-kernel.o_binary
    • Nama komponen terkait dalam nvidia-modeset.ko adalah nv-modeset-kernel.o_binary
    • nvidia-drm.ko dan nvidia-uvm.ko tidak memiliki komponen OS-agnostic
  • Lapisan antarmuka kernel dari tiap modul kernel harus dibangun sesuai dengan kernel target

Struktur direktori dan integrasi Nouveau

  • Peran direktori utama adalah sebagai berikut
    • kernel-open/: lapisan antarmuka kernel
    • kernel-open/nvidia/: lapisan antarmuka kernel untuk nvidia.ko
    • kernel-open/nvidia-drm/: lapisan antarmuka kernel untuk nvidia-drm.ko
    • kernel-open/nvidia-modeset/: lapisan antarmuka kernel untuk nvidia-modeset.ko
    • kernel-open/nvidia-uvm/: lapisan antarmuka kernel untuk nvidia-uvm.ko
    • src/: kode OS-agnostic
    • src/nvidia/: kode OS-agnostic untuk nvidia.ko
    • src/nvidia-modeset/: kode OS-agnostic untuk nvidia-modeset.ko
    • src/common/: kode utilitas yang digunakan oleh satu atau lebih dari nvidia.ko dan nvidia-modeset.ko
    • nouveau/: alat integrasi driver perangkat Nouveau
  • Skrip Python di direktori nouveau mengekstrak beberapa image biner firmware yang dikodekan di dalam source code beserta data terkait, lalu menyimpannya sebagai file terpisah
  • File-file ini digunakan oleh driver perangkat Nouveau untuk memuat dan berkomunikasi dengan firmware GSP
  • Tata letak file biner dijelaskan dalam nouveau_firmware_layout.ods, dan file ini berformat OpenDocument Spreadsheet

Kontribusi dan penanganan isu

  • Kontribusi dilakukan dengan membuat pull request ke repositori open-gpu-kernel-modules milik NVIDIA
  • Saat mengirim pull request, wajib menyetujui Contributor License Agreement
  • Codebase ini dibagikan dengan driver proprietari NVIDIA, dan source code publik dihasilkan melalui berbagai pemrosesan atas kode bersama
    • Repositori GitHub pada dasarnya berfungsi seperti snapshot dari tiap rilis driver
    • Sulit mengharapkan tersedianya revision history untuk perubahan individual yang dilakukan di codebase bersama NVIDIA
    • Sangat mungkin tiap rilis driver hanya memiliki satu git commit
    • Kontribusi individual mungkin tidak tercermin sebagai git commit terpisah di repositori GitHub
    • Karena proses pemrosesan sebelum dipublikasikan, penerapan kontribusi ke codebase bersama memerlukan merge manual
    • Refaktorisasi besar bisa sulit untuk di-merge dan diterima, sehingga perlu kontak dan koordinasi sebelumnya
  • Masalah terkait Open GPU Kernel Modules dapat disampaikan melalui Issues di repositori NVIDIA, forum pengembang NVIDIA, atau linux-bugs@nvidia.com
  • Jika menemukan kerentanan keamanan, harus memeriksa dokumen SECURITY.md terpisah

Cakupan GPU yang kompatibel

  • Modul kernel terbuka NVIDIA dapat digunakan pada GPU Turing dan yang lebih baru
  • Untuk rincian dukungan fitur dan batasannya, diarahkan untuk merujuk ke dokumen kernel_open.html dalam README end user driver GPU NVIDIA
  • Untuk dukungan vGPU, harus merujuk ke README.vgpu yang disertakan dalam vGPU Host Package
  • Tabel GPU yang kompatibel mencantumkan nama produk bersama PCI ID
    • Jika ada tiga ID, yang pertama adalah PCI Device ID, yang kedua PCI Subsystem Vendor ID, dan yang ketiga PCI Subsystem Device ID
    • Tabel tersebut mencakup berbagai produk seperti 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, dan lain-lain

1 komentar

 
GN⁺ 2024-04-13
Opini Hacker News
  • Luar biasa. Saya sempat penasaran apakah ini mungkin, dan sekarang satu-satunya yang menghalangi rig 4x4090 untuk LLM lokal hanyalah waktu pembuatannya
    Kalau tensor parallelization bisa dilakukan, untuk inferensi sepertinya akan jauh lebih murah dan cepat daripada H100 SXM. Namun saya masih belum paham kenapa tinybox memilih konfigurasi 6 GPU. Banyak workload hanya berjalan baik di 4 atau 8 GPU, jadi sekarang rasanya seperti membayar untuk 6 tetapi hanya memakai 4, atau berakhir dengan konfigurasi tanggung yang bukan 8

    • tinygrad mendukung pembagian tidak merata. Tidak ada alasan fundamental harus 4 atau 8; dengan software yang bagus, pekerjaan bisa diparalelkan hampir sepenuhnya pada jumlah GPU berapa pun
      Alasan memilih 6 adalah karena ada 128 PCIe lane, yaitu 8 port x16. Jika 1 dipakai untuk NVMe dan 1 untuk jaringan, 6 GPU bisa dihubungkan sebagai full fabric. Kalau hanya memakai 4, PCIe terbuang; kalau memakai 8, hampir tidak ada ruang untuk koneksi eksternal selain beberapa USB3
    • Alasannya 6 GPU adalah karena dibutuhkan storage cepat, dan itu memakai PCIe lane
      Targetnya juga menjalankan model 70B FP16, yang kira-kira membutuhkan VRAM 140GB. 6*24GB = 144GB, jadi pas
    • 6 terlihat masuk akal. Sebagian dari 128 lane ThreadRipper harus dipakai untuk jaringan dan NVMe
      Misalnya 4 NVMe membutuhkan x16 lane, dan jaringan 10G membutuhkan x4 lane lagi
    • Saya sempat melihat materi NVIDIA SXM2 yang belum lama ini dipublikasikan, dan SXM2/NVLink 2.0 juga tampak seperti sistem 6-way
      NVIDIA SXM kemudian diperbarui ke versi 3 dan 4, dan konfigurasi ini juga bukan berbasis itu, tetapi mungkin ada alasan lain mengapa 6-way masuk akal
    • Akan bagus kalau bisa membagikan detail build yang sedang dipikirkan. Lab kami butuh server, tetapi pilihannya terlalu banyak sampai sulit mendapat gambaran
  • Ini benar-benar kabar baik. Karena berada di dunia akademik, saya tahu beberapa lab yang membuat mesin dengan beberapa 4090 lalu tidak menyadari bahwa Nvidia memblokir komunikasi P2P antarkartu
    Itu juga salah satu alasan saya tidak membeli 4090 untuk pekerjaan saya, meski harganya jauh lebih murah. Ini bukan NVLink, tetapi karena Nvidia hampir menghapus NVLink dari semua kartu selain yang paling atas, ini tetap lebih baik daripada tidak ada. Akhir tahun lalu saya mendapat penawaran untuk 4 unit NVLink H100, tetapi waktu pengirimannya 13 bulan; produk non-NVLink bisa diterima dalam 4 bulan. Saat ini saya membeli 4 unit L40S agar lab tetap berjalan, tetapi masalah rantai pasok dan kenaikan harga yang luar biasa membuat riset menjadi sangat sulit. Itu jauh dari cukup untuk mendukung 6 mahasiswa doktoral dan beberapa mahasiswa S1
    Pada 2015–2018 di universitas saya sebelumnya, kami bisa membuat mesin dengan 2 GPU dan NVLink seharga 5 ribu dolar per unit, lalu menaruh satu di bawah meja setiap mahasiswa; masa itu jauh lebih mudah

    • Bahkan sebelum itu, Nvidia sudah membuat hidup kami lebih sulit dengan secara bertahap menghilangkan desain blower pada kartu konsumen yang bisa dimasukkan ke server
      Dari sudut pandang lab, saya rasa kami akan selalu memilih kartu yang harganya 1/4 meskipun MTBF-nya setengah
    • Bagaimana biayanya dibandingkan dengan penyedia cloud GPU?
  • Apa arti P2P di sini? Saat saya cari, sepertinya peer to peer, tetapi dalam konteks kartu grafis itu maksudnya apa?

  • Saya berharap lebih banyak perusahaan hardware membuka dokumentasi dan membiarkan komunitas mencari tahu sisanya
    Mirip dengan yang terjadi pada IBM VGA awal. "Mode X" atau mode-mode hardware yang sebenarnya, bukan BIOS, bahkan 800x600x16 bisa ditemukan kalau dicari. Sayangnya, sebagian besar tampaknya lebih memilih mengontrol ketat semua aspek penggunaan produk untuk memeras lebih banyak uang dari basis pengguna. Secara pribadi, saya melihat masa ketika PC paling produktif juga merupakan masa ketika PC paling terbuka

    • Kalau begitu mereka tidak bisa mengenakan harga berbeda kepada pelanggan yang berbeda untuk hardware yang sama. Itu tidak menguntungkan semua pihak
    • Jika saya produsen hardware dan penguncian software atas fitur produk tidak berhasil, saya akan menggantinya dengan penguncian hardware
      Maka harga produk akan menjadi lebih mahal saja
    • Keterbukaan jelas bagus, tetapi sebenarnya tidak wajib. Orang-orang bisa mencari cara menangani sistem tertutup juga
      Interoperabilitas adversarial (adversarial interoperability) dulu umum, dan lewat rekayasa balik orang membuat software berjalan, entah produsen menginginkannya atau tidak. Yang dulu jarang tetapi kini umum adalah penguncian software dan hardware. Kriptografi seharusnya menjadi teknologi yang memberi kita kekuatan, tetapi pada akhirnya dipakai untuk mengecualikan kita dari mesin milik kita sendiri. Kini kita tidak lagi berada di kursi pengemudi. Bahkan sistem operasi pun tidak lagi benar-benar mengoperasikan sistem. Sistem Linux yang bebas sekalipun, di dalam gumpalan campuran firmware proprietary dan silikon yang tidak bisa diketahui produsen, hanyalah "OS pengguna"; lebih mirip komponen kecil yang disandbox dari operasi sebenarnya
    • Software Nvidia adalah moat mereka
  • Alasan awal Nvidia saat menghapus NVLink dari lini konsumen adalah bahwa PCIe 5 akan cukup cepat
    Namun seri 40xx dirilis tanpa PCIe 5 maupun dukungan P2P. Bagus bahwa setidaknya separuh dari itu kini terpenuhi, tetapi sulit membayangkan mereka akan mengizinkan ini juga di firmware generasi berikutnya

  • Apakah ini salah satu fitur yang dinonaktifkan pada kartu konsumen untuk segmentasi pasar?

    • Sampai batas tertentu, ya
      Sebagai analogi yang tidak sempurna, bayangkan ada permukiman kecil berisi sekitar 15 rumah yang sedang dibangun. Biasanya, di sudut jalan dipasang trafo 200 kVA dan jaringan listrik memasok daya yang sesuai. Namun karena kekurangan trafo, kontraktor memasang trafo komersial 1250 kVA. Trafo itu bisa memasok listrik ke jauh lebih banyak rumah daripada yang dibutuhkan, jadi beroperasi dengan kapasitas yang masih sangat longgar. Suatu hari, seorang penghuni ingin memulai fasilitas budidaya skala besar dan menemukan cara untuk mengaktifkan kapasitas trafo cadangan itu hanya untuk rumahnya. Yang ditemukan geohot kira-kira setara dengan “aktivasi” tersebut
    • Sepertinya ini akan banyak mendapat downvote, tapi saya berharap praktik seperti ini pada perangkat konsumen dilarang atau dikenai pajak yang sangat berat
    • Tidak ada insentif sama sekali untuk mengimplementasikan dan menguji fitur ini pada GPU konsumen. Konfigurasi multi-GPU untuk gaming hampir tidak pernah benar-benar berjalan dengan baik
  • Sejak dulu saya selalu kagum dengan kemampuan hacking George Hotz. Itu juga sangat menginspirasi proyek pribadi saya

    • Kalau melihat proses pengembangannya, benar-benar menarik. Kedermawanannya dalam membagikan proses itu juga layak dicatat
      Ia sering tersangkut pada masalah dangkal dan acak yang bagi engineer yang lebih berpengetahuan mungkin terasa tidak terlalu sulit. Ia juga sering terlihat menulis kode yang sangat buruk, bahkan kode yang salah. Adegan terkait Twitter adalah contoh yang bagus. Meski begitu, dengan gigih mengulanginya sendirian, ia juga sering menghasilkan perbaikan yang mengejutkan. Ini contoh bagus untuk dipelajari
    • Saya mendapat dorongan besar dari stream-nya. Fokus dan usaha adalah kunci hasil yang baik, dan jika ditambah visi serta strategi yang jelas, kesuksesan juga bisa diraih
      Selamat untuk geohot dan semua kontributor tinygrad/comma
    • Ia punya daya konsentrasi seperti pilot militer dalam penerbangan jarak jauh
    • Laptop Xbox360-nya adalah sumber motivasi utama masa remaja saya
  • Setelah melihat sekilas README, untuk yang penasaran, ini bukan NVLink, melainkan P2P di atas PCIe

    • RTX 40 tidak punya NVLink di PCB, tetapi karena beberapa kartu dari seri yang sama mendukungnya, kemungkinan ada di silikonnya. Saya kira mungkin dimatikan lewat fuse
    • Setahu saya 4090 tidak mendukung PCIe 5.0, jadi dibatasi pada kecepatan PCIe 4.0. Tetap saja ini sebuah peningkatan
  • Pada arsitektur mendatang, mereka akan mulai menguncinya di firmware, jadi nikmatilah selama masih bertahan

    • Benar, tapi toh cepat atau lambat hal itu memang akan terjadi
      Jadi lebih baik bisa dipakai setidaknya satu generasi daripada tidak ada sama sekali
  • Saya penasaran apakah George sendiri yang melakukannya, atau seseorang yang mengincar bounty yang dipasang tinycorp
    Dan saya ingin bertanya kepada orang yang paham subsistem PCI: bukankah ini terlihat lebih seperti NVIDIA tidak terlalu memedulikannya, ketimbang mereka secara aktif mencoba memblokirnya?

    • Perangkat PCI memang selalu bisa membaca dan menulis ruang alamat bersama. Memang dibatasi oleh IOMMU, tetapi biasanya paling sering dipakai untuk DMA ke RAM sistem, bukan berarti terbatas hanya untuk itu
      Jadi masuk akal untuk mengutak-atik perangkat agar seluruh VRAM dimasukkan ke ruang alamat. Cukup jika ada dukungan resizable BAR, atau BAR berukuran tetap yang cukup besar. Masuk akal juga untuk memerintahkan satu kartu membaca dan menulis alamat yang dipetakan ke VRAM kartu lain. Saya penasaran apakah kapasitas switching PCIe yang akan menjadi bottleneck, atau justru link point-to-point dan VRAM. Bagaimanapun, mengurangi perjalanan bolak-balik lewat RAM sistem akan membantu
    • Commit-nya atas nama geohot, jadi sepertinya George sendiri yang melakukannya
    • Perkembangannya juga dicatat di Discord tinygrad