Skip to content

Conversation

jamienicol
Copy link
Contributor

@jamienicol jamienicol commented Sep 16, 2025

Connections
Precursor for Vulkan External texture support- part of #4386

Description
External textures require lowering a single binding resource into multiple bindings in the backend. The way we currently create bind group layouts and bind groups in the vulkan backend makes this difficult, so the first patch here is a refactoring which will make this easier. Secondly, this will require remapping the binding indices, so this adds a binding map like we have in other naga backends.

Testing
This shouldn't cause any changes in behaviour (other than using different binding indices in some cases). So the existing tests passing is enough

Squash or Rebase?
Rebase

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.

@jamienicol jamienicol force-pushed the vulkan-remap-bindings branch from 3dd3691 to 27f32dc Compare September 18, 2025 11:25
Copy link
Member

@teoxoy teoxoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

…nd groups, rather than list of vk::DescriptorType

This is a refactoring of Vulkan BindGroupLayout and BindGroup creation
in preparation for implementing external texture support.

Currently when creating a BindGroupLayout the Vulkan backend creates a
list of the vk::DescriptorType for each entry, as well as the count, for
binding arrays. Then when creating the BindGroup, it iterates through
this list and does whatever it needs to do for each entry based on these
values.

In order to support external textures, we will have to create multiple
descriptors for each BindingType::ExternalTexture. This means we cannot
map each binding type to a single Vulkan descriptor type. Instead, store
the list of BindGroupLayoutEntries on the BindGroupLayout and use those
when creating the BindGroup, using the same "layout_and_entry_iter"
idiom used by other backends. In subsequent patches this will allow us
to create multiple descriptors for a single resource binding.
In order to support external textures, we must be able to map a single
external texture resource binding to multiple Vulkan descriptors. This
means we must be able to override the `Binding` and `DescriptorSet`
values for global variables when generating SPIR-V, rather than simply
passing through the group and binding values from Naga IR.

This patch extends the existing SPIR-V Naga backend's `BindingMap` to
contain a descriptor set and binding value in addition to the existing
array size. When creating BindGroupLayouts/BindGroups we use a
sequentially incrementing value for each entry's binding value,
continuing to just use the bind group index as the descriptor set
value.

The Naga backend looks up each resource in the map when emitting its
`Binding` and `DescriptorSet` decorations. If the entry cannot be
found in the map, it will either error or emit fake bindings based on
its configuration.
@teoxoy teoxoy force-pushed the vulkan-remap-bindings branch from 27f32dc to 8a93a2f Compare September 24, 2025 15:44
@teoxoy teoxoy enabled auto-merge (rebase) September 24, 2025 15:44
@teoxoy teoxoy merged commit ba0b6b9 into gfx-rs:trunk Sep 24, 2025
41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants