Add bindless support back to ExtendedMaterial.

[pcwalton]

PR #17898 disabled bindless support for ExtendedMaterial. This commit adds it back. It also adds a new example, extended_material_bindless, showing how to use it.

[robtfm]

the core of the implementation looks good. i think there's potential to make it a bit less confusing for users, but i'm not certain (i had to get up to speed with the base bindless implementation along the way).

[robtfm]

i found this very hard to understand. i think the base of my confusion is that i couldn't see why we need to specify unique table indices for each item of data (the "50..53").

i think (please correct me if i'm wrong) it's for non-bindless fallback. if that's the case, then in non-bindless the uniform will be @binding(50), and in bindless @binding(101), right? it's a bit confusing, i think it would be better to use 101..=103 for example purposes, so at least the uniform is the same.

then ... if we are already specifying the uniform slot, and the individual slots for each item of data with #[texture(x)] etc, why do we need to specify the table range here at all? is there a reason to want some fields bindless and others not?

this would also bring the binding-conflict requirements to the same thing for bindless and non-bindless, which would be a bit easier to think about.

[pcwalton]

i found this very hard to understand. i think the base of my confusion is that i couldn't see why we need to specify unique table indices for each item of data (the "50..53").

The table indices point to the slot reserved for each texture in each binding buffer. The shader accesses a texture called base_color with code like bindless_textures_2d[table.base_color[material_index]].

then ... if we are already specifying the uniform slot, and the individual slots for each item of data with #[texture(x)] etc, why do we need to specify the table range here at all? is there a reason to want some fields bindless and others not?

One reason is that the table entries are contiguous in memory, so you might want them to be smaller than the binding numbers to avoid wasting space in the table with unused bindings.

then ... if we are already specifying the uniform slot, and the individual slots for each item of data with #[texture(x)] etc, why do we need to specify the table range here at all? is there a reason to want some fields bindless and others not?

If you know you're deploying on a platform with no bindless, you might want ExtendedMaterial to not use bindless to avoid the verbosity.

[robtfm]

the table indices need to be unique over the whole material, right? and bindless will only be used if all the base materials in the type stack are bindless-enabled too.

so the uniqueness requirement for the table indices is precisely the same requirement as for the slot indices in non-bindless fallback?

so if you can do better by using lower table indices, you can also just use lower slot assignments.

[pcwalton]

Actually sorry, my explanation before was wrong. There are two tables for a bindless ExtendedMaterial: one for the base and one for the extension. This is necessary because pbr_input_from_standard_material will read from material_indices, an array of StandardMaterialBindings in pbr_bindings.wgsl. The StandardMaterialBindings have a hard-coded size. If we tried to place the standard material bindings and the extended material bindings in the same array, then the size of each element of pbr_bindings::material_bindings would be wrong, and you'd get a corrupted shader.

So the reason why we need the 50..53 bit is that we have to specify which bindings go into the second table. The indices are mapped starting at 0. So binding 50 gets mapped to struct field 0, binding 51 gets mapped to struct field 1, etc.

[robtfm]

sorry but i still don't get why they need to be manually specified.

if you're comfortable i'm just missing the point then i guess i recuse myself

[pcwalton]

Now that I think about it, we might actually not need this PR to support manually specifying the size. But we would want it for #18104 because in that case we want to specify the size of the table to be 0..31, regardless of whether the feature that enables the 30th binding is enabled.

[pcwalton]

That would be PR #18771 if you want to see an example of where we need the range field.

[pcwalton]

Updated to main and fixed an issue with the bindless index table sizes.

[BenjaminBrienen]

2025-04-06T19:38:17.754020Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (Pop!_OS 22.04)", kernel: "6.12.10-76061203-generic", cpu: "AMD Ryzen 9 7950X 16-Core Processor", core_count: "16", memory: "61.9 GiB" }    
2025-04-06T19:38:17.900941Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 3070", vendor: 4318, device: 9348, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "565.77", backend: Vulkan }
2025-04-06T19:38:18.471014Z  INFO bevy_winit::system: Creating new window extended_material_bindless (0v1)
2025-04-06T19:38:18.471114Z  INFO winit::platform_impl::linux::x11::window: Guessed window scale factor: 2
2025-04-06T19:38:18.728560Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'
2025-04-06T19:38:18.754750Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'
2025-04-06T19:38:36.461479Z  INFO bevy_window::system: No windows are open, exiting    
2025-04-06T19:38:36.462640Z  INFO bevy_winit::system: Closing window 0v1

[pcwalton]

I switched the texture to the UV checkerboard pattern. Now the example looks significantly less ugly.

[cart]

The level of complexity this foists on users is pretty gnarly (both here and in shaders). Getting these indices right feels like "unnecessary implementation details".

It definitely feels like its time to start building a higher level system that abstracts over data binding and access, removing the need for developers to handle it manually. It would be very nice if "bindless" was automatic and transparent on both the rust side and the shader side (at least by default).

As a shader developer just trying to be creative (ex: I'm working on a water system in a side project at the moment), and as someone not intimately familiar with the bindless impl (which will be the majority of our shader authors), I see this complexity and think "I'll pass and eat the overhead".

[pcwalton]

I don't like it any more than you do :) And I agree. We discussed some ideas for improvement on Discord.