2026-04-30 - HLSL Working Group Minutes
- Discussion topics
- Constant Buffer Discussions
- No Resource buffers in constant buffer
- Add const? We have to allow calls to non-const.
- 202y we migrate. Use clang-tidy to only allow calls to const
- Discuss SPIR-V Validator (spirv-val) failures and resolutions:
- https://github.com/llvm/llvm-project/issues/194435 (VUID-StandaloneSpirv-None-04667) OpTypeStruct must not contain an opaque type
- https://github.com/llvm/llvm-project/issues/194432 (VUID-StandaloneSpirv-Location-04916) Location anonotations
- https://github.com/llvm/llvm-project/issues/194293 (VUID-StandaloneSpirv-Flat-04744) Flat anonotations
- Matrix Layout Keywords Proposal Update:
- @farzonl wants to add a new AttributedType for Matrix Layout Keywords to eliminate all walking to find Decls (per-call-site discovery).
- Every existing call site already has a QualType so this becomes an easy lookup on the type
- Constant Buffer Discussions
Meeting notes:
Flat Annotation Handling in HLSL and SPIR-V:
Steven, Farzon, Chris, Justin, and Tex discussed the implementation of flat annotations, focusing on whether to handle them in the Clang frontend or the SPIR-V backend, and explored the complexities of per-vertex attributes and compatibility with DXC.
- Frontend Versus Backend Implementation: Steven raised concerns about adding flat annotations in the SPIR-V backend due to HLSL rules, suggesting that Clang should handle cases where no interpolation is required. Farzon noted Chris’s advice to consider the backend for simplicity, but Steven and Justin agreed that frontend handling is necessary to avoid duplication.
- Per-Vertex Attribute Representation: The group discussed the challenge of representing per-vertex attributes, with Tex identifying the ‘getAttributeAtVertex’ function. Chris and Tex suggested redesigning the HLSL exposure for these attributes, proposing a special type in the type system to track associated attributes throughout the pipeline.
- Compatibility and Redesign Considerations: Chris and Tex expressed openness to breaking compatibility with DXC for improved handling of per-vertex attributes, noting that DXC’s current behavior is ‘magic’ and may not be desirable to carry forward. Steven emphasized that the chosen implementation affects shader input representation and flat decoration handling.
- Immediate and Long-Term Solutions: Justin concluded that both immediate and long-term solutions require changes in Clang, and the team agreed to address the immediate needs while deferring more complex questions for later.
Location Attribute Crashes and Dead Variable Cleanup:
Farzon, Steven, Justin, Nathan, and others examined issues with location attributes causing crashes in Vulkan validation, traced the problem to dead global variables not being cleaned up, and discussed potential solutions involving linker phases and instruction selection improvements.
- Crash Due to Unused Location Attributes: Farzon reported that adding location attributes causes crashes, while omitting them leads to Vulkan validator complaints. Justin and Steven analyzed test cases, noting that unused globals with location decorations are not properly cleaned up, resulting in validation errors.
- LLVM Emitter and Linking Model: Steven explained that LLVM emits global variables with struct types that are optimized away but retained due to the linking model, which keeps them for potential future references. This retention leads to dead variables persisting in the output.
- Potential Solutions and Linking Phase: The team discussed implementing a linker phase to clean up dead variables, with Steven suggesting a tool to delete hidden visibility variables post-linking. Justin noted that OpenCL’s approach complicates matters, as it requires retaining these variables for linking back into LLVM IR.
- Short-Term Workarounds and Test Marking: Justin proposed marking failing tests against the bug and possibly blocking further progress until the linking model is resolved. Steven suggested improving dead code removal during instruction selection as a potential workaround.
- Vulkan Validation Layer Integration: Steven and Justin discussed whether Vulkan validation layers are enabled during test runs, with Justin planning to follow up to ensure errors are caught earlier in the process.
Constant Buffer Design and Compatibility:
Steven, Justin, Tex, and Chris reviewed the initial constant buffer design, debated resource inclusion and function call restrictions, and considered compatibility and migration strategies for future HLSL language versions.
- Resource Inclusion Policy: Steven confirmed with Justin that the team will ban resources in constant buffers, aligning on this policy for the current design.
- Function Call Restrictions: Steven questioned whether non-const functions can be called on constant buffer objects. Tex clarified that HLSL does not currently support const functions, and Justin noted compatibility concerns, concluding that such calls must be allowed for now.
- Migration and Future Language Versions: Tex and Steven discussed proposals to add const support in future HLSL versions, with Steven suggesting that for 2020x, non-const calls are allowed, and for 2020y, stricter enforcement could be implemented with tooling support for migration.
- Implementation Details and Address Space Handling: Steven outlined unresolved implementation details, including function calling conventions and struct assignment for constant buffers, planning to wait for Helena’s struct assignment work before finalizing these aspects.
- Address Space and Layout Challenges: Tex and Steven debated address space handling, noting that address space 0 is treated as generic in LLVM and Clang, but layout incompatibilities require special handling for constant buffers. Justin proposed drafting a straw man proposal for improved address space management.
Intrinsic Header Updates and TableGen Migration:
Daniel, Farzon, Damyan, Deric, Kaitlin, and Justin discussed the migration of intrinsic headers to TableGen, clarified the location of updated information, and identified remaining issues with template-defined intrinsics.
- TableGen Migration Status: Daniel highlighted that many intrinsic headers are now generated from TableGen, leading to outdated checklists. Farzon explained that Kaitlin created a unified location for updated information and that most tickets have been updated accordingly.
- Remaining Template Intrinsic Issues: Deric noted that some intrinsics still require template definitions and cannot be fully migrated to TableGen, with Farzon acknowledging this limitation and referencing Derrick’s expertise.
PR Updates and Struct Assignment Coordination:
Helena informed Steven about taking over a PR related to constructor removal and address space changes in SPIR-V tests, requesting Steven’s review to ensure correctness, and discussed coordination on struct assignment for constant buffers.
- PR Review Request: Helena notified Steven about changes to SPIR-V tests involving address space copies and requested Steven to double-check the implementation for correctness.
- Struct Assignment Coordination: Steven indicated plans to wait for Helena’s completion of struct assignment work before finalizing constant buffer assignment handling, ensuring alignment with ongoing development.
Follow-up tasks:
- Location Attribute Validation Issue: Add the HLSL example that triggered the location attribute validation issue to the relevant GitHub issue for further debugging. (Farzon)
- SPIR-V Validation Test Failures: Mark the failing tests related to the SPIR-V validation issue against the corresponding bug to track and block on linking model resolution. (Justin)
- Vulkan Validation Layers in Test Suite: Follow up to confirm whether Vulkan validation layers are enabled during test runs, as errors should have been detected earlier. (Justin)
- Address Space Handling Proposal: Write a straw man proposal for changing the internal representation so that address space 0 is treated as generic, and address spaces are shifted appropriately during lowering. (Justin)