Hacklenmiş Nvidia 4090 GPU sürücüsü P2P’yi etkinleştiriyor

 (github.com/tinygrad)
1 puan yazan GN⁺ 2024-04-13 | 1 yorum | WhatsApp'ta paylaş
  • Bu depo, NVIDIA Linux açık GPU çekirdek modülleri kaynak sürümüdür; README’ye göre sürüm 565.57.01’dir
  • Derlenen çekirdek modülleri, aynı 565.57.01 sürücü sürümünün GSP firmware’i ve kullanıcı alanı NVIDIA GPU sürücü bileşenleriyle birlikte kullanılmalıdır
  • Destek kapsamı x86_64 ve aarch64’tür; Linux çekirdeği, tescilli NVIDIA çekirdek modülüyle aynı aralığı destekler ve mevcut durumda 4.15 ve üzeridir
  • Çekirdek modülü, işletim sisteminden bağımsız bileşenler ve Linux çekirdek arayüz katmanı olarak ayrılır; hedef çekirdeğe uygun çekirdek arayüz katmanı derlenmelidir
  • Uyumlu GPU’lar Turing sonrası GPU’lardır; tabloda NVIDIA GeForce RTX 4090 dahil çeşitli GeForce, RTX, A/H/L serisi ürünler ve PCI ID’leri listelenir

Sürümler ve derleme koşulları

  • Bu depo, NVIDIA Linux open GPU kernel modules kaynak sürümüdür ve sürümü 565.57.01’dir
  • Temel derleme komutu şöyledir
    • make modules -j$(nproc)
  • Kurulumdan önce mevcut NVIDIA çekirdek modülleri kaldırılmalı ve root yetkisiyle şu komut çalıştırılmalıdır
    • make modules_install -j$(nproc)
  • Burada derlenen çekirdek modülleri, karşılık gelen 565.57.01 sürücü sürümünün GSP firmware’ini ve kullanıcı alanı NVIDIA GPU sürücü bileşenlerini gerektirir
    • NVIDIA GPU sürücüsü .run dosyasının --no-kernel-modules seçeneğiyle kurulması örnek olarak sunulur

Desteklenen mimariler ve araç zinciri

  • Çekirdek modülleri şu anda x86_64 veya aarch64 için derlenebilir
  • Çapraz derlemede TARGET_ARCH=aarch64|x86_64 ile birlikte CC, LD, AR, CXX, OBJCOPY make komut satırında belirtilir
  • GCC veya Clang’in nispeten güncel bir sürümüyle derlenebilir
  • Çekirdek modülünün çekirdek arayüz katmanı, hedef çekirdek derlenirken kullanılan araç zinciriyle derlenmelidir
  • Desteklenen Linux çekirdeği sürümleri, tescilli NVIDIA çekirdek modülünün desteklediği aralıkla aynıdır; mevcut durumda Linux kernel 4.15 ve üzeridir

Derleme seçenekleri

  • NV_VERBOSE=1 çalıştırılan tüm komutları yazdırır
    • Varsayılan değerde yalnızca kısa bir CC satırı yazdırılır
  • DEBUG=1 çekirdek modülünü hata ayıklama derlemesi olarak derler
    • Varsayılan derleme, hata ayıklama bilgisi olmadan derlenir
    • Bu seçenek ayrıca çekirdek modülündeki çeşitli hata ayıklama günlük mesajlarını etkinleştirir

Çekirdek modülü yapısı

  • NVIDIA çekirdek modüllerinin büyük kısmı iki bileşene ayrılır
    • OS-agnostic bileşen: işletim sisteminden bağımsız bölüm
    • kernel interface layer: Linux çekirdeği sürümüne ve ayarlarına özgü bölüm
  • NVIDIA .run kurulum paketinde OS-agnostic bileşen ikili olarak sağlanır
    • Bu bileşen büyük olduğu ve derlemesi uzun sürdüğü için, her sürücü kurulumunda kullanıcının yeniden derlememesi adına önceden derlenmiş sürüm sağlanır
    • nvidia.ko için ilgili bileşenin adı nv-kernel.o_binary’dir
    • nvidia-modeset.ko için ilgili bileşenin adı nv-modeset-kernel.o_binary’dir
    • nvidia-drm.ko ve nvidia-uvm.ko içinde OS-agnostic bileşen yoktur
  • Her çekirdek modülünün çekirdek arayüz katmanı hedef çekirdeğe uygun şekilde derlenmelidir

