Hacked Nvidia 4090 GPU driver to enable P2P

Original Article ↗ Hacker News Discussion ↗

What the hack enables (P2P on RTX 40xx)

  • Patch to Nvidia’s open-source kernel driver on Linux enables GPU-to-GPU peer-to-peer (P2P) over PCIe on RTX 4090 and likely most 40xx cards.
  • P2P here means one GPU can read/write another GPU’s VRAM directly over PCIe, avoiding a bounce through system RAM and CPU.
  • This uses resizable BAR / large BAR to map full VRAM into the shared PCIe address space; IOMMU currently must be disabled.
  • It is explicitly not NVLink; bandwidth is much lower than data-center parts with NVLink, but still a significant gain over going via RAM.

Technical limits and performance considerations

  • PCIe 4.0 on 4090s caps bandwidth; P2P over PCIe is ~2× slower than 3090 NVLink and far slower than A100/H100 NVLink, but still useful.
  • Especially relevant for multi-GPU ML workloads (tensor/model parallelism, KV-cache sharding), less so for gaming or simple data-parallel tasks.
  • For many inference workloads, 2×4090 with P2P can easily beat a single workstation/datacenter card; training remains more constrained.
  • There’s debate over whether multi-GPU P2P is mainly about adding effective VRAM capacity vs. raw compute.

Nvidia product segmentation and “locked” features

  • Many commenters see this as another example of consumer cards shipping with hardware capabilities that are disabled in software for segmentation, pushing “serious” users to expensive A/H-series cards.
  • Others argue vendors have economic reasons: one silicon, multiple SKUs lowers manufacturing cost and recoups large R&D by price discrimination.
  • Some think the omission of P2P on 40xx may be an oversight; others expect future architectures/firmware to hard-disable such features once hacks appear.

Hardware / build implications

  • P2P makes multi-4090 rigs (4–6 GPUs) more attractive for local LLMs and other compute workloads; discussion of lane counts, PCIe switches, large BAR, and NVLink tradeoffs.
  • 6-GPU designs (e.g., 6×24GB = 144GB VRAM) are attractive but awkward for some libraries that expect 4 or 8 GPUs; some frameworks (like tinygrad) claim to support uneven splits.
  • There is interest in whether similar techniques can extend to 3090s and older GPUs; bandwidth, PCIe topology, and power cost are major constraints.

Legal, business, and future-lockdown concerns

  • Some worry Nvidia could respond via driver or firmware updates, or eventually through on-die e-fuses, making such hacks impossible.
  • Others argue visible hacks help regulators see what’s possible and may shape antitrust or “right to compute” debates.

Broader AI governance tangent

  • Large subthread debates “compute governance”: restricting access to powerful hardware to mitigate hypothetical AGI existential risk.
  • One side sees strict control (including extreme enforcement scenarios) as potentially justified; the other sees it as dystopian, unfalsifiable fear-mongering and a route to state/mega-corp control of AI.
  • There is no consensus; the only agreement is that AI’s dual-use nature makes regulation contentious.