NextBSD graphics: porting the NVIDIA driver as per-branch co-existing kexts

One NVIDIAGraphics<NNN>.kext per FreeBSD nvidia branch — drm/modeset/core tiers, per-branch firmware, and the hard single-branch-per-kernel wall · built from NVIDIA’s driver tarball like FreeBSD’s nvidia ports. Draft, July 2026.

Bottom line. Port the FreeBSD NVIDIA driver as six co-existing, per-branch Apple-style kexts — NVIDIAGraphics595 / 580 / 470 / 390 / 340 / 304.kext — built from NVIDIA’s driver tarball exactly as FreeBSD’s nvidia ports do — compile the kernel glue against the local kernel, link the nv-kernel blob, wrap the .kos with ko2kext.sh — and shipped as packages on the same terms FreeBSD ships nvidia-driver. Three method tiers fall straight out of NVIDIA’s own module history: drm-kms (595, 580 — ship nvidia + nvidia-modeset + nvidia-drm, bind the shared drmn/IOGraphics core, give /dev/dri/cardN); modeset-only (470, 390 — nvidia + nvidia-modeset, no FreeBSD nvidia-drm bridge, no /dev/dri); core-only (340, 304 — nvidia.ko alone). All six sit inert on disk and the matcher autoloads exactly one by GPU. The permanent, unfixable wall: every branch’s core module is literally named nvidia, so the kernel’s global module namespace allows at most one NVIDIA branch resident per running kernel. Single-GPU is the fully-supported target; multi-GPU works only when a single branch covers every card present.

Update (validated against the real nextbsd-kernel-modules source + a real supported-gpus.json). Two of this plan’s corrections were themselves refined once the actual repo was read, and both make the first PR easier: (1) the matcher is confirmed PCI-id personalities, not marketing-name strings — the shipping gen-i915/amdgpu/radeon-personalities.sh emit IOPCIPrimaryMatch tables, CI de-overlaps (gen-radeon -x) and asserts the sets pairwise-disjoint. So §6 is resolved and gen-nvidia-personalities is the right tool. (2) ko2kext.sh wraps exactly one .ko, so NVIDIA follows the existing convention of one kext per module, chained by OSBundleLibraries (as IntelGraphics.kext→IOGraphics→TTM) — not one fat 3-module bundle. The multi-.ko “packaging blocker” below dissolves: it only existed under the one-fat-kext assumption. And a bonus: supported-gpus.json’s legacybranch field partitions all six branches with no hand-maintained arch map. First PR landed: tools/gen-nvidia-personalities.sh + selftest (branch nvidia-gen-personalities), validated end-to-end against a real 2224-chip table (395 unified/Turing+ ids, disjoint from the legacy branches). See §3/§6 for the corrected specifics.

0. What you asked, and the two corrections that shape everything

The request: name the newest branch by version too (NVIDIAGraphics595.kext, not a bare NVIDIAGraphics.kext) so the version is always legible; port as many older branches as possible as co-existing kexts; tier them by method — DRM/KMS, else nvidia-modeset, else nvidia.ko only. That taxonomy is exactly right and is adopted verbatim. A three-agent adversarial review surfaced two things the naive version of this plan got wrong, and both are baked into what follows:

A kext is not one .ko. The drm-kms tiers involve three modules and the modeset tier two, chained by MODULE_DEPEND (nvidia_drm → nvidia_modeset → nvidia). Since ko2kext.sh wraps one .ko, each becomes its own kext chained by OSBundleLibraries (the DMABuf/IOGraphics/TTM pattern): NVIDIAGraphics595.kext wraps nvidia-drm and depends on a modeset kext and a core kext, plus IOGraphics. Loading the top (nvidia-drm) pulls the chain; a single fat 3-module bundle would need a ko2kext extension and is not how this repo works (see §3).
“Co-exist together on one system” means co-exist on disk, not co-resident. The matcher loads one branch; a second branch’s load fails EEXIST in the kernel module namespace (§5). This is inherent to NVIDIA’s driver on FreeBSD and Linux, not a kext artifact.