Dizin yapısı ve Nouveau entegrasyonu

  • Başlıca dizinlerin rolleri şöyledir
    • kernel-open/: çekirdek arayüz katmanı
    • kernel-open/nvidia/: nvidia.ko için çekirdek arayüz katmanı
    • kernel-open/nvidia-drm/: nvidia-drm.ko için çekirdek arayüz katmanı
    • kernel-open/nvidia-modeset/: nvidia-modeset.ko için çekirdek arayüz katmanı
    • kernel-open/nvidia-uvm/: nvidia-uvm.ko için çekirdek arayüz katmanı
    • src/: OS-agnostic kod
    • src/nvidia/: nvidia.ko için OS-agnostic kod
    • src/nvidia-modeset/: nvidia-modeset.ko için OS-agnostic kod
    • src/common/: nvidia.ko ve nvidia-modeset.ko modüllerinden en az birinde kullanılan yardımcı kod
    • nouveau/: Nouveau aygıt sürücüsü entegrasyon araçları
  • nouveau dizinindeki Python betikleri, kaynak koda kodlanmış bazı firmware ikili imajlarını ve ilgili verileri çıkarıp ayrı dosyalar olarak kaydeder
  • Bu dosyalar, Nouveau aygıt sürücüsünün GSP firmware yüklemesi ve onunla iletişim kurması için kullanılır
  • İkili dosya yerleşimi nouveau_firmware_layout.ods içinde açıklanmıştır; bu dosya OpenDocument Spreadsheet biçimindedir

Katkılar ve sorun yönetimi

  • Katkılar, NVIDIA’nın open-gpu-kernel-modules deposuna pull request oluşturularak yapılır
  • Pull request gönderirken Contributor License Agreement kabulü gerekir
  • Bu kod tabanı NVIDIA tescilli sürücüsüyle paylaşılır ve açık kaynak, paylaşılan koda çeşitli işlemler uygulanarak oluşturulur
    • GitHub deposu ağırlıklı olarak her sürücü sürümünün anlık görüntüsü gibi çalışır
    • NVIDIA paylaşımlı kod tabanında yapılan tekil değişikliklerin revision history’sinin sağlanmasını beklemek zordur
    • Her sürücü sürümünde yalnızca bir git commit bulunması muhtemeldir
    • Tekil katkılar GitHub deposunda ayrı bir git commit olarak yansıtılamayabilir
    • Yayın öncesi işleme süreci nedeniyle, katkıların paylaşımlı kod tabanına uygulanması için manuel birleştirme gerekir
    • Büyük refactoring’lerin birleştirilmesi ve kabulü zor olabileceğinden önceden iletişim ve koordinasyon gerekir
  • Open GPU Kernel Modules ile ilgili sorunlar NVIDIA deposundaki Issues bölümüne, NVIDIA geliştirici forumuna veya linux-bugs@nvidia.com adresine iletilebilir
  • Bir güvenlik açığı bulunursa ayrı SECURITY.md belgesine bakılmalıdır

