--- title: "GPU BAR1 and Framebuffer Memory: Why the Two Totals Do Not Add" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/gpu-bar1-mapping-versus-frame-buffer-memory" last-updated: "2026-10-20" --- # GPU BAR1 and Framebuffer Memory: Why the Two Totals Do Not Add Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. BAR1 maps GPU framebuffer memory for direct access by the CPU or PCIe peer devices. It exposes an access window onto device memory; it does not supply another physical memory pool for a model. A report listing 80 GiB of FB Total and 64 GiB of BAR1 Total therefore does not describe 144 GiB of physical GPU memory. Read each group's usage fields separately. ## Understand what the BAR1 window exposes NVIDIA's System Management Interface documentation describes framebuffer, or FB, as onboard device memory. Its BAR1 definition concerns mapping that memory for direct CPU access or access by third-party PCIe peers. The GPUDirect RDMA 13.4 guide describes PCI BARs as address windows. The memory reached through a window and the window's mapping resource answer different questions. Counting both as installed GPU memory treats an access mechanism as additional storage. A large aperture does not add HBM packages to the GPU. Its size also does not mean that each individual mapping covers the whole device. References: [N1](https://docs.nvidia.com/deploy/nvidia-smi/index.html), [N3](https://docs.nvidia.com/cuda/gpudirect-rdma/) ## Keep FB and BAR1 total, used and free separate FB Total, FB Used and FB Free concern framebuffer capacity and usage. The current documentation also names FB Reserved. BAR1 Total, BAR1 Used and BAR1 Free concern the separate mapping resource; they are not a second set of model-storage allocations. Retain the group name beside every value. A field labeled Free is ambiguous after its FB or BAR1 heading has been removed. The same applies to a summary that keeps two totals but relabels their sum as GPU memory. References: [N1](https://docs.nvidia.com/deploy/nvidia-smi/index.html), [N2](https://docs.nvidia.com/deploy/archive/R535/nvml-api/structnvmlBAR1Memory__t.html) ## Read a fictional 80 GiB framebuffer and 64 GiB BAR1 report Consider a wholly fictional report expressed in GiB. These invented values describe no named GPU, actual observation or supported aperture. They illustrate interpretation of supplied reporting fields. The framebuffer fields are FB Total: 80 GiB; FB Reserved: 2 GiB; FB Used: 74 GiB; and FB Free: 4 GiB. The mapping fields are BAR1 Total: 64 GiB; BAR1 Used: 1 GiB; and BAR1 Free: 63 GiB. The arithmetic 80 + 64 = 144 GiB is numerically correct, but 144 GiB is an invalid physical-GPU-memory capacity conclusion. The stipulated framebuffer total remains 80 GiB. The BAR1 line supplies no additional 64 GiB of physical memory for a model. The small BAR1 Used value also does not overturn FB Used: 74 GiB. It would be wrong to read BAR1 Free: 63 GiB as 63 GiB of free CUDA framebuffer, or to add 4 + 63 and report 67 GiB free for the application. The two Free values belong to different resources. This example makes no prediction about whether a model fits. The two groups do not identify which framebuffer regions are mapped or establish that a mapping spans the full device. References: [N1](https://docs.nvidia.com/deploy/nvidia-smi/index.html), [N2](https://docs.nvidia.com/deploy/archive/R535/nvml-api/structnvmlBAR1Memory__t.html) ## Preserve the reporting interface and its units NVIDIA's archived R535 NVML reference, last updated January 31, 2024, defines bar1Total as total BAR1 memory, bar1Used as allocated used memory and bar1Free as unallocated BAR1 memory. All three fields are in bytes. This is a dated API definition, not a specification for a current GPU's aperture. The fictional report above uses GiB throughout. Keep an actual report's units and any documented display conversion attached to its values. Renaming bytes as GiB, or silently mixing GB and GiB, introduces another error without resolving the resource distinction. For comparisons of exact GPU variants and published capacity, use Data Center GPUs by Memory Capacity. For an offer that adds host memory, use the CXL Memory Expansion guide. Those decisions need their own resource boundaries; neither is answered by adding BAR1 to FB. References: [N2](https://docs.nvidia.com/deploy/archive/R535/nvml-api/structnvmlBAR1Memory__t.html) ## A BAR1 entry does not verify a GPU-to-NIC path The mapping mechanism explains why BAR1 is relevant to direct access. It does not make the counter a certificate that a particular network adapter can exchange data with the GPU. A BAR1 amount identifies neither the peer device nor a completed transfer. NVIDIA's GPUDirect RDMA 13.4 guide describes topology and platform limitations, including implementations that can perform poorly or fail despite a shared PCIe root complex. The existing GPU Server PCIe Topology guide develops that configuration question. A BAR1 entry alone proves neither a working GPU-to-NIC path nor application transfer performance. This article interprets supplied fields. Actual software and platform support remain with the responsible OEM, device and software providers. References: [N3](https://docs.nvidia.com/cuda/gpudirect-rdma/) ## Carry the selected configuration into a physical assembly inquiry If a comparison sheet combines FB and BAR1, request a corrected description that retains both groups, their units and the identified complete-system configuration. That correction resolves the capacity claim; it supplies no reason by itself to change hardware or platform settings. When the selected system needs receiving, preparation or rack assembly, Leviathan's Rack Assembly & Preparation service and its project inquiry below provide the relevant physical next step. Share a nonconfidential summary of the supplied system, approved rack arrangement, factory-complete state, permitted remaining physical tasks and required handoff records. The inquiry concerns that equipment package; it does not purchase a Leviathan GPU-memory tuning service. ## Primary sources - [N1 — NVIDIA System Management Interface: FB Memory Usage and BAR1 Memory Usage](https://docs.nvidia.com/deploy/nvidia-smi/index.html). Checked 2026-10-20. Defines onboard framebuffer, BAR1 mapping for CPU or PCIe peer access, and the separately named reporting fields. - [N2 — NVIDIA NVML API Reference v535: nvmlBAR1Memory_t](https://docs.nvidia.com/deploy/archive/R535/nvml-api/structnvmlBAR1Memory__t.html). Checked 2026-10-20. Archived reference last updated January 31, 2024. Defines total, allocated and unallocated BAR1 amounts in bytes; useful for interpreting this API's fields. - [N3 — NVIDIA GPUDirect RDMA 13.4: How GPUDirect RDMA Works and Supported Systems](https://docs.nvidia.com/cuda/gpudirect-rdma/). Checked 2026-10-20. Explains PCI BAR address windows and topology/platform limitations. A counter does not establish support or measured performance for a particular GPU-to-NIC implementation. ## Related Leviathan resources - [Data Center GPUs by Memory Capacity: Compare the Exact Variant](/articles/data-center-gpu-memory-capacity-comparison) - [CXL Memory Expansion: Which Memory Does the GPU Server Offer Actually Add?](/articles/cxl-host-memory-expansion-gpu-hbm-boundary) - [GPU Server PCIe Topology: Why Slot Count Does Not Prove GPUDirect RDMA](/articles/gpu-server-pcie-topology-gpudirect-rdma) - [Rack Assembly & Preparation for the selected configuration](/services/gpu-assembly) - [Discuss the physical receiving, preparation or rack-build package](/contact?service=gpu-assembly&from=%2Farticles%2Fgpu-bar1-mapping-versus-frame-buffer-memory) ## Have a physical receiving or rack-build package to scope? Share the selected complete-system configuration, supplied equipment, approved rack arrangement and permitted physical tasks so we can discuss preparation, assembly and handoff records. [Discuss the scope](/contact?service=gpu-assembly&from=/articles/gpu-bar1-mapping-versus-frame-buffer-memory)