8 GB compute and HBM: limits and open questions

80 GiB and about 120-126 SMs are now reported on hardware-modified 8 GB cards. Kate's November 10, 2026 GA100VFI write-up describes voltage glitching followed by permanent fuse programming. The lab's eight cards remain a separate software-unlocked sample reporting 64 GiB and 74 SMs; the lab has not reproduced GA100VFI. Source: repo github.com/kate-land/ga100vfi by kate-land on GitHub, 2026-11-10 Source: @darkmaniac7, 2026-11-11 (lab notes)

For installation, use Driver unlock. For current priorities and the register index, return to Developer status.

GA100VFI hardware results reported November 10

Kate reports usable 80 GiB on nine of ten examined 8 GB cards; one card had only 64 GiB usable and gained no framebuffer capacity. The write-up describes pseudorandom writes throughout the full framebuffer, read-back after L2 invalidation, and working inference workloads. It also shows two 20c2 devices reporting 81,920 MiB. This is the author's hardware result, not just a larger capacity readout, but the small sample does not establish a success rate for other batches.

Area	Reported result	Scope
Memory	80 GiB on nine cards; 64 GiB on one	Author reports full-framebuffer pattern tests and inference workloads; no local reproduction
Compute	About 120-126 functional SMs, varying by die	Published OpenCL output shows 124 compute units at 1,410 MHz
FP16	About 85.9 TFLOP/s, versus 50.1 software-unlocked and 72.5 retail A100	ProjectPhysX OpenCL-Benchmark half2 FMA, not Tensor Core throughput or a general inference speedup
PCIe	Gen3/Gen4 training and operation reported	Gen4 x16 also requires the PCIe capacitor modification and a compatible host; the displayed OpenCL run negotiated Gen3 x16
NVLink	Two 8 GB cards shown with NV12 topology	Additional board work and a host-side ROM-check bypass; no separate NVLink transfer benchmark is supplied in the post
ECC, MIG, NVDEC and NVJPG	Listed as potentially unlockable	Explicitly untested in the write-up; not validated feature support

The glitch temporarily changes control-fuse readouts. Kate then restores programming capability while the software-override gate remains open and appends permanent fuseless-fuse (FF) records that change effective floorsweep and PCIe options. This is not the free-RIR-slot method used on some 10 GB cards. The report also requires suitable driver geometry/configuration changes; it is not an ordinary cmpunlocker setting. The public repository snapshot supplies the board design, STM32 firmware, PWMVID host-control tools, register analysis and experiment-loop material, not a drop-in NVIDIA driver upgrade.

Hardware work and permanent changes are required. The setup uses an STM32G4 board, PWMVID/NVVDD connections and removal of a 0402 resistor. Kate reports 1-48 hours of glitching per card. Timing, occupied fuse rows and defect masks differ by die, so another card's fuse payload is not a transferable recipe. For NVLink, the reported U11 bridge bypasses whatever regulation or protection the missing component would provide and can join +3.3 V rails across supplies; Kate notes that modifying one board of a pair can power the bridge. See the original write-up for the hardware limitations. No glitching or fuse programming was performed on the lab's cards.

Reported 8 GB
Primary write-up: Kate, November 10, 2026. Source: repo github.com/kate-land/ga100vfi by kate-land on GitHub, 2026-11-10

Scope of the eight-card lab record

The remaining measurements describe the lab's November 10-11 software-only research with driver/GSP 615.71.09. That pass combined a configuration census, a read-only bridge map and offline firmware analysis. It demonstrated no additional VRAM or working SMs on those eight cards, and did not include a fresh full-range memory test or performance result. Those limits do not contradict Kate's separate hardware result. Source: @darkmaniac7, 2026-11-11 (lab notes)

What the reported capacity means

Card names refer to their original marketed capacity. Measurements below use binary units: 1 GiB = 1,024 MiB. The driver and CUDA expose different totals on these cards.

Observation on every card	Value	What it establishes
NVML total memory	65,536 MiB = 64 GiB	Driver-reported capacity
CUDA total memory	68,070,735,872 bytes, about 63.396 GiB	Capacity reported through the CUDA API
CUDA compute attributes	74 SMs, compute capability 8.0	Reported compute configuration
Memory configuration	FBPA_CFG1=0x02779000, MMU_LMR=0x20b	The existing unlocked geometry is selected

