ไดรเวอร์ GPU Nvidia 4090 ที่ถูกแฮ็ก เปิดใช้งาน P2P

 (github.com/tinygrad)
1 คะแนน โดย GN⁺ 2024-04-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รีโพซิทอรีนี้คือซอร์สรีลีสของ NVIDIA Linux open GPU kernel modules และตาม README ระบุเวอร์ชันเป็น 565.57.01
  • เคอร์เนลโมดูลที่คอมไพล์ขึ้นมาต้องใช้ร่วมกับเฟิร์มแวร์ GSP และคอมโพเนนต์ไดรเวอร์ NVIDIA GPU ฝั่ง user space ของ ไดรเวอร์รีลีส 565.57.01 เดียวกัน
  • รองรับ x86_64 และ aarch64 และรองรับ Linux kernel ในช่วงเดียวกับ NVIDIA kernel module แบบ proprietary โดยปัจจุบันคือ 4.15 ขึ้นไป
  • เคอร์เนลโมดูลแบ่งเป็นคอมโพเนนต์ที่ไม่ขึ้นกับระบบปฏิบัติการ และ ชั้นอินเทอร์เฟซ Linux kernel โดยต้องบิลด์ชั้นอินเทอร์เฟซเคอร์เนลให้ตรงกับเคอร์เนลเป้าหมาย
  • GPU ที่รองรับคือ GPU ตั้งแต่ Turing เป็นต้นไป และในตารางมีการระบุผลิตภัณฑ์ GeForce, RTX, ซีรีส์ A/H/L หลายรุ่น รวมถึง NVIDIA GeForce RTX 4090 พร้อม PCI ID

รีลีสและเงื่อนไขการบิลด์

  • รีโพซิทอรีนี้คือซอร์สรีลีสของ NVIDIA Linux open GPU kernel modules และมีเวอร์ชันเป็น 565.57.01
  • คำสั่งบิลด์พื้นฐานมีดังนี้
    • make modules -j$(nproc)
  • ก่อนติดตั้งต้องลบ NVIDIA kernel module เดิมออก และรันคำสั่งต่อไปนี้ด้วยสิทธิ์ root
    • make modules_install -j$(nproc)
  • เคอร์เนลโมดูลที่บิลด์จากที่นี่ต้องใช้เฟิร์มแวร์ GSP และคอมโพเนนต์ไดรเวอร์ NVIDIA GPU ฝั่ง user space ของ ไดรเวอร์รีลีส 565.57.01 ที่ตรงกัน
    • มีการยกตัวอย่างวิธีติดตั้งไฟล์ไดรเวอร์ NVIDIA GPU .run ด้วยออปชัน --no-kernel-modules

สถาปัตยกรรมที่รองรับและ toolchain

  • ปัจจุบันสามารถบิลด์เคอร์เนลโมดูลสำหรับ x86_64 หรือ aarch64 ได้
  • หาก cross-compile ให้ระบุ TARGET_ARCH=aarch64|x86_64 พร้อมกับ CC, LD, AR, CXX, OBJCOPY บนบรรทัดคำสั่งของ make
  • สามารถบิลด์ด้วย GCC หรือ Clang เวอร์ชันค่อนข้างใหม่ได้
  • ชั้นอินเทอร์เฟซเคอร์เนล ของเคอร์เนลโมดูลต้องบิลด์ด้วย toolchain เดียวกับที่ใช้บิลด์เคอร์เนลเป้าหมาย
  • เวอร์ชัน Linux kernel ที่รองรับเท่ากับช่วงที่ NVIDIA kernel module แบบ proprietary รองรับ ซึ่งปัจจุบันคือ Linux kernel 4.15 ขึ้นไป

ออปชันการบิลด์

  • NV_VERBOSE=1 จะแสดงคำสั่งทั้งหมดที่ถูกรัน
    • ค่าเริ่มต้นจะแสดงเพียงบรรทัด CC แบบสั้น
  • DEBUG=1 จะคอมไพล์เคอร์เนลโมดูลเป็น debug build
    • การบิลด์ปกติจะคอมไพล์โดยไม่มีข้อมูลดีบัก
    • ออปชันนี้ยังเปิดใช้งานข้อความ debug log หลายรายการของเคอร์เนลโมดูลด้วย

