Revise partial_bindless release note#24506
Conversation
alice-i-cecile
added
C-Docs
amtep
left a comment
amtep
left a comment
There was a problem hiding this comment.
Looks great.
It's not just a revision — it's an improvement in readability.
Release notes must constantly navigate real tension between advertising new features and sounding too promotional — often at the cost of clarity — but these changes perform admirably.
|
Why does this emphasize it's an improvement for Metal? Doesn't DX12 also support TEXTURE_BINDING_ARRAY but not BUFFER_BINDING_ARRAY? https://docs.rs/wgpu/latest/wgpu/struct.FeaturesWGPU.html#associatedconstant.BUFFER_BINDING_ARRAY |
alice-i-cecile
added
S-Needs-Help
alice-i-cecile
added
S-Needs-Review
| Metal (Apple's GPU API) supports texture binding arrays but not buffer binding arrays. | ||
| Bevy required both to enable bindless, which previously excluded Metal entirely — even for materials that never use buffer arrays. | ||
| If you were shipping on Mac or iOS, your game was running on a slower, fundamentally different code path. | ||
| Both Metal (Apple's GPU API) and DX12 (an older Windows API) have partial bindless support: |
There was a problem hiding this comment.
dx12 is also a modern api
| Both Metal (Apple's GPU API) and DX12 (an older Windows API) have partial bindless support: | |
| Both Metal (Apple's GPU API) and DX12 (a Windows graphics API) have partial bindless support: |
| The sampler limit check was testing the wrong metric: `max_samplers_per_shader_stage` counts binding slots, but the relevant limit is `max_binding_array_sampler_elements_per_shader_stage`, the array element count — a mismatch that could silently exceed hardware limits. | ||
| Bevy now also skips creating binding array slots for resource types a material doesn't use, staying within Metal's hard 31 argument buffer slot limit and reducing overhead on all platforms. | ||
| We've also fixed two important correctness bugs in the process. | ||
| First, we discovered that the sampler limit check was testing the wrong metric: `max_samplers_per_shader_stage` counts binding slots, but the relevant limit is `max_binding_array_sampler_elements_per_shader_stage`, the array element count (a mismatch that could silently exceed hardware limits). |
There was a problem hiding this comment.
Seems max_binding_array_sampler_elements_per_shader_stage is larger than max_samplers_per_shader_stage so it's unlikely to exceed.
| First, we discovered that the sampler limit check was testing the wrong metric: `max_samplers_per_shader_stage` counts binding slots, but the relevant limit is `max_binding_array_sampler_elements_per_shader_stage`, the array element count (a mismatch that could silently exceed hardware limits). | |
| First, we discovered that the sampler limit check was testing the wrong metric: `max_samplers_per_shader_stage` counts binding slots, but the relevant limit is `max_binding_array_sampler_elements_per_shader_stage`, the array element count (a mismatch that could incorrectly disable bindless). |
| Most materials, including `StandardMaterial`, do not need buffer array support. | ||
| To ensure those materials take the fast path, Bevy now checks the actual needs of each material. | ||
| If you only need texture arrays, your material can be rendered efficiently across Bevy's desktop platforms. | ||
| If you use `#[uniform(..., binding_array(...))]`, expect unusually poor performance when using Metal or DX12. |
There was a problem hiding this comment.
I feel "poor performance" is a bit too harsh.
tbillington
left a comment
tbillington
left a comment
There was a problem hiding this comment.
sorry for the hassle, I do think this reads better now though!
| Windows, Mac, Linux, mobile — with confidence that it will just work. | ||
| That's a tough promise to live up to: rendering complex scenes on Mac and iOS was markedly slower. | ||
| In an ideal world, Bevy users could write a single application and ship it everywhere, with every last one of the messy cross-platform differences beautifully abstracted away. | ||
| That can be a bit hard though. |
There was a problem hiding this comment.
could probably omit this sentence, it doesn't really do anything imo
| In this particular case, we found that rendering complex scenes on Mac and iOS was markedly slower than it should have been. | ||
|
|
||
| Looking into it, the lack of bindless rendering support was to blame. |
There was a problem hiding this comment.
these are fine, but feels a little handwavey? like "we found" and "looking into it" just feel wishywashy haha
it would come across stronger if there was more concrete background like "In previous versions of Bevy user reports and benchmarks of complex scenes on mac and iOS showed much worse performance than other platforms. After investigation of the graphics pipeline used we found that it wasn't taking advantage of bindless rendering where it could." (continues into line 12)
5 participants
Objective
Tone was too insincere marketing, and it used LLM-standard constructions.
While this was hand-written, the register drifted into marketing — complete with em-dash asides and "it's not X; it's Y".
Solution
Rewrite it, tightening the phrasing and cutting out some connective material. Mourn the loss of my precious — and accept that the fight is a lost cause.
Add a proper conclusion while we're here.