EmbarkStudios / rust-gpu

🐉 Making Rust a first-class language and ecosystem for GPU shaders 🚧

Home Page:https://shader.rs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow keeping linkage annotation

SiebenCorgie opened this issue · comments

SpirV allows defining import and export [0] for linking separate Shader modules [1] post compilation.

Apparently SpirV linking is already used within rust-gpu, but not exposed. Therefore we can't use extern "C" as we usually would.

This functionality would be useful, for instance when building shader permutation systems.

The enhancement would basically be allowing extern C, #[no_mangle] etc. to map to (possibly named) import/export decorated values whenever the Linkage capability on spirv-builder is enabled.

Note that extern "C" exports in Rust only affect ABI.
#[no_mangle] + #[export_name = "..."] is how you control symbol names for exports.

Anyway, Linkage is really the only prerequisite, we remove our annotations today because it's not really supported anywhere I can think of. This is the relevant code:

// NOTE(eddyb) `Options`'s `keep_link_export`s field requests that `Export`s
// are left in (primarily for unit testing - see also its doc comment).
let mut kept_any_linkage_decorations = false;
module.annotations.retain(|inst| {
!(inst.class.opcode == Op::Decorate
&& inst.operands[1].unwrap_decoration() == Decoration::LinkageAttributes
&& match inst.operands[3].unwrap_linkage_type() {
LinkageType::Export if opts.keep_link_exports => {
kept_any_linkage_decorations = true;
false
}
_ => true,
})
});

Oh, right, that's kind of funny, there's already a keep_link_exports meant for testing.

You'll have to be careful tho, to not search for the Capability::Linkage in the SPIR-V Module (since it sounds like that one is always present, in the interest of keeping the module valid?), but rather determine "did the user ask for the Linkage capability" from however target_features (from Session) turn into capabilities.