1. The six branches and the three method tiers

As of mid-2026 FreeBSD ships one current branch plus five frozen legacy branches. There is no 570 legacy port — 570 was a transient mainline version superseded by 580; do not create a 570 kext. Version numbers below are examples; pin the exact branch version at build from each port’s distinfo.

Kext	Branch / port	Method	Modules bundled (bold = load target = CFBundleExecutable)	`/dev/dri`?	Firmware	GPU families	Binds IOGraphics?
`NVIDIAGraphics595.kext`	main / 595 x11/nvidia-kmod (+ graphics/nvidia-drm-kmod)	drm-kms	nvidia-drm → nvidia-modeset → nvidia	yes	GSP blobs (see §4)	Turing, Ampere, Ada, Hopper, Blackwell	yes (`drmn`)
`NVIDIAGraphics580.kext`	580 x11/nvidia-kmod-580	drm-kms	nvidia-drm → nvidia-modeset → nvidia	yes	GSP blobs (see §4)	Maxwell, Pascal, Volta + Turing…Blackwell	yes (`drmn`)
`NVIDIAGraphics470.kext`	470 x11/nvidia-kmod-470	modeset-only	nvidia-modeset → nvidia	no	none	Kepler (GeForce 600/700)	no
`NVIDIAGraphics390.kext`	390 x11/nvidia-kmod-390	modeset-only	nvidia-modeset → nvidia	no	none	Fermi (GeForce 400/500)	no
`NVIDIAGraphics340.kext`	340 x11/nvidia-kmod-340	core-only	nvidia	no	none	Tesla (GeForce 8/9/200/300)	no
`NVIDIAGraphics304.kext`	304 x11/nvidia-kmod-304	core-only	nvidia	no	none	Curie (GeForce 6/7)	no

Correction to the local roster. nextbsd-graphics-plan.html §7 (and the naming roster) classify 390 as nvidia.ko-only. That is wrong: 390 is the kernel-modesetting cutoff — it ships nvidia-modeset.ko; only 340 and 304 predate modeset and are truly core-only. Wrapping 390 without nvidia-modeset ships a degraded kext. (FreeBSD handbook / forums thread 92568.)

Why 470/390 are “modeset-only” despite shipping an nvidia-drm.ko upstream: the gap is FreeBSD-specific. graphics/nvidia-drm-kmod builds the DRM bridge only for the main and 580 branches; there is no FreeBSD nvidia-drm for 470/390/340/304, so those give X11 UMS + nvidia-modeset console KMS but never /dev/dri. Verify at build against that Makefile before finalizing the 470/390 tier — it is the single fact the whole no-/dev/dri, no-IOGraphics classification hangs on.

2. Naming: every kext carries its branch number

Adopted rule, per your request: the kext basename always carries the branch number; there is no unnumbered “latest” alias. So NVIDIAGraphics595.kext, not NVIDIAGraphics.kext. When 600 lands it is a new numbered kext with no rename churn, and a machine’s loaded kext tells you the driver series at a glance.

Fits the sibling GPU kexts. The shipping drivers are IntelGraphics/AMDGraphics/RadeonGraphics (org.nextbsd.driver.*Graphics), so NVIDIAGraphics<NNN> is more doctrine-consistent than the plan’s own bare NVIDIA/NVIDIALegacy* names. Fold this into naming decision D1 (naming-plan §3, still open) and rename the roster’s NVIDIALegacy* rows to match.
Bundle ids: org.nextbsd.driver.NVIDIAGraphics595 … .NVIDIAGraphics304. A per-branch-unique CFBundleIdentifier is mandatory (it is the only bundle key guaranteed unique across branches within a tier).
The flat name drops one signal the old Legacy prefix carried: which branches are KMS vs X11-only, and “Graphics” arguably over-promises KMS for core-only 340/304. Mitigation: carry the method tier and the IOGraphics dependency in Info.plist metadata and these docs, not in the basename, so the name stays uniform while capability stays discoverable.

