Repository navigation
Support binding larger buffer ranges >2GB to shaders #6338
Description
Hi,
I'd like to request support for binding buffer sizes in the 64bit range.
That currently seems to be constrained to 2GB.
A Dawn team member has advised me that this is a spec issue; see this Chromium issue. I haven't been able to pinpoint the constraint in the spec myself, but I am also not very familiar with it.
Related work that has already landed:
Related issues:
Reacted by Markus Schütz
Activity
m-schuetz commentedon Jul 15, 2026
This would be really nice to have, especially in the absence of bindless buffers and BDA.
[-]Support larger buffer sizes[/-][+]Support binding larger buffer ranges >2GB to shaders[/+]kainino0x commentedon Jul 15, 2026
According to this, it's larger buffer binding ranges that is a spec issue. There's no spec issue with larger GPUBuffer allocations, but you can't use it all in one shader invocation.
Is that what you need? And how big do you need? 4GB (unsigned 32-bit index)? More than 4GB (64-bit index)?
ColoredCarrot commentedon Jul 17, 2026
Ah, my bad; on all the machines I had tested,
maxBufferSizestill seemed to be hard-capped at 2GB in Chromium, but digging further, I did find some references online for a 4GB limit. I'll clarify on the Chromium side.In any case, yes, please consider this a request for binding ranges in 64‑bit space (so > 4GB).
(Though if you think it would be better to pursue <=4GB first, that would already be a major improvement as well!)
jimblandy commentedon Jul 22, 2026
I think hardware support for 64-bit indices is very sparse, so although we could add support to the spec, the devices that could use it would be rare.
abgnydn commentedon Aug 14, 2026
One sizing data point, since the question was how big.
I run a browser workload with about 15.7 GB of resident GPU buffers, a 35B sparse MoE (Qwen3.6-35B-A3B, experts at 3-bit). Its largest bindings are the embedding and the untied lm_head, byte-identical at 254,279,680 B each (248320 x 2048, 4-bit); the per-layer expert stacks are about 101 MB each. Binding range is not what constrains this workload, buffer count is. That is one architecture and MoE weights shard per layer, so it may not generalise. A single large KV or activation buffer would look different.
On the 2 GB and 4 GB values in the thread: on an M2 Max, Chrome 151 reports 4294967292 for both
maxBufferSizeandmaxStorageBufferBindingSize, which is the topLimits.cpptier of 4 GiB - 4. Requesting one byte more fails with aGPUValidationErrorrather than clamping. Dawn's Metal backend computesUINT32_MAXbefore tiering and says why:So for the <=4 GB option specifically, the Metal ceiling is a Dawn
u32rather than a device property. That does not bear on 64-bit indices, where the hardware-support point stands.On the 2 GB figure specifically, it may not have been a misreading. Dawn's D3D12 backend sets
maxBufferSizetokAssumedMaxBufferSize, which is exactly 2 GiB, unconditionally on every device: "D3D12 has no documented limit on the buffer size" and "Use 2 GB when the limit is unavailable". So on Windows a 2 GBmaxBufferSizeis what every adapter reports regardless of hardware. Separately, and on the binding-size axis rather than the allocation one, Dawn's Vulkan backend clampsmaxStorageBufferBindingSizeto 2 GiB - 4 on NVIDIA deliberately, citing crbug.com/435684920.One thing this workload does hit, which is not this issue: allocations well above physical memory succeed on macOS because it swaps, and there is no way to detect that in advance. That is the gap in #5505.
abgnydn commentedon Aug 14, 2026
Adding a cross-vendor reading, since everything above was one Mac.
NVIDIA Tesla T4 (Turing), Linux, headless Chrome 148, via Vulkan:
maxBufferSize4294967292,maxStorageBufferBindingSize2147483644. The second is 2 GiB - 4, which is the NVIDIA clamp above, measured rather than read from source.The 2 GiB
maxBufferSizeis also not D3D12-specific. The Vulkan, D3D11, D3D12 and OpenGL backends all assignkAssumedMaxBufferSizeto it.On the hardware question: Dawn's D3D12 backend sets
maxStorageBufferBindingSizeto 256 MiB on Qualcomm parts below Adreno 8xx, commented "Due to hardware limitation, Raw Buffers can only address 2^28 bytes instead of the guaranteed 2^31 bytes." That is a real device ceiling four orders of magnitude below 4 GiB, which seems relevant to how widely a larger range could be relied on.