The census used register reads and CUDA attribute queries, with no memory allocations or kernel launches. A capacity report does not establish distinct, reliable storage at every address. That requires address-dependent writes and full read-back across the claimed range, including checks for aliasing into the lower region. See Verifying an unlock.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

Compute: where the 74 SMs come from

The known RECONFIG change releases two TPCs, giving the reported 70-to-74 SM step. The shipped patch describes its status model as:

STATUS = DISABLE | DEFECTIVE | CTRL | (RECONFIG & ~OVERRIDE)

In this model, the override affects the RECONFIG term. It does not clear the other disable terms. This explains the scope of the existing mechanism; it does not establish that all other compute research is exhausted.

Reported 8 GB
Source: @akuchen_66498, 2026-09-26
Source: repo github.com/amoghmunikote/cmpunlocker by amoghmunikote on GitHub
Source: @darkmaniac7, 2026-11-11 (lab notes)

The eight-card census closes the same arithmetic on every card. The register topology inspected here has eight GPC positions, eight TPC positions per GPC and two SMs per TPC. That is a 128-position accounting model for this capture, not a claim about the maximum physical layout of every GA100 die.

Category per card	TPC accounting	SM accounting
Two active GPCs with eight TPCs each	16 active	32 active
Three active GPCs with seven TPCs each	21 active, 3 unavailable	42 active, 6 unavailable
Three disabled whole GPCs	24 unavailable	48 unavailable
Total	37 active, 27 unavailable	74 active, 54 unavailable

Every per-GPC TPC override already reads 0xff. TPC control masks are zero, and effective TPC disable status equals the fused disable mask on every card. There is no residual candidate in the ordinary RECONFIG path in this sample. The speed-select registers also read SS0=0x88888888 and SS1=0x8, with effective feature readout 1 equal to zero, the known full-rate encoding. These observations are not a new throughput measurement. See Full SM unlock.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

HBM: inactive partitions are candidates, not capacity

Each lab card has the same partition counts, but the actual masks differ. A mask from another card is not a substitute for a same-card capture. Kate's hardware result supplies a public example of recovering excluded partitions; the corresponding storage on these eight lab cards remains untested.

Mask category per card	FBPs / FBPAs	Supported interpretation
Active	8 / 16	Included in the current configuration
Disabled, not marked defective	2 / 4	A possible research target; presence, health and an enable route remain unproved
Marked defective	2 / 4	Excluded by the captured masks; no recovery result is established

At the current geometry's nominal 4 GiB per active FBPA, 16 FBPAs account for the reported 64 GiB. If the four disabled FBPAs not marked defective had working storage, could be enabled and supported the same geometry, they would add 16 GiB for a total of 80 GiB. This is conditional arithmetic. A 96 GiB configuration at that geometry would require all 24 FBPAs. Neither result has been validated here, and a defective-mask category alone does not establish a unit's physical condition or recoverability.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

Register gates and recovery state

The captures establish the following state on these eight cards. They do not establish a universal gate configuration for every GA100 product.

Register or group	Captured value	Limit of the finding
EN_SW_OVERRIDE, 0x00820040	0 on all eight	The ordinary software-override enable is clear; no additional floorsweep-enable path was qualified
DISABLE_SW_OVERRIDE_STATUS, 0x00820084	1 on all eight	Observed gate state; not evidence that a host write can change it
GPC, TPC, FBP and FBPA control masks	0 on all eight	Clearing these already-zero masks supplies no observed enable transition
Row-remap override, 0x00823824	1 on three cards, 0 on five	The value alone does not establish enabled row remapping
Feature readout 2, 0x00823828, bit 0	Clear on all eight	No asserted initialization readout in this capture; correction and recovery still need functional tests

The row-remap register's exact write encoding and qualified writer remain unresolved in the inspected paths. See Fuses and floorsweep maps for the gate model and the developer hub's recovery status.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

What the bridge map adds

The read-only bridge map inspected 24 CFG1 apertures on each card. Sixteen were responsive on every card and returned 0x02779000; the others returned register-access errors. Broadcast controls and three samples from a selected responsive aperture per card showed INSTR=0xf, MODE=8, SHWIR=0xf0 and STATUS=0x10. The map made no host writes and did not read DATA. These are bridge observations, not a new HBM identity or capacity result.