3. The packaging blocker: many `.ko`s, one load target

NextBSD’s ko2kext.sh model gives a kext one Contents/MacOS/<executable> and keys loaded-state off that single CFBundleExecutable. But an NVIDIA drm-kms kext bundles three modules and the dependency runs nvidia_drm → nvidia_modeset → nvidia (each depends on the one below). Loading the leaf nvidia pulls in nothing above it — you get /dev/nvidia and no KMS. You must load the top of the chain, which drags its dependencies down. Therefore:

Tier	Bundled `.ko`s	`CFBundleExecutable` (load target)	Result
drm-kms (595, 580)	nvidia, nvidia-modeset, nvidia-drm	`nvidia-drm`	full KMS, `/dev/dri/cardN`
modeset-only (470, 390)	nvidia, nvidia-modeset	`nvidia-modeset`	console KMS + X11 UMS, no `/dev/dri`
core-only (340, 304)	nvidia	`nvidia`	`/dev/nvidia` only

ko2kext.sh needs a multi-.ko packaging step it does not have today: stage all of a branch’s modules into the bundle, set CFBundleExecutable to the tier’s top module, and ensure the intra-bundle dependency chain resolves within the bundle (via OSBundleLibraries / full-path preload) rather than by bare module name across the whole Extensions tree — see the linker.hints hazard in §5. This also corrects a premise the first-pass plan leaned on: CFBundleExecutable is not identical across all six (it is nvidia-drm / nvidia-modeset / nvidia by tier). Note CFBundleExecutable is the .ko filename, which you may rename per branch without touching the binary; only the compiled-in DECLARE_MODULE name is immutable — and that immutable name is what causes the load-time wall.

OSBundleLibraries, and why NVIDIA omits TTM/DMABuf

The 595/580 kexts link only the drmn/IOGraphics core (ko2kext.sh -l org.nextbsd.kext.iographics); nvidia-drm’s hard bind is MODULE_DEPEND(nvidia_drm, drmn, 2,2,2). Unlike the i915/amdgpu kexts they do not list TTM/DMABuf — NVIDIA uses its own memory manager, not the Linux TTM path. That asymmetry vs the sibling kexts is correct, not an oversight; state it in the Info.plist rationale so nobody “fixes” it.

4. Firmware: raw GSP blobs in `Resources/firmware/`, only on the Turing+ kexts

Match the mechanism NextBSD’s shipping drm kexts already use (drm612 plan §3): firmware is staged as raw blobs — cp -RL into <kext>/Contents/Resources/firmware/ — and the kernel finds them via the firmware_path kernel patch. No separate firmware kext, and not the firmware(9)-.ko model (which would add yet another module to the load chain and compound §3). Only two branches carry firmware:

Branch	GSP firmware	Default	Notes
595	`gsp_tu10x.bin` (Turing) + `gsp_ga10x.bin` (Ampere and all newer: Ada/Hopper/Blackwell)	GSP off by default; required only for Blackwell / RTX-50	Bundle both blobs. Enable per-GPU via `hw.nvidia.registry.EnableGpuFirmware=1`.
580	same two blobs	GSP off by default	The Maxwell/Pascal/Volta GPUs this branch uniquely covers are pre-GSP and never touch it.
470/390/340/304	none	—	Empty `Resources/`. (470 ships a legacy `gsp.bin` that only GSP-enables a few datacenter parts; treat as pre-GSP for packaging.)

Correction to the first-pass synthesis. It called 595 “open-kernel-modules only” with GSP “mandatory, no fallback,” and drew a mandatory-vs-optional GSP split between 595 and 580. On FreeBSD that is false: x11/nvidia-kmod (main) ships the proprietary module (the nv-kernel.o blob) with GSP default-off; GSP-off works for Turing/Ampere/Ada and only Blackwell/RTX-50 forces it on. Both 595 and 580 default GSP off. This also keeps the nv-kernel.o link step coherent (proprietary modules have that blob; open ones don’t).