โครงสร้างของเคอร์เนลโมดูล

  • NVIDIA kernel module ส่วนใหญ่แบ่งออกเป็นสองคอมโพเนนต์
    • คอมโพเนนต์ที่ไม่ขึ้นกับ OS: ส่วนที่เป็นอิสระจากระบบปฏิบัติการ
    • kernel interface layer: ส่วนที่เฉพาะกับเวอร์ชันและการตั้งค่าของ Linux kernel
  • ในแพ็กเกจติดตั้ง .run ของ NVIDIA จะมีการแจกจ่ายคอมโพเนนต์ที่ไม่ขึ้นกับ OS ในรูปแบบไบนารี
    • คอมโพเนนต์นี้มีขนาดใหญ่และใช้เวลาคอมไพล์นาน จึงมีเวอร์ชันที่บิลด์ไว้ล่วงหน้าเพื่อไม่ให้ผู้ใช้ต้องคอมไพล์ใหม่ทุกครั้งที่ติดตั้งไดรเวอร์
    • ชื่อคอมโพเนนต์นี้ใน nvidia.ko คือ nv-kernel.o_binary
    • ชื่อคอมโพเนนต์นี้ใน nvidia-modeset.ko คือ nv-modeset-kernel.o_binary
    • nvidia-drm.ko และ nvidia-uvm.ko ไม่มีคอมโพเนนต์ที่ไม่ขึ้นกับ OS
  • ชั้นอินเทอร์เฟซเคอร์เนล ของแต่ละเคอร์เนลโมดูลต้องบิลด์ให้ตรงกับเคอร์เนลเป้าหมาย

โครงสร้างไดเรกทอรีและการทำงานร่วมกับ 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
    • src/nvidia/: โค้ดที่ไม่ขึ้นกับ OS สำหรับ nvidia.ko
    • src/nvidia-modeset/: โค้ดที่ไม่ขึ้นกับ OS สำหรับ nvidia-modeset.ko
    • src/common/: โค้ดยูทิลิตีที่ใช้ใน nvidia.ko หรือ nvidia-modeset.ko อย่างน้อยหนึ่งตัว
    • nouveau/: เครื่องมือสำหรับทำงานร่วมกับไดรเวอร์อุปกรณ์ Nouveau
  • สคริปต์ Python ในไดเรกทอรี nouveau จะดึง อิมเมจไบนารีของเฟิร์มแวร์ บางส่วนที่ฝังอยู่ในซอร์สโค้ดพร้อมข้อมูลที่เกี่ยวข้อง แล้วบันทึกเป็นไฟล์แยก
  • ไฟล์เหล่านี้ถูกใช้โดยไดรเวอร์อุปกรณ์ Nouveau เพื่อโหลดและสื่อสารกับ เฟิร์มแวร์ GSP
  • เลย์เอาต์ของไฟล์ไบนารีมีอธิบายไว้ใน nouveau_firmware_layout.ods ซึ่งเป็นไฟล์รูปแบบ OpenDocument Spreadsheet

การมีส่วนร่วมและการจัดการปัญหา

  • การมีส่วนร่วมทำผ่านการสร้าง pull request ไปยังรีโพซิทอรี open-gpu-kernel-modules ของ NVIDIA
  • เมื่อต้องการส่ง pull request จำเป็นต้องยอมรับ Contributor License Agreement
  • โค้ดเบสนี้ใช้ร่วมกับไดรเวอร์ proprietary ของ NVIDIA และซอร์สแบบเปิดถูกสร้างขึ้นจากโค้ดที่ใช้ร่วมกันหลังผ่านกระบวนการหลายขั้นตอน
    • รีโพซิทอรีบน GitHub ทำงานคล้าย snapshot ของแต่ละไดรเวอร์รีลีสเป็นหลัก
    • ไม่ควรคาดหวังว่าจะมี revision history ของการเปลี่ยนแปลงรายรายการที่เกิดขึ้นในโค้ดเบสส่วนกลางของ NVIDIA
    • มีความเป็นไปได้สูงว่าแต่ละไดรเวอร์รีลีสจะมี git commit เพียงหนึ่งรายการ
    • การมีส่วนร่วมรายรายการอาจไม่สามารถสะท้อนเข้ารีโพซิทอรี GitHub เป็น git commit แยกได้
    • เนื่องจากมีกระบวนการก่อนเผยแพร่ การนำ contribution ไปใช้กับโค้ดเบสส่วนกลางจึงต้อง merge ด้วยมือ
    • การรีแฟกเตอร์ขนาดใหญ่อาจ merge และรับเข้าได้ยาก จึงควรติดต่อและประสานงานล่วงหน้า
  • ปัญหาที่เกี่ยวข้องกับ Open GPU Kernel Modules สามารถส่งไปยัง Issues ของรีโพซิทอรี NVIDIA, ฟอรัมนักพัฒนา NVIDIA หรือ linux-bugs@nvidia.com
  • หากพบช่องโหว่ด้านความปลอดภัย ควรดูเอกสาร SECURITY.md แยกต่างหาก

