Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

RFC: link-time capabilities

Aberta
  • Algo errado?
#388 0 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
rust
Domínio
compilers

Direção de pesquisa

Comece lendo a issue sobre Large Integer polyfills (#307) e, em seguida, rastreie como spirv-builder declara atualmente as capabilities e como a crate final do shader é compilada. Compare as abordagens propostas por entry point, por crate e com feature gating. O trabalho estará concluído quando houver um design definido e um plano de implementação para reutilizar crates compiladas enquanto variantes com capabilities diferentes são vinculadas.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

RFC

Link-time capabilities are capabilities that are not exposed to codegen, but only set at link time. Importantly, changing link-time capabilities does not require a clean recompile, unlike the current spirv capabilities.

I good first experiment ground would likely be Large Integer polyfills, which I think they are better suited at link time. A really common use-case would likely be to emit one shader module with Int64 Capabilitiy enabled, and another with u32 polyfill for all u64 integers. So implementing this at link time would allow you to compile the shader crate only once and link it twice.

There's a few variants I could imagine to specify these link-time capabilities:

  • per entry point in the #[spirv(capability(polyfill_u64))], mapping well with multimodule
  • per shader crate using #![spirv(capability(polyfill_u64))] at root level, mapping well to single module
  • some new system that allows specifying how entry points are grouped, potentially allowing entry points to be emitted in a variety of modules with different link-time capabilities. Maybe not with the first implementation.

Importantly, this should work well with rust features, so you can #[cfg_attr(feature = "u64_emulation", spirv(capability(polyfill_u64)))] and compile only the final shader crate twice, while reusing the remaining compiled crate tree.

I could also see a similar system being employed for usual spirv capabilities in the future, replacing the current pre-declaration of used features in spirv-builder. Similarly to the zombie system, you could attach an OpCapability to a certain instruction. If that instruction is linked into a shader module, add the OpCapability to it. But if it's unused, DCE will kill the instruction thus the capability.

This reverses how you'd enable code that depends on some capability: Currently, you'd declare the capability in spirv-builder and have a #[cfg(target_feature = "")] in your code. With link-time capabilities, you use a normal rust feature like #[cfg(feature = "")]to gate your code requiring some capability, and if the end user enables that feature, it implicitly enables the required capability. The final shader crate binary can itself have features enabled though spirv-builder, that enable features of any such library gating required capabilities like you'd normally do in Cargo.toml.

Linguagem predominante
Rust
Estrelas
3.4k
Forks
132
Merge médio
1d 58min
PRs com merge (30d)
12

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Rust-GPU/rust-gpu

Todas as issues de Rust-GPU/rust-gpu

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.