The two GSP blobs total on the order of tens of MB, so the 595 and 580 bundles are materially larger than the four empty-Resources/ legacy kexts — a packaging/size note, not a blocker. There is no third GSP variant to chase (gsp_ga10x.bin already covers Ada/Hopper/Blackwell); just re-check each tarball’s firmware/ dir at build.

5. Co-existence: on disk yes, co-resident no

On disk — fine, that is the point

All six bundles stage side-by-side in the kext directory. Each carries its branch’s .kos, its own de-overlapped IOPCIPrimaryMatch table, its firmware (595/580 only), and a per-branch-unique CFBundleIdentifier. They do nothing until the matcher autoloads one.

One real on-disk hazard: the linker.hints namespace. All six bundles’ inner cores compile to module name nvidia (plus nvidia_modeset/nvidia_drm). kldxref builds linker.hints over the whole Extensions tree, so six files each declare a nvidia provider. Bare-name MODULE_DEPEND resolution could then bind one branch’s modeset/bridge against another branch’s core — silent cross-branch KBI contamination. Defense: resolve the modeset/bridge to their core strictly intra-bundle (OSBundleLibraries / full-path preload, per §3), and ensure kldxref does not publish six ambiguous nvidia providers (per-branch .ko filenames help here, but the internal module name still collides at load — below).

Co-resident — impossible, permanently

A kext only wraps the unmodified .ko; the kernel sees the module by its compiled-in DECLARE_MODULE name, not the bundle directory. Every branch’s core is literally module nvidia (the modeset/bridge are uniformly nvidia_modeset/nvidia_drm). FreeBSD’s module_register() does module_lookupbyname() and returns EEXIST if that name is already resident — version is irrelevant; name identity alone drives it. So the first branch loads; a second branch’s kldload hits EEXIST at module_register before any driver attaches, and kern_linker unwinds and unloads the entire linker file.

Renaming the internal module to dodge this means patching NVIDIA’s binary (we don’t — we build and ship it unmodified, like the FreeBSD port), and severing the MODULE_DEPEND chain and the /dev/nvidia* userland contract. Off the table. At most one NVIDIA branch is resident per running kernel, and this is identical on stock FreeBSD and Linux (you cannot install two nvidia-driver branches concurrently there either).

Single-GPU — the supported target

All six kexts on disk; the matcher maps the card to exactly one branch; that one loads; the other five stay unloaded so the name collision never fires. For 595/580 the bridge binds drmn and creates /dev/dri/cardN; the older branches are /dev/nvidia-only. A single loaded branch already drives multiple same-generation GPUs via /dev/nvidia0..N. Cross-vendor is normal (an Intel/AMD card on card0, NVIDIA on card1, sharing drmn).

Multi-GPU — the honest limitation

Two NVIDIA cards work only if a single branch covers all of them. Because just one branch can be resident, a box with (say) a Kepler card [max branch 470] and a Blackwell card [needs 595] cannot drive both: whichever branch loads first wins, and the other card falls back to efifb/vt.

Subtlety the first-pass plan got backwards: the per-card “newest-branch-wins” de-overlap (§6) can itself manufacture this problem for a config a single upstream driver handles. A Maxwell + Ada box: de-overlap assigns Maxwell→580 and Ada→595, so the matcher wants two branches → EEXIST → one card dark. Yet a stock single 580 install drives both (Ada is inside 580’s raw range). So per-card de-overlap optimizes single-card correctness at the cost of same-vendor multi-card coverage.

Required handling: when multiple NVIDIA cards are present, do not pick per-card — pick the one branch that covers the most (ideally all) present cards, defaulting to the branch covering the primary-display card, with an explicit user override (loader tunable / per-kext property) to pin the branch. Document the un-coverable disjoint case (Kepler + Blackwell) as a permanent limitation, not a bug.

6. The load-bearing open question: how does the matcher pick a branch?

Everything above assumes NextBSD’s userspace matcher autoloads one branch by GPU. There are two candidate mechanisms, and which one NextBSD actually uses is unconfirmed and must be settled before committing:

PCI-id personalities (the graphics-plan model). gen-nvidia-personalities parses each branch’s supportedchips.html into an exact, non-contiguous 0x10de id list, then computes a global de-overlap (newest branch that lists a chip wins) so the six match tables are pairwise-disjoint. NVIDIA support ranges are cumulative and overlap heavily (a Turing card is in both 580’s and main’s raw lists), so verbatim lists would match one card to two or three kexts. A descending IOProbeScore (595 > 580 > 470 >…) is belt-and-suspenders for any residual overlap.
Marketing-name-string selection (what the closely-related lineage actually shipped). Per freebsd-gpu-detection-comparison.html §7/§9, the IOPCIMatch+IOProbeScore personality approach for NVIDIA was ripped out in Phase 1d because hand-curated PCI-id tables “don’t scale”; the shipping selector matches the GPU’s marketing-name string against per-branch patterns, newest-first (the NomadBSD model) — and it ships one nvidia-drm-kmod with no version selection at all.

RESOLVED — it is option 1 (PCI-id personalities). Reading the real nextbsd-kernel-modules settled this: gen-i915/amdgpu/radeon-personalities.sh parse each driver’s own device table into IOPCIPrimaryMatch words (0xDDDDVVVV), the CI de-overlaps with gen-radeon -x <amdgpu-match> and asserts the match sets pairwise-disjoint, and ko2kext.sh -p injects the block the in-kernel IOService matcher reads. So this repo already does exact-PCI-id NVIDIA-style selection with de-overlap — the marketing-name-string lineage below was a different project. gen-nvidia-personalities.sh is therefore the right tool and now exists (built on supported-gpus.json, partitioning branches by the legacybranch field, -x-capable like gen-radeon; validated against a real 2224-chip table). Remaining minor confirmations, not blockers: that the matcher honors exact non-contiguous lists (the sibling kexts already rely on this) and whether IOProbeScore tie-breaks or only registration order (the legacybranch partition is disjoint regardless).

7. Base & DRM bump: which branches are coupled

Separate the two halves of the “6.6→6.12” story, because they touch different branches:

The DRM-6.12 half (drm-kmod branch flip) affects only 595 and 580, via their nvidia-drm bridge’s hard MODULE_DEPEND(nvidia_drm, drmn, 2,2,2). The bridge must be rebuilt against the exact drmn core commit IOGraphics ships — a stock pkg .ko will never do, and after IOGraphics moves to drm-6.12 the bridge follows in lockstep.
The base-15.1 half (kernel KBI) affects all six. Every branch’s core nvidia.ko open-shim is recompiled against the kernel obj, so a releng/15.0 → 15.1 bump re-KBIs all of them. This corrects an executive-summary overstatement from the first pass (“only the drm-kms branches are affected by the bump”) — only the drm-6.12 half is exclusive to 595/580; the base bump is universal.

Branch	DRM-6.12 coupled?	Base-15.1 (kernel KBI) coupled?	Build risk on 15.x
595, 580	yes (bridge lockstep)	yes	low
470, 390	no bridge	yes	moderate
340, 304	no bridge	yes	high — predate open-modules & modern LinuxKPI; may not compile against a 15.x kernel at all. 304 is the likely drop.

Practical rule: the recipe always rebuilds nvidia-drm against whatever drm core IOGraphics is currently built from.

Confirmed against the real FreeBSD ports tree (July 2026). The earlier hedge that nvidia-drm-612-kmod was “possibly an invented name” was wrong — it is a real port, and there is a whole OSVERSION-selecting family. graphics/nvidia-drm-kmod is a metaport that picks the bridge by kernel version:

OSVERSION ≥ 1500509 (15.1+) → nvidia-drm-612-kmod → RUN_DEPENDS drm-612-kmod (6.12)
OSVERSION ≥ 1500031 (15.0)  → nvidia-drm-66-kmod  → RUN_DEPENDS drm-66-kmod  (6.6)
else                          → nvidia-drm-61-kmod  → RUN_DEPENDS drm-61-kmod  (6.1)

