You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Flutter GPU] Reusable binding sets so per-draw bind cost stops scaling with binding count #190397
There is no way to express "these textures and uniform buffers are a set I will bind repeatedly". Every draw re-binds every resource individually, so per-draw work is O(bindings) by construction, even after the name marshalling in #189819 and the per-binding allocations in #190396 are fixed.
Other HALs hoist this out of the draw loop. WebGPU builds a GPUBindGroup once and binds it in O(1). SDL_GPU binds arrays by index, one call per stage. Both amortize descriptor assembly across draws; flutter_gpu repeats it per draw.
This costs most where flutter_gpu should be strongest. A renderer drawing one material across many nodes rebinds an identical resource set thousands of times per frame.
API sketch
final bindings = gpuContext.createBindingSet(shader, {
'FrameInfo': frameInfo,
'base_color_texture': (albedo, sampler),
});
pass.bindSet(bindings); // O(1), no per-resource work
pass.draw(vertexCount);
A set is immutable and validated once against the shader's reflection at creation, so the per-bind name lookup disappears for its members as well.
Backwards compatibility
Adding bindSet alongside the existing per-resource binds is source compatible, but it keeps the per-draw replay path alive and makes Draw merge two binding sources, which is where the cost currently lives.
Replacing bindUniform and bindTexture outright is breaking, and is probably the better trade. The migration is mechanical, and the API is still in preview.
Activity
[Flutter GPU] Reusable binding sets (flutter#190400)