Release 0.4.0 (including backfilling CHANGELOG.md).

[eddyb]

Opening as draft and only changing CHANGELOG.md because there's some release automation.

(EDIT: release already done, this PR just needs to merge the 0.4.0 tag into main)

For the record, this is what I used for this release (same as previous SPIR-T releases):

VERSION=0.4.0 bash -c 'cargo release $VERSION -x && sed -i -E "s|/tree/$VERSION||" Cargo.toml && git commit -m "Undo \`$VERSION\` \`package.repository\` change in \`Cargo.toml\`." -- Cargo.toml'

[eddyb]

@Rust-GPU/rust-gpu-maintainers This is what I am most worried about.
_{(most of the other additions are about all the changes that landed together in #2, which I'm glad I was able to summarize, but are not super critical - tho feel free to comment on them as well, ofc)}

You can preview the rendered CHANGELOG to see what it will look like.

Here it might be less important, but I hope we can come up with something like this for the rust-gpu repo as well.

I've also considered changing all the PR#123 below this point to say "PR_Embark" or otherwise indicate the distinction, but that felt overkill.

[LegNeato]

I wouldn't overthink it, this looks fine to me.

[Firestar99]

Suggestion: Include the repository transition notice at the very top so it's the first thing you see, and note that all PRs >40 are from embark's repo and everything <40 is from this repo. I think that's easy enough to understand and immediately visible by the amount of digits, especially in the rust-gpu repo where embark got to >1000 PRs.
As an example see current rust-gpu main (ignore the breaking change notice, that hasn't been removed yet, will be in one of my PRs)
Also you don't have to write two changelogs or copy the splitter multiple times, if we had embark and rust-gpu PRs in the same category.

[LegNeato]

Ideally we will have over 40 PRs eventually though...

[Firestar99]

But not for this release, right? I would have just added the notice to this particular release, as any further releases would obviously be PRs from this repo, so no need to warn users about it.

[LegNeato]

Yeah, sure. Again, I don't think this matters one way or another as the only consumer of spir-t is rust-gpu ha.

[LegNeato]

Fwiw chatgpt does a decent job writing these (though a bit verbose);

SPIRV-Headers Updated to Vulkan SDK 1.3.290 (PR #4)

Rust-GPU now supports Vulkan SDK 1.3.290, keeping shaders compatible with the latest GPU hardware and features.

Control Flow Restructuring Fixes (PR #2)

OpPhi Chain Fix

Corrects how chains of OpPhi instructions are rewritten, improving SSA handling in complex control flows.

Isolating Control Regions

Unstructured control flow graphs are isolated, with explicit value propagation across edges, preventing accidental value visibility.

Optimizing Redundant Dataflow

Removes unnecessary data propagation in sound restructuring, resulting in more efficient execution.

SSA Dominance Fixes

Fixes earlier SSA dominance issues, optimizing control flow and reducing redundant operations.

ExitInvocations Support (PR #2)

Introduces support for terminators like OpKill and OpEmitMeshTasksEXT, enabling proper task termination. Allows panic!() for task exits from an entry-point.

Divergent Control Flow Optimization (PR #2)

Optimizes divergent control flow. Simple cases like:

if cond { panic!() } else { foo() }

are flattened to:

if cond { panic!() } else {}
foo();

For complex cases like:

if cond1 {
    if cond2 { panic!() } else { task1() }
} else {
    if cond3 { task2() } else { panic!() }
}
task3();

the optimization flattens it to:

if cond1 && cond2 { panic!(); }
else if cond1 { task1(); }
else if cond3 { task2(); }
else { panic!(); }
task3();

This reduces branching and minimizes thread divergence, boosting performance in complex shaders.

[eddyb]

@LegNeato huh, what did you even use as an input for those? (sorry, I see it now, the format really threw me off)
Were you thinking CHANGELOG -> release notes? That's not a concern for SPIR-T because SPIR-T releases haven't had "release notes" so far.

For Rust-GPU it wouldn't really work either since the content has to be more user-facing (comparable to Rust release blog posts that contain "feature highlights" - Rust also has a dry CHANGELOG file, which lacks those IIRC).

[LegNeato]

I was more curious what it would come up with and just dropped it in in case you liked any of the wording more.