Each builds src/nvidia-drm/ from NVIDIA’s tarball with USES=kmod against DRMKMODDIR=<drm-kmod source>, fetching two distfiles (the NVIDIA tarball + the matching drm-kmod source). And 595.84 is the genuine current version (x11/nvidia-driver distinfo: NVIDIA-FreeBSD-x86_64-595.84.tar.xz, 328 MB), not a placeholder — the legacy branch versions (580.119.02, 470.256.02…) remain examples to pin at build.

7a. One shared `drm.ko` core — Intel/AMD/Radeon and NVIDIA move together

There is exactly one drm.ko (drmn) core on the system, and the entire drm-kmod tree is a single versioned unit. The shipping CI proves it: the drm-kmod job builds drm + i915kms + amdgpu + radeonkms from one freebsd/drm-kmod checkout, and IntelGraphics/AMDGraphics/RadeonGraphics all -l org.nextbsd.kext.iographics (the single IOGraphics.kext = drm.ko). nvidia-drm binds that same core. So the core version is all-or-nothing:

nvidia-drm-612-kmod RUN_DEPENDS on drm-612-kmod’s drm.ko; drm-612-kmod even CONFLICTS_INSTALL with drm-66-kmod. You cannot run 6.6 i915/amdgpu/radeon against a 6.12 drm.ko — the KBI won’t match.
So choosing nvidia-drm-612 means IOGraphics is 6.12, which means IntelGraphics/AMDGraphics/RadeonGraphics are already 6.12 — rebuilt from the same drm-612 source. NVIDIA does not “force” the others individually; they travel together as one stack, and NVIDIA rides the shared core.
The only way to add NVIDIA without touching the others is to stay on the 6.6 core and build nvidia-drm-66-kmod. That is the sole reason to prefer -66. Going 6.12 is fine and forward-looking; it just brings the whole stack.

Sequencing — the real dependency chain. drm-612-kmod is hard-gated at OSVERSION ≥ 1500509 (15.1) and IGNOREs on 15.0 (the 6.12 LinuxKPI symbols aren’t in the 15.0 kernel). The modules repo CI still pins FREEBSD_BRANCH: releng/15.0 + drm-kmod --branch 6.6-lts. So nvidia-drm-612 cannot build until the base is actually 15.1 and the drm-kmod job is flipped to 6.12-lts. The order is fixed:

15.1 base bump → drm-kmod 6.6-lts → 6.12-lts
  (IOGraphics + IntelGraphics + AMDGraphics + RadeonGraphics all rebuilt at 6.12)
    → then nvidia-drm-612-kmod rides on the 6.12 core

That first step is its own effort — the drm-kmod 6.6→6.12 upgrade plan (decision) and the 15.1/drm-612 execution plan. NVIDIA step 2 is downstream of it.

7b. What the drm-612 bump actually costs (and why NVIDIA is spared it)