Uyumlu GPU kapsamı

  • NVIDIA açık çekirdek modülleri Turing sonrası GPU’larda kullanılabilir
  • Özellik desteği ve kısıtlamaların ayrıntıları için NVIDIA GPU driver end user README’deki kernel_open.html belgesine başvurulması belirtilir
  • vGPU desteği için vGPU Host Package içindeki README.vgpu belgesine bakılmalıdır
  • Uyumlu GPU tablosu ürün adlarını ve PCI ID’lerini birlikte listeler
    • Üç ID varsa ilki PCI Device ID, ikincisi PCI Subsystem Vendor ID, üçüncüsü PCI Subsystem Device ID’dir
    • Tabloda 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 gibi birçok ürün yer alır

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-13
Hacker News görüşleri

  • Harika. Bunun mümkün olup olmadığını merak ediyordum; artık yerel LLM için 4x4090 sistemleri engelleyen tek şey, bunları yapma zamanı
    Tensor paralelleştirme olunca çıkarımda H100 SXM’den çok daha ucuz ve hızlı olacak gibi. Yine de tinybox’ın neden 6 GPU’lu yapılandırmayı seçtiğini hâlâ anlamıyorum. Pek çok iş yükü yalnızca 4 ya da 8 GPU’da iyi çalışıyor; şu an 6 GPU parası ödeyip sadece 4’ünü kullanmak ya da 8 olmayan arada kalmış bir yapılandırmaya sahip olmak gibi görünüyor

    • tinygrad dengesiz bölmeyi destekliyor. 4 ya da 8 olması için temel bir neden yok; yazılım iyiyse iş, herhangi bir GPU sayısında neredeyse tamamen paralelleştirilebilir
      6’nın seçilme nedeni PCIe hattının 128 adet, yani 8 tane x16 port olması. NVMe’ye 1, ağa 1 tane ayırınca 6 GPU’yu tam fabric ile bağlayabiliyorsunuz. Sadece 4 kullanırsanız PCIe’yi boşa harcarsınız; 8 kullanırsanız birkaç USB3 dışında harici bağlantı için alan kalmaz
    • 6 GPU olmasının nedeni hızlı depolamaya ihtiyaç duyulması ve bunun PCIe hatlarını kullanması
      Hedef de 70B FP16 model çalıştırmaktı ve kabaca 140 GB VRAM gerekiyor. 6*24 GB = 144 GB olduğundan tam uyuyor
    • 6 makul görünüyor. ThreadRipper’ın 128 hattının bir kısmını ağ ve NVMe için kullanmak gerekiyor
      Örneğin 4 NVMe x16 hat, 10G ağ da ayrıca x4 hat gerektirir
    • Kısa süre önce yayımlanan NVIDIA SXM2 materyallerine baktım; SXM2/NVLink 2.0 da 6-yollu bir sistem gibi görünüyordu
      NVIDIA SXM daha sonra 3 ve 4 sürümlerine güncellendi ve bu yapılandırma onun temeli de değil, ama 6-yollu olmasının mantıklı olmasının başka bir nedeni olabilir
    • Aklındaki build ayrıntılarını paylaşabilirsen iyi olur. Laboratuvar sunucusuna ihtiyacımız var ama seçenek o kadar çok ki pek kestiremiyorum

  • Gerçekten çok iyi haber. Akademide olduğum için, birden fazla 4090 ile sistem kurup Nvidia’nın kartlar arası P2P iletişimi engellediğini bilmeyen birkaç laboratuvar tanıyorum
    Benim işim için çok daha ucuz olmasına rağmen 4090 almama nedenlerimden biri de buydu. Bu NVLink değil ama Nvidia en üst seviye kartlar dışında NVLink’i neredeyse tamamen kaldırdığı için hiç yoktan iyidir. Geçen yılın sonunda NVLink’li 4 adet H100 için teklif aldım; teslim süresi 13 aydı, NVLink olmayan ürünler ise 4 ayda gelebiliyordu. Şimdilik laboratuvarı ayakta tutmak için 4 adet L40S aldım ama tedarik zinciri sorunları ve muazzam fiyat artışları araştırmayı çok zorlaştırıyor. 6 doktora öğrencisini ve birkaç lisans öğrencisini desteklemek için kesinlikle yetersiz
    2015~2018 yıllarında önceki üniversitemizde, 2 GPU’lu ve NVLink’li makineleri tanesi 5 bin dolara toplayıp her öğrencinin masasının altına birer tane koyabiliyorduk; o zamanlar çok daha kolaydı

    • Bundan önce de Nvidia, sunuculara takılabilen tüketici kartlarındaki blower tipi tasarımı aşamalı olarak kaldırarak hayatımızı zorlaştırmıştı
      Laboratuvar açısından MTBF yarı yarıya olsa bile fiyatı 1/4 olan kartı her zaman seçerdik gibi geliyor
    • GPU bulut sağlayıcılarıyla karşılaştırınca maliyet nasıl?

  • Buradaki P2P ne anlama geliyor? Arayınca peer to peer gibi görünüyor ama grafik kartı bağlamında bu ne demek?

  • Daha fazla donanım şirketinin dokümantasyonu açıp geri kalanını topluluğun çözmesine izin vermesini isterdim
    İlk IBM VGA’da yaşananlara benziyor. "Mode X" ya da BIOS olmayan donanımın gerçek modları, hatta 800x600x16 bile araştırıp bulunabiliyordu. Ne yazık ki çoğu şirket, kullanıcı kitlesinden daha fazla para koparmak için ürün kullanımının her yönünü sıkı sıkıya kontrol etmeyi tercih ediyor gibi. Bana göre PC’nin en üretken olduğu dönem, aynı zamanda en açık olduğu dönemdi

    • O zaman aynı donanım için farklı müşterilerden farklı fiyat alamazlar. Bu herkesin yararına değil
    • Donanım üreticisi olsaydım ve ürün özelliklerinin yazılımla kilitlenmesi işe yaramasaydı, bunun yerine donanım kilidine geçerdim
      O zaman ürün fiyatı sadece daha pahalı olurdu
    • Açıklık kesinlikle harikaydı ama aslında şart değildi. İnsanlar kapalı sistemlerle de başa çıkmanın yolunu bulabilir
      Hasmane birlikte çalışabilirlik (adversarial interoperability) yaygındı; üretici istese de istemese de tersine mühendislikle yazılımı çalışır hâle getirirlerdi. Eskiden nadir olup şimdi yaygınlaşan şey yazılım ve donanım kilitleri. Kriptografi bize güç veren bir teknoloji olmalıydı, ama sonunda bizi kendi makinelerimizden dışlamak için kullanılmaya başladı. Artık sürücü koltuğunda biz yokuz. İşletim sistemi bile artık sistemi işletmiyor. Özgür bir Linux sistemi bile, üreticinin ne yaptığını bilmediğimiz kapalı firmware ve silikon karışımı bir yığının içinde sadece "kullanıcı OS"si; gerçek işleyişten sandbox’a alınmış küçük bir parçaya daha yakın
    • Nvidia’nın yazılımı onların savunma hendeği

  • Nvidia’nın tüketici serisinden NVLink’i kaldırırken öne sürdüğü asıl gerekçe, PCIe 5’in yeterince hızlı olacağıydı
    Ama 40xx serisi ne PCIe 5 ne de P2P desteğiyle çıktı. Şimdi bunun yarısının bile yerine gelmesi iyi, fakat gelecek nesil firmware’de buna izin vereceklerini hayal etmek zor

  • Bu, tüketici kartlarında pazar ayrımı için devre dışı bırakılmış özelliklerden biri mi?

    • Bir ölçüde doğru
      Tam kusursuz bir benzetme değil ama, yaklaşık 15 evlik küçük bir mahallenin inşaat hâlinde olduğunu düşünün. Normalde köşeye 200 kVA’lık bir transformatör konur ve şebekeden uygun miktarda güç sağlanır. Ama transformatör sıkıntısı nedeniyle müteahhit ticari tip 1250 kVA’lık bir transformatör kurar. Gerektiğinden çok daha fazla eve enerji verebildiği için kapasitesinin epey altında çalışır. Bir gün bir sakin büyük ölçekli bir yetiştirme tesisi başlatmak ister ve o fazla transformatör kapasitesini yalnızca kendi evi için etkinleştirmenin yolunu bulur. geohot’un bulduğu şey tam da bu “etkinleştirme”ye karşılık geliyor
    • Çok eksi oy alacak gibi ama tüketici cihazlarında bu tür uygulamaların yasaklanmasını ya da çok ağır vergilendirilmesini isterdim
    • Bu özelliği tüketici GPU’larında uygulamak ve test etmek için hiçbir teşvik yok. Oyunculara yönelik çoklu GPU yapılandırmaları neredeyse hiçbir zaman düzgün çalışmadı

  • George Hotz’un hackleme becerisine eskiden beri hep hayran kaldım. Kişisel projelerim için de büyük ilham oldu

    • Geliştirme sürecini izlemek gerçekten ilginç. Bunu bu kadar cömertçe paylaşmasını da ayrıca belirtmek gerek
      Daha bilgili bir mühendisin daha az zorlanacağı yüzeysel ve keyfî sorunlarda sık sık takılıyor. Gerçekten kötü, hatta bazen yanlış kod yazdığını da sıkça görüyorsunuz. Twitter ile ilgili sahneler buna iyi bir örnek. Buna rağmen tek başına inatla tekrar tekrar deniyor ve aynı sıklıkta şaşırtıcı iyileştirmeler ortaya çıkarıyor. Öğrenilecek iyi bir örnek
    • Yayınlarından büyük motivasyon aldım. Odaklanma ve emek iyi sonuçların anahtarı; buna net bir vizyon ve strateji de eklenirse başarı da elde edilebilir
      geohot’u ve tinygrad/comma katkıcılarının hepsini tebrik ederim
    • Uzun menzilli uçuş yapan bir askerî pilot gibi bir odaklanması var
    • Onun Xbox360 dizüstü bilgisayarı, ergenlik yıllarımdaki motivasyonumun merkezindeydi

  • README’ye göz attım; merak edenler için söyleyeyim, bu NVLink değil, PCIe üzerindeki P2P

    • RTX 40’ın PCB’sinde NVLink yok, ama aynı aileden bazı kartlar desteklediğine göre silikonda bulunuyor olmalı. Muhtemelen sigortayla kapatılmıştır diye düşünüyorum
    • Bildiğim kadarıyla 4090 PCIe 5.0 desteklemiyor, bu yüzden PCIe 4.0 hızlarıyla sınırlı. Yine de bir iyileştirme

  • Gelecek mimarilerde bunu firmware’de kilitlemeye başlayacaklar; o yüzden sürdüğü sürece iyi olacak

    • Doğru, ama zaten eninde sonunda olacak şey buydu
      Bu yüzden hiç olmamasındansa bir nesil bile kullanabilmek daha iyi

  • Bunu George’un kendisi mi yaptı, yoksa tinycorp’un koyduğu ödülün peşine düşen biri mi yaptı merak ediyorum
    Ayrıca PCI alt sistemini iyi bilen birine sormak isterim: Bu, NVIDIA’nın aktif olarak engellemeye çalışmasından çok pek umursamamış gibi görünmüyor mu?

    • PCI cihazları her zaman paylaşılan adres alanını okuyup yazabiliyordu. IOMMU kısıtlarına tabi olsalar da, genelde en sık sistem RAM’ine DMA için kullanıldılar; ama bununla sınırlı değillerdi
      Bu yüzden cihaza müdahale edip tüm VRAM’i adres alanına koyacak şekilde yapılandırmak mantıklı. resizable BAR desteği varsa ya da sabit boyutlu BAR yeterince büyükse olur. Ayrıca bir karta, başka bir kartın VRAM’ine eşlenmiş adresleri okuyup yazmasını söylemek de mantıklı. Darboğazın PCIe anahtarlama kapasitesi mi, yoksa noktadan noktaya bağlantı ve VRAM mi olacağını merak ediyorum. Her iki durumda da sistem RAM’i üzerinden gidip gelmeyi azaltmak faydalı olacaktır
    • Commit geohot adına olduğu için George’un kendisi yapmış gibi görünüyor
    • İlerlemeyi tinygrad Discord’da da kaydetmişti