The pinned hbmmon source explains why identity capture is a separate experiment: DATA reads advance the stream, and an INSTR write through one unicast aperture controls the global WIR master. A per-aperture address therefore does not imply an isolated experiment. The observed mode matches the source's temperature-polling regime; neither its control echo nor an inaccessible aperture establishes whether an inactive site contains working HBM.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)
Source: repo github.com/matstatman/hbmmon/tree/5e287354c292fabd7babb09c5ee5cdf25ade615e by matstatman on GitHub

What the firmware analysis establishes

Offline analysis of the captured 615.71.09 firmware matched the normal GA100 constructor to PMU package image 156. It also matched a GSP request to that image's unit 0x13, function 7 receiver. The receiver's inspected state transitions implement sequencer acquisition/release. Releasing it can continue queued work, so it is not a read-only query or a standalone rollback. The selected-image attribution is static; runtime loading and invocation were not measured by this analysis.

Following the queued work recovered a recipe builder and local, delegated and skipped step paths. Two clock-related steps lead to a payload-and-tag mailbox operation. These aperture stores bypass the inspected PRI helper, so counting calls to that helper does not cover every hardware-write path.

The normal GA100 method selection now identifies package image 20 as an FB Falcon image. Its channel 1, opcode 0 handler matches the PMU request and reply path. The handler divides the request by 1,000, checks a frequency range, calls a transition routine and returns a rounded result and status. The decoding and bounded synthetic checks establish this frequency-control path; they do not execute or validate a real transition.

Runtime activation, the profile-table contents and origin, and the full transition and failure effects remain unresolved. The selected GSP defaults clear the FB Falcon enable field; later policy can change it. A selected image getter therefore does not prove that the route was active on a card. No live command or added capacity is qualified by this finding.

Literal searches and selected register-helper analysis did not qualify an additional capacity or SM-enable route. Those are bounded negative results. Computed addresses, runtime-supplied scripts, other images or apertures and unsupported decoder instructions remain outside their coverage. Package image 20 now has a static GA100 attribution, but its runtime loading is unmeasured. Applying its reported CFG0 mask 0xdffff7ff to the captured 0x07981800 produces 0x07981000; bit 11 was set. That is not evidence that the image ran or that the mask adds capacity. The inspected evidence therefore supports neither an undiscovered unlock recipe nor a claim that no other route can exist.

Reported 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

The next useful discriminator

For GA100VFI, the next evidence is independent reproduction with per-card defect masks, capacity tests, working-SM checks and sustained workloads. The published result establishes a hardware avenue; it does not establish eligibility or an 80 GiB outcome for the lab's cards.

For research without permanent fuse changes, the missing path is still access to and initialization of an inactive site. Qualify the installed firmware's host-write gates, selector and poller behavior before a bounded identity capture with verified restoration. A valid identity would still leave mapping and capacity open: added memory needs a reversible mapping and dense address-dependent validation across both the original and added regions.

For firmware analysis, trace the frequency-profile tables and initialization source consumed by the recovered FB Falcon receiver, then the full transition and failure paths. The exact symbolic identity and units of the PMU domain mask remain unproved. A separately recovered metadata getter may help observe sequencer state, but its matching host transport and ownership still need qualification. For compute, a new mechanism needs changed topology, working-unit correctness and sustained performance above the existing 74-SM baseline. These are evidence targets, not proposed register writes. No fuse burn or firmware flash is proposed by this note.

Theory 8 GB
Source: @darkmaniac7, 2026-11-11 (lab notes)

The 10 GB card has separate evidence and firmware questions. See Memory unlock on the 10 GB card and The 10 GB card: provenance and the 80 GB question; this eight-card sample does not resolve them.

Firmware identification

The static PMU analysis used package image 156 with SHA-256 f3e86532268c258b14d6ca8812c4f05d618220fd26a490edb731c9ca7025ea5e. The captured GSP ELF SHA-256 is afa9ce3f65c28e1f6ab8c449e20e08bbb273855e3a97b1f5d332f57dfa9d68ea. FB Falcon image 20 is 122,880 bytes with SHA-256 97d20357ee74678b886da6247746d84be2185c07891d1f79a038b78d5f0558e4. Its selected descriptor gives application file offset = application PC + 0x1000. These identify the analyzed files and static mapping; they do not prove runtime loading. Source: @darkmaniac7, 2026-11-11 (lab notes)