The execution plan’s one real code surprise is the Intel device-id generator (#337) — the exact “Intel IDs don’t line up” issue. On 6.6, gen-i915-personalities.sh greps INTEL_VGA_DEVICE(0x…) literals out of i915_pciids.h. 6.12 restructured that header: the IDs moved into MACRO__(0x…) entries inside per-platform INTEL_<PLAT>_IDS(…) macros, so the old regex matches zero lines → empty IntelGraphics.kext → the generator’s [ -n ] guard exit 1s. The fix is not a regex swap — a naive header scrape over-claims xe-only platforms (INTEL_LNL_IDS Lunar Lake / INTEL_BMG_IDS Battlemage, no i915 driver in 6.12-lts) and under-claims transitive includes (INTEL_MTL_IDS pulls in INTEL_ARL_IDS). The correct extraction is preprocessor-driven off the driver’s own pciidlist[] in i915_pci.c (→ 364 bound IDs; LNL/BMG absent, ARL present). amdgpu (308 rows) and radeon (699 rows) are unaffected. Full implementation-ready diff in that plan’s §3.7.

NVIDIA is immune to this class of breakage. gen-nvidia-personalities.sh parses supported-gpus.json — a stable, versioned data file — not C macros that upstream restructures between releases. So the 6.6→6.12 header churn that breaks gen-i915 has no analogue for NVIDIA; the generator that landed in #17 is drm-version-agnostic.

8. The build repo and the build DAG

NVIDIA is built the same way FreeBSD’s nvidia ports build it: fetch NVIDIA’s driver tarball at build, compile the kernel glue against the local kernel, link the nv-kernel blob, and wrap with ko2kext.sh. The compiled result is redistributable — FreeBSD ships nvidia-driver/nvidia-kmod as binary packages under LICENSE_PERMS = dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept — so NextBSD can ship the resulting kexts in nextbsd-pkg the same way, carrying NVIDIA’s license file (doc/license.txt) and not selling them. Whether the build/wrap lives in a sibling repo (nextbsd-nvidia) or a job in nextbsd-kernel-modules is a build-architecture choice. This mirrors FreeBSD’s split of x11/nvidia-driver → x11/nvidia-kmod + graphics/nvidia-drm-kmod.

Stand up the NVIDIA build (sibling repo nextbsd-nvidia or a job in nextbsd-kernel-modules); fetch NVIDIA’s tarball at build (no NVIDIA source vendored in-repo).
Provide the NextBSD kernel obj (/usr/src/sys artifacts + linker.hints) and the exact IOGraphics.kext/drmn commit the 595/580 bridges must KBI-match.
Per branch, in parallel: fetch the unmodified tarball; recompile the shim + link nv-kernel.o → nvidia.ko (all six), nvidia-modeset.ko (595/580/470/390), and — only 595/580 — nvidia-drm.ko against the step-2 drmn.
gen-nvidia-personalities: parse all six supportedchips.html and compute the global de-overlap in one pass (re-run whenever any branch’s chip list changes — a point release can move a boundary GPU). Gated on §6 first.
Per branch: stage firmware raw into Resources/firmware/ (595/580 only).
Per branch: ko2kext.sh with the multi-.ko step (§3) — CFBundleExecutable = tier top module; unique CFBundleIdentifier; -l org.nextbsd.kext.iographics and -f firmware for 595/580 only.
Assemble all six; validate the six match tables are pairwise-disjoint (no id in zero or two lists) before shipping.
Test single-GPU autoload end-to-end per card; confirm a second branch’s load reports a clean EEXIST “branch already resident.”
License: carry NVIDIA’s doc/license.txt in the kext/package and don’t sell it — the same terms FreeBSD ships nvidia-driver under (LICENSE_PERMS pkg-mirror no-pkg-sell auto-accept).

9. Per-branch recipe checklist

Fetch the branch’s unmodified tarball at build; pin the exact version. Never host it in the repo.
Confirm the module set — do not over/under-wrap: 595/580 = 3 modules; 470/390 = 2 (verify no FreeBSD bridge exists first); 340/304 = 1.
Compile the shim against the kernel obj + link nv-kernel.o. For 340/304 treat a build failure against 15.x as “drop this branch,” not a blocker for the others.
Bridge pin (595/580): rebuild nvidia-drm against the exact drmn commit IOGraphics ships.
Personalities: take this branch’s slice from the global de-overlap; emit exact non-contiguous 0x10de ids; stamp descending IOProbeScore.
Firmware: raw blobs in Resources/firmware/ for 595/580; nothing for the rest.
Wrap: unique CFBundleIdentifier; CFBundleExecutable = tier top module; -l/-f only for 595/580.
Properties: set hw.nvidiadrm.modeset=1 (read-only, pre-load) for the KMS branches; document hw.nvidia.registry.EnableGpuFirmware.
Validate: 595/580 → /dev/dri/cardN; 470/390 → /dev/nvidia + modeset, no /dev/dri; 340/304 → /dev/nvidia only.

10. Risks & open questions

Matcher premise (§6) — RESOLVED: the real repo does PCI-id personalities with de-overlap; gen-nvidia-personalities.sh built + validated. No longer a blocker.
Multi-.ko packaging (§3) — ko2kext.sh as written wraps one .ko with CFBundleExecutable=nvidia and would never load KMS on four of six branches. The multi-module step is net-new.
Licensing — not a blocker: FreeBSD ships nvidia-driver/nvidia-kmod as binary packages (LICENSE_PERMS pkg-mirror no-pkg-sell auto-accept); NextBSD ships the kexts on the same terms — carry the license file, don’t sell.
Legacy build ceiling — 340/304 may not compile on 15.x; the “6 branches” goal realistically delivers 4–5. 304 is likely dropped.
De-overlap correctness — must run globally and regenerate on any supportedchips.html change, or a boundary GPU lands in zero or two tables (nondeterministic autoload).
linker.hints cross-branch binding (§5) — six nvidia providers on disk; enforce intra-bundle resolution.
Exact __FreeBSD_version floors unconfirmed for the legacy branches; resolve from each port’s Makefile at build. 595.84 is the confirmed current version; the legacy versions (580.119.02, 470.256.02…) remain examples to pin at build.
Multi-GPU semantics (§5) — ship the “pin one branch covering the most cards” policy + user override, and document the disjoint-case fallback honestly.

NextBSD NVIDIA multi-branch kext porting plan · July 2026. Synthesized and adversarially reviewed by a 9-agent workflow (5 research finders: branch landscape, module composition, firmware, coexistence, pipeline grounding → synthesis → 3 review lenses: coexistence-correctness, branch/module accuracy, pipeline/base-bump). Corrections folded in from review: 390 is modeset-only not core-only; CFBundleExecutable is per-tier not uniform (multi-.ko load step required); 595 uses the proprietary module with GSP default-off (not open-modules/GSP-mandatory); firmware is raw blobs in Resources/firmware/ (not firmware(9) .kos); the base-15.1 bump touches all six branches, only drm-6.12 is 595/580-exclusive; per-card de-overlap can break same-vendor multi-card. Post-review, reading the real nextbsd-kernel-modules + FreeBSD ports settled the open items (see the Update banner and §6/§7): matcher confirmed PCI-id personalities; one kext per .ko chained; nvidia-drm-612-kmod and 595.84 confirmed real; the whole drm-kmod stack (Intel/AMD/Radeon + NVIDIA) shares one 6.12 drm.ko core. Grounded in the local NextBSD docs (nextbsd-graphics-plan §7, freebsd-gpu-detection-comparison, freebsd-ko-to-kext-conversion-plan, nextbsd-kld-to-kext-naming-plan, nextbsd-drm612-upgrade-plan) and NVIDIA/FreeBSD ports facts (flagged where unverified). A plan, not a promise.

NextBSD graphics: porting the NVIDIA driver as per-branch co-existing kexts

0. What you asked, and the two corrections that shape everything

1. The six branches and the three method tiers

2. Naming: every kext carries its branch number

3. The packaging blocker: many .kos, one load target

OSBundleLibraries, and why NVIDIA omits TTM/DMABuf

4. Firmware: raw GSP blobs in Resources/firmware/, only on the Turing+ kexts

5. Co-existence: on disk yes, co-resident no

On disk — fine, that is the point

Co-resident — impossible, permanently

Single-GPU — the supported target

Multi-GPU — the honest limitation

6. The load-bearing open question: how does the matcher pick a branch?

7. Base & DRM bump: which branches are coupled

7a. One shared drm.ko core — Intel/AMD/Radeon and NVIDIA move together

7b. What the drm-612 bump actually costs (and why NVIDIA is spared it)

8. The build repo and the build DAG

9. Per-branch recipe checklist

10. Risks & open questions

3. The packaging blocker: many `.ko`s, one load target

4. Firmware: raw GSP blobs in `Resources/firmware/`, only on the Turing+ kexts

7a. One shared `drm.ko` core — Intel/AMD/Radeon and NVIDIA move together