fix(vk): coloured specks on fallback foliage (AMD): the generated vertex stage's outputs start at (0,0,0,1) #1513
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!1513
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mesh-fallback-colour-specks-vertex-defaults"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The mesh fallback's generated vertex stage left output components undefined when the mesh program doesn't write them. On AMD's Windows driver the fragment stage read register garbage: coloured specks in Kokiri Forest's bushes. This starts them at (0,0,0,1), as the native mesh stage's outputs do since
6dcf6f1.Part of splitting up #1023.
Change
Every output generic starts at (0,0,0,1), and the point size at 1, before the record's lines are stored over them. This matches the native mesh stage (
6dcf6f1) and a vertex stage's unwritten components.Risk
It changes every fallback program's SPIR-V, so GPUs without mesh shaders re-translate once on their first start. GPUs with mesh shaders are unaffected.
Tests
tests/test_mesh_fallback.pychecks the defaults. The check fails on main without this change.Tested on
Looks good. The default stores mirror StoreFallbackOutput's addressing (single-component vs access chain with element - first_element), they run before the record's stores so real values still win, and (0,0,0,1) / point size 1 match the native mesh stage. CI is green.
Nit: the test is a source-string match, so it'd break on a harmless reformat of that line, but that is how the rest of test_mesh_fallback.py works.