ขอบเขต GPU ที่รองรับ

  • NVIDIA open kernel modules ใช้งานได้กับ GPU ตั้งแต่ Turing เป็นต้นไป
  • รายละเอียดการรองรับฟีเจอร์และข้อจำกัดให้ดูเอกสาร kernel_open.html ใน NVIDIA GPU driver end user README
  • การรองรับ vGPU ให้ดู README.vgpu ที่รวมอยู่ใน vGPU Host Package
  • ตาราง 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 เป็นต้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-04-13
ความคิดเห็นใน Hacker News

  • ยอดมาก เคยสงสัยว่าเรื่องนี้ทำได้ไหม ตอนนี้สิ่งเดียวที่ขวาง เครื่อง 4x4090 สำหรับ LLM แบบโลคัลก็คือเวลาในการสร้างเท่านั้น
    ถ้าทำ tensor parallelism ได้ ก็น่าจะถูกกว่าและเร็วกว่า H100 SXM มากสำหรับงาน inference แต่ยังไม่เข้าใจว่าทำไม tinybox ถึงเลือกคอนฟิก GPU 6 ตัว งานจำนวนมากรันได้ดีเฉพาะกับ 4 หรือ 8 ตัว ตอนนี้ดูเหมือนจ่ายเงินสำหรับ 6 ตัวแต่ใช้จริงแค่ 4 ตัว หรือกลายเป็นคอนฟิกก้ำกึ่งที่ไม่ใช่ 8 ตัว

    • tinygrad รองรับ การแบ่งแบบไม่เท่ากัน ไม่มีเหตุผลพื้นฐานว่าต้องเป็น 4 หรือ 8 ตัว และถ้าซอฟต์แวร์ดี งานก็สามารถทำให้ขนานกันได้เกือบสมบูรณ์แบบไม่ว่าจะมี GPU กี่ตัว
      เหตุผลที่เลือก 6 ตัวคือมี PCIe lane 128 เลน หรือก็คือพอร์ต x16 จำนวน 8 พอร์ต ใช้กับ NVMe 1 พอร์ต และเครือข่าย 1 พอร์ต ก็จะเชื่อม GPU 6 ตัวแบบ full fabric ได้ ถ้าใช้แค่ 4 ตัวก็เสีย PCIe เปล่า และถ้าใช้ 8 ตัวก็แทบไม่เหลือช่องทางเชื่อมต่อภายนอกนอกจาก USB3 ไม่กี่พอร์ต
    • เหตุผลที่เป็น GPU 6 ตัวคือจำเป็นต้องมีสตอเรจความเร็วสูง และสิ่งนั้นใช้ PCIe lane
      เป้าหมายก็คือรันโมเดล 70B FP16 ซึ่งต้องใช้ VRAM ประมาณ 140GB พอดีกับ 6*24GB = 144GB
    • 6 ตัวดูสมเหตุสมผลดี ใน 128 เลนของ ThreadRipper ต้องแบ่งบางส่วนไปให้เครือข่ายและ 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 ออกจากการ์ดที่ไม่ใช่รุ่นท็อปไปหมดแล้ว มีก็ยังดีกว่าไม่มี ปลายปีที่แล้วผมขอใบเสนอราคาสำหรับ H100 แบบ NVLink 4 ใบ ระยะเวลาส่งมอบคือ 13 เดือน ส่วนรุ่นที่ไม่มี NVLink รับได้ใน 4 เดือน ตอนนี้ซื้อ L40S 4 ใบมาเพื่อประคองแล็บไว้ แต่ปัญหาซัพพลายเชนและราคาที่พุ่งขึ้นมหาศาลทำให้งานวิจัยลำบากมาก มันไม่เพียงพออย่างยิ่งสำหรับสนับสนุนนักศึกษาปริญญาเอก 6 คนและนักศึกษาปริญญาตรีอีกหลายคน
    ตอนปี 2015~2018 ที่มหาวิทยาลัยเก่า เราสามารถสร้างเครื่องที่มี GPU 2 ใบพร้อม NVLink ได้ในราคาเครื่องละ 5,000 ดอลลาร์ แล้ววางไว้ใต้โต๊ะให้นักศึกษาแต่ละคนได้ ตอนนั้นง่ายกว่ามาก

    • ก่อนหน้านั้น Nvidia ก็ทำให้ชีวิตเรายากขึ้นแล้ว ด้วยการค่อย ๆ เลิกดีไซน์แบบ blower ของการ์ดผู้บริโภคที่ใส่ในเซิร์ฟเวอร์ได้
      จากมุมมองของแล็บ ต่อให้ MTBF เหลือครึ่งเดียว ก็คงเลือกการ์ดที่ราคาแค่ 1/4 ได้เสมอ
    • เมื่อเทียบกับผู้ให้บริการ GPU cloud แล้ว ต้นทุนเป็นอย่างไร?

  • P2P ในที่นี้หมายถึงอะไร? ลองค้นดูเหมือนจะเป็น peer to peer แต่ในบริบทของการ์ดจอมันหมายความว่าอะไร?

    • หมายความว่าเวลาส่งข้อมูลจากหน่วยความจำของ GPU ตัวหนึ่งไปยัง GPU อีกตัว ไม่จำเป็นต้องผ่าน RAM ของระบบ https://xilinx.github.io/XRT/master/html/p2p.html
    • หมายถึง การเข้าถึงหน่วยความจำร่วมกัน ระหว่าง GPU ของ Nvidia
      https://developer.nvidia.com/gpudirect
    • คำที่ถูกต้อง และในอดีตคนส่วนใหญ่คงเรียกแบบนี้ คือ bus mastering
    • เป็นคำที่งี่เง่า เหมือนกับเรียกลิงก์ RS-232 ว่า peer to peer นั่นแหละ

  • อยากให้บริษัทฮาร์ดแวร์จำนวนมากขึ้นเปิดเอกสาร แล้วปล่อยให้ชุมชนค้นหาส่วนที่เหลือเอง
    คล้ายกับสิ่งที่เกิดขึ้นกับ IBM VGA ยุคแรก ๆ ลองไปดู "Mode X" หรือโหมดจริงของฮาร์ดแวร์ที่ไม่ใช่ BIOS แม้แต่ 800x600x16 ก็ได้ น่าเสียดายที่ส่วนใหญ่ดูเหมือนจะชอบควบคุมทุกแง่มุมของการใช้ผลิตภัณฑ์อย่างแน่นหนา เพื่อรีดเงินจากฐานผู้ใช้ให้มากขึ้น โดยส่วนตัวผมคิดว่าช่วงที่ PC มีประสิทธิผลมากที่สุดก็เป็นช่วงที่ เปิดกว้างที่สุด เช่นกัน

    • ถ้าเป็นแบบนั้นก็จะคิดราคาต่างกันกับลูกค้าแต่ละรายบนฮาร์ดแวร์เดียวกันไม่ได้ ไม่ใช่ว่าทุกคนจะได้ประโยชน์
    • ถ้าผมเป็นผู้ผลิตฮาร์ดแวร์ และ การล็อกฟีเจอร์ด้วยซอฟต์แวร์ ใช้ไม่ได้ผล ผมก็จะเปลี่ยนไปล็อกด้วยฮาร์ดแวร์แทน
      แล้วราคาสินค้าก็จะยิ่งแพงขึ้นเฉย ๆ
    • ความเปิดกว้างยอดเยี่ยมแน่นอน แต่จริง ๆ แล้วไม่ใช่สิ่งจำเป็น ผู้คนหาวิธีจัดการกับระบบปิดได้
      adversarial interoperability เป็นเรื่องปกติ และคนก็ทำ reverse engineering ให้ซอฟต์แวร์รันได้ ไม่ว่าผู้ผลิตจะอยากหรือไม่ก็ตาม สิ่งที่เมื่อก่อนพบได้น้อยแต่ตอนนี้พบได้ทั่วไปคือ การล็อกซอฟต์แวร์·ฮาร์ดแวร์ วิทยาการเข้ารหัสควรเป็นเทคโนโลยีที่มอบอำนาจให้เรา แต่สุดท้ายกลับถูกใช้เพื่อกีดกันเราออกจากเครื่องของเราเอง ตอนนี้เราไม่ได้อยู่หลังพวงมาลัยแล้ว แม้แต่ระบบปฏิบัติการก็ไม่ได้ควบคุมระบบอีกต่อไป แม้แต่ระบบ Linux ที่เสรีก็เป็นเพียง "OS ของผู้ใช้" ภายในก้อนที่ประกอบจากเฟิร์มแวร์และซิลิคอนแบบปิดที่ผู้ผลิตไม่เปิดเผย และแทบจะเป็นแค่ชิ้นส่วนเล็ก ๆ ที่ถูก sandbox ออกจากการทำงานจริง
    • ซอฟต์แวร์ของ Nvidia คือ คูเมือง ของพวกเขา

  • เหตุผลดั้งเดิมที่ Nvidia ยกมาเมื่อถอด NVLink ออกจากไลน์อัปผู้บริโภค คือ PCIe 5 น่าจะเร็วพอแล้ว
    แต่ซีรีส์ 40xx กลับออกมาโดยไม่มีทั้ง PCIe 5 และการรองรับ P2P ตอนนี้ดีที่อย่างน้อยก็เติมเต็มได้ครึ่งหนึ่ง แต่ยากจะจินตนาการว่าพวกเขาจะยอมให้ทำแบบนี้ต่อในเฟิร์มแวร์เจเนอเรชันถัดไป

  • นี่เป็นหนึ่งในฟีเจอร์ที่ถูกปิดไว้ในการ์ดสำหรับผู้บริโภคเพื่อ แบ่งแยกตลาด ใช่ไหม?

    • ก็ถูกในระดับหนึ่ง
      เปรียบเทียบแบบไม่สมบูรณ์นัก ลองนึกว่ามีชุมชนเล็ก ๆ ราว 15 หลังคาเรือนกำลังก่อสร้างอยู่ ปกติจะมีหม้อแปลง 200kVA วางไว้ที่หัวมุม แล้วจ่ายไฟจากโครงข่ายในระดับที่เหมาะสม แต่เพราะขาดแคลนหม้อแปลง ผู้รับเหมาจึงติดตั้งหม้อแปลงเชิงพาณิชย์ 1250kVA แทน มันจ่ายไฟให้บ้านได้มากกว่าที่จำเป็นมาก จึงทำงานโดยเหลือความจุอยู่อีกเยอะ วันหนึ่งผู้อยู่อาศัยคนหนึ่งอยากเริ่มทำฟาร์มปลูกขนาดใหญ่ เลยหาวิธีเปิดใช้ความจุหม้อแปลงส่วนเกินนั้นเฉพาะบ้านตัวเอง สิ่งที่ geohot ค้นพบก็คือการ “เปิดใช้” แบบนั้นเอง
    • คงโดนโหวตลบเยอะแน่ แต่ผมอยากให้ห้ามแนวปฏิบัติแบบนี้ในอุปกรณ์ผู้บริโภค หรือไม่ก็เก็บภาษีให้หนักมาก
    • ไม่มีแรงจูงใจเลยที่จะนำฟีเจอร์นี้ไปใส่และทดสอบใน GPU สำหรับผู้บริโภค การจัดชุด มัลติ GPU สำหรับเล่นเกมแทบไม่เคยทำงานได้ดีจริง ๆ

  • ผมทึ่งในฝีมือแฮ็กของ George Hotz มาตลอดตั้งแต่ก่อนหน้านี้แล้ว โปรเจกต์ส่วนตัวของผมก็ได้รับแรงบันดาลใจอย่างมากจากเขา

    • ถ้าดูกระบวนการพัฒนาของเขาจะเห็นว่าน่าสนใจมาก ความใจกว้างที่เขาแชร์ให้ดูก็ควรกล่าวถึงด้วย
      เขามักติดกับปัญหาตื้น ๆ และค่อนข้างสุ่ม ซึ่งวิศวกรที่มีความรู้มากกว่าน่าจะรู้สึกว่ายากน้อยกว่า มักเห็นเขาเขียนโค้ดที่แย่มาก หรือแม้แต่โค้ดที่ผิดจริง ๆ ฉากเกี่ยวกับ Twitter เป็นตัวอย่างที่ดี แต่ถึงอย่างนั้น เขาก็วนทำซ้ำอย่างดื้อดึงด้วยตัวคนเดียว และสร้างการปรับปรุงที่น่าทึ่งได้บ่อยพอ ๆ กัน เป็นตัวอย่างที่ดีให้เรียนรู้
    • ผมได้รับแรงกระตุ้นอย่างมากจากสตรีมของเขา สมาธิและความพยายามคือหัวใจของผลลัพธ์ที่ดี และถ้ามีวิสัยทัศน์กับกลยุทธ์ที่ชัดเจนเพิ่มเข้าไป ก็สามารถไปถึง ความสำเร็จ ได้
      ขอแสดงความยินดีกับทั้ง geohot และผู้มีส่วนร่วมใน tinygrad/comma
    • เขามี สมาธิ แบบนักบินทหารที่กำลังบินระยะไกล
    • แล็ปท็อป Xbox360 ของเขาเป็นแรงบันดาลใจสำคัญในช่วงวัยรุ่นของผม

  • ผมไล่อ่าน README คร่าว ๆ แล้ว สำหรับคนที่สงสัย นี่คือ P2P บน PCIe ไม่ใช่ NVLink

    • RTX 40 ไม่มี NVLink บน PCB แต่การ์ดบางรุ่นในตระกูลเดียวกันรองรับ ดังนั้นน่าจะมีอยู่ในซิลิคอน อาจถูกปิดไว้ด้วยฟิวส์
    • เท่าที่รู้ 4090 ไม่รองรับ PCIe 5.0 เลยถูกจำกัดที่ ความเร็ว PCIe 4.0 ถึงอย่างนั้นก็ยังถือว่าเป็นการปรับปรุง

  • ในสถาปัตยกรรมรุ่นต่อ ๆ ไป พวกเขาคงเริ่มล็อกสิ่งนี้ไว้ในเฟิร์มแวร์ ดังนั้นระหว่างที่ยังใช้ได้ก็คงดี

    • ใช่ แต่ยังไงสักวันมันก็ต้องเป็นแบบนั้นอยู่แล้ว
      ดังนั้นได้ใช้สักหนึ่งเจเนอเรชันก็ยังดีกว่าไม่มีเลย

  • สงสัยว่า George ทำเองหรือเปล่า หรือเป็นคนที่หวังเงินรางวัลที่ tinycorp ตั้งไว้
    และอยากถามคนที่รู้ระบบย่อย PCI ดี ๆ ว่า เรื่องนี้ดูเหมือน NVIDIA ไม่ได้พยายามบล็อกอย่างจริงจัง แต่แค่ไม่ได้สนใจมากกว่า ใช่ไหม?

    • อุปกรณ์ PCI สามารถอ่านและเขียนพื้นที่แอดเดรสที่ใช้ร่วมกันได้มาโดยตลอด แม้จะถูกจำกัดโดย IOMMU แต่ปกติมักถูกใช้กับ DMA ไปยัง RAM ของระบบเป็นหลักเท่านั้น ไม่ได้จำกัดอยู่แค่นั้น
      ดังนั้นการไปแตะอุปกรณ์เพื่อกำหนดค่าให้เอา VRAM ทั้งหมดเข้าไปอยู่ในพื้นที่แอดเดรสจึงสมเหตุสมผล ถ้ามีการรองรับ resizable BAR หรือถ้า BAR ขนาดคงที่ใหญ่พอก็ทำได้ และการสั่งให้การ์ดใบหนึ่งอ่านและเขียนแอดเดรสที่แมปไปยัง VRAM ของการ์ดอีกใบก็สมเหตุสมผลเช่นกัน อยากรู้ว่าความจุการสวิตช์ของ PCIe จะเป็นคอขวด หรือว่าลิงก์แบบจุดต่อจุดกับ VRAM จะเป็นคอขวด ไม่ว่าจะทางไหน การลดการวิ่งไป-กลับผ่าน RAM ของระบบก็น่าจะช่วยได้
    • คอมมิตเป็นชื่อ geohot เลยดูเหมือนว่า George ทำเอง
    • เขายังบันทึกความคืบหน้าไว้ใน Discord ของ tinygrad ด้วย