Skip to content

Conversation

@Nielsbishere
Copy link
Contributor

This change introduces a new compiler option, -keep-all-resources, which ensures that even optimized-out resources are retained in DXIL reflection.

Motivation

By default, unused resources are removed during optimization, and applications may rely on their absence to infer optimization opportunities (e.g., skipping transitions). However, sometimes when reflection completeness is important (e.g., tools, debugging, visual scripting, or consistency with SPIR-V -Od) it is desirable to keep all declared resources visible in reflection, regardless of usage.

Behavior

When enabled, unused resources are not fully removed.
They will appear in reflection but will not generate createHandle instructions.

Notes

This is not enabled by default to avoid DXIL bloat and to prevent breaking apps that assume missing resources imply optimization.
Conflicts with #7729.
Step 2/2 to solve #5105.

…lection. This isn't default to avoid DXIL bloat and because apps might assume that if a resource is missing that it's optimized out and use this info to avoid transitions or other optimizations. When a resource is unused but still present, it won't emit a createHandle, but the reflection info will still be there
@github-actions
Copy link
Contributor

github-actions bot commented Sep 4, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

…this pc has a bit of trouble to get the tests to run, switching to my other pc first to verify
…ll resources should keep it in the runtime data, but remove them from functions that don't use them
@Nielsbishere
Copy link
Contributor Author

Okay, now that I've sacrificed a couple of goats, I've been able to get the HLSL tests to run. Fixed a little issue in my test. Runs fine now.
I'm sure I don't have permission to get azure to run the pipelines, but I'll try it anyways

@Nielsbishere
Copy link
Contributor Author

/AzurePipelines run

@azure-pipelines
Copy link

Commenter does not have sufficient privileges for PR 7734 in repo microsoft/DirectXShaderCompiler

@Nielsbishere
Copy link
Contributor Author

Nielsbishere commented Nov 5, 2025

Actually it turns out this is quite a bit more complicated than it first seems.
Keeping the resource around doesn't actually mean that it's accessible from reflection. Due to DCE, the register disappears from the function(s) it is used in (create handle) and that's what is used to determine if the resource is 'bound' or not. Keeping the resource around doesn't change that, if the create handle is gone (from my understanding). The DXIL output will see these registers without symbols just fine, but won't be exposed there in reflection. I'll need to think about it a little bit to think of the right solution...

…istent bindings it actually affects behavior in reflection, so it needs to be persistent. Added DxilModule::RemoveEmptyBuffers to handle removal of empty $Globals buffer. Added a proper test to check for optimized out registers with the correct flag or non optimized out registers.
…ag added to DxilResourceBase; m_IsUnused. This is packed in the highest bit of the id stored to disk. This is used so that ID3D12ShaderReflection can also figure out if something is really unused. This means that ID3D12LibraryReflection could technically figure out two things if we wanted to; if a register is unused top level (so in all functions) and if a register is unused for a specific function. For ID3D12LibraryReflection it's just kept function local and for ID3D12ShaderReflection it's kept global. Added unit test for ID3D12ShaderReflection.
…ing a register. Fixed a wrong scope creating multiple functions of the same type by accident.
…ilShaderFlags instead. This is because 'keep-all' from the other PR relies on this Enum to be serialized; because reflection needs to know if unused resources are preserved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

2 participants