Skip to content

Conversation

@tangent-vector
Copy link
Contributor

There's a lot of cruft in slang.h and the slangc command-line options that was never really meant to be used, and a lot of other cruft that we knew was a liability from the moment it landed. This is a proposal to mark as much stuff deprecated as currently seems possible, with the hope that over time we can clean up the implementation by not needing to support too many legacy features and in-retrospect-poor design choices.

There's a lot of cruft in `slang.h` and the `slangc` command-line options that was never really meant to be used, and a lot of other cruft that we knew was a liability from the moment it landed.
This is a proposal to mark as much stuff deprecated as currently seems possible, with the hope that over time we can clean up the implementation by not needing to support too many legacy features and in-retrospect-poor design choices.
tangent-vector added a commit to tangent-vector/slang that referenced this pull request Jul 31, 2025
This is intended to be the implementation PR for shader-slang/spec#31
tangent-vector added a commit to tangent-vector/slang that referenced this pull request Jul 31, 2025
This is intended to be the implementation PR for shader-slang/spec#31
csyonghe added a commit to csyonghe/spec that referenced this pull request Aug 4, 2025
csyonghe pushed a commit to csyonghe/spec that referenced this pull request Aug 4, 2025
Comment on lines +169 to +172
* option `-source-embed-style` should be deprecated

* option `-source-embed-name` should be deprecated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am actively using these options, they're useful for small applications that want to embed SPIR-V in the executable so that they don't need to care about a filesystem. They also mirror equivalent glslc / glslang functionality, making slangc a drop-in replacement in an existing CMake shader compilation setup.

I have no issues with the other deprecations listed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm also not the only person using this functionality, here's someone recently on Discord asking how to do exactly what these options do: https://discord.com/channels/1303735196696445038/1397550571321299006

@swoods-nv
Copy link
Contributor

Tagging @danginsburg for input and awareness as well

@danginsburg
Copy link

Tagging @danginsburg for input and awareness as well

The only ones that would impact our usage are:

  • ICompileRequest - we are still using this deprecated interface, but this is just that I haven't gotten around to moving to the new API. I don't anticipate that it should be an issue.
  • -enable-effect-annotations - we do need this for our shaders since we store a bunch of metadata that is read by our material compiler and material editor in annotations. I'd have to write a prepass if it was fully removed. As long as it remains but is marked deprecated it's fine.
  • -fspv-reflect - this one we needed to be able to do ByteAddressBuffer reflection post DCE to find out which members were referenced, see: Feature request: reflect referenced members of a ByteAddressBuffer KhronosGroup/SPIRV-Reflect#234. I think this is one we would really have a difficult time dealing with if it went away, I'm not sure how we could workaround it unless the slang reflection API could provide the info.


* option `-msvc-style-bitfield-packing` should be marked as undesirable (and subject to future deprecation/removal)

* option `-fspv-reflect` should be marked as undesirable (and subject to future deprecation/removal)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn’t this required to support Khronos’s SPIRV reflection library? https://github.com/KhronosGroup/SPIRV-Reflect if I understand right, then IIRC Valve was a proponent that we support SPIRV-Reflect decorators.

If this is true, then I’d probably object to removing this command line argument.


* option `-reflection-json` should be marked as undesirable (and subject to future deprecation/removal)

* option `-msvc-style-bitfield-packing` should be marked as undesirable (and subject to future deprecation/removal)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There may be a need for the functionality this option provides, it was brought up in this issue: shader-slang/slang#8112


* `ISlangWriter`

* The ability for users to override the "prelude" code for particular target languages and/or downstream compilers
Copy link

@CrossVR CrossVR Sep 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are currently using a custom build of Slang that uses our own C++ prelude in addition to some other changes. This feature could be a potentially useful way for us to use the official build of Slang.

Our intention is to contribute our changes back, but some of our prelude changes rely on a LLVM compiler plugin so I'm not sure if all our prelude changes will make it in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants