Resource constructors proposal #197

hekota · 2025-03-28T19:48:52Z

Proposal for resource classes constructors.

Fixes #209

damyanp

So I've tried to understand this, and maybe I've been reading it too quickly, but I don't understand how any of these non-default constructors would get called?

hekota · 2025-03-28T21:31:51Z

So I've tried to understand this, and maybe I've been reading it too quickly, but I don't understand how any of these non-default constructors would get called?

Right, I did not mention that. Only the default constructor call gets generated automatically by Clang. The others will be set up by Sema after processing the resource binding attribute, or a lack of it. Basically it will be changing:

RWBuffer<float> A : register(u3)
into
RWBuffer<float> A(Binding(0,3,1,0));

damyanp · 2025-03-28T21:35:17Z

Ah, thanks, that helps!

The others will be set up by Sema after processing the resource binding attribute, or a lack of it.

What will Sema use to identify things that need to be fixed up in this way?

hekota · 2025-03-28T23:49:36Z

What will Sema use to identify things that need to be fixed up in this way?

Sema detects whether a global variable is resource class by checking if the first field of the declaration is a resource handle.

…ip the order of space and register

…sibly not needing __handle as builtin param

We already have `__builtin_hlsl_resource_getpointer` and we should follow the same pattern for other buildins related to resources. Renaming the builtins to: `__builtin_hlsl_resource_createpoisonhandle` `__builtin_hlsl_resource_createhandlefrombinding` `__builtin_hlsl_resource_createhandlefromimplicitbinding`

proposals/NNNN-resource-constructors.md

bob80905

Looks good to my untrained eye

llvm-beanz · 2025-04-16T20:18:56Z

proposals/NNNN-resource-constructors.md

+
+### Dynamically-bound resources
+
+TBD


I think for this case we probably can have something where ResourceDescriptorHeap is an array of some magic "untyped handle", and we have a constructor that constructs from that untyped handle to a resource with a different builtin to initialize the handle.

That doesn't need to be designed for this document, but I think it follows well with the patterns here.

llvm-beanz

I like this.

I was a little skeptical about having the constructor calls in the AST, but honestly, this is great.

…constructors

- Adds resource constructor that takes explicit binding for all resource classes. - Updates implementation of default resource constructor to initialize resource handle to `poison`. - Removes initialization of resource classes from Codegen. - Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime` because it does not have a corresponding resource class type. - Adds `ImplicitCastExpr` for builtin function calls. Sema adds these automatically when a method of a template class is instantiated, but some resource classes like `ByteAddressBuffer` are not templates so they need to have this added explicitly. Design proposal: llvm/wg-hlsl#197 Closes #134154

- Adds resource constructor that takes explicit binding for all resource classes. - Updates implementation of default resource constructor to initialize resource handle to `poison`. - Removes initialization of resource classes from Codegen. - Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime` because it does not have a corresponding resource class type. - Adds `ImplicitCastExpr` for builtin function calls. Sema adds these automatically when a method of a template class is instantiated, but some resource classes like `ByteAddressBuffer` are not templates so they need to have this added explicitly. Design proposal: llvm/wg-hlsl#197 Closes llvm#134154

- Adds resource constructor that takes explicit binding for all resource classes. - Updates implementation of default resource constructor to initialize resource handle to `poison`. - Removes initialization of resource classes from Codegen. - Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime` because it does not have a corresponding resource class type. - Adds `ImplicitCastExpr` for builtin function calls. Sema adds these automatically when a method of a template class is instantiated, but some resource classes like `ByteAddressBuffer` are not templates so they need to have this added explicitly. Design proposal: llvm/wg-hlsl#197 Closes #134154

- Adds resource constructor that takes explicit binding for all resource classes. - Updates implementation of default resource constructor to initialize resource handle to `poison`. - Removes initialization of resource classes from Codegen. - Initialization of `cbuffer` still needs to happen in `CGHLSLRuntime` because it does not have a corresponding resource class type. - Adds `ImplicitCastExpr` for builtin function calls. Sema adds these automatically when a method of a template class is instantiated, but some resource classes like `ByteAddressBuffer` are not templates so they need to have this added explicitly. Design proposal: llvm/wg-hlsl#197 Closes llvm#134154

* [0002] RootSignatures - Versioning proposal (llvm#115) This PR is adding the versioning information to Root Signature specs. It includes: - adding a new attribute to clang driver to specify root signature versions. - updating metadata representation to hold root signature versions. Closes: llvm#113 * [0002] RootSignatures - Add default values to proposal (llvm#173) - adds default value information to the Root Signature specification Resolves llvm#172 * Proposal for mapping resource attributes to DXIL and SPIR-V (llvm#76) * Constant buffers design document (llvm#94) Design document describing how HLSL constant buffers will be handled in Clang. Contains the design for parsing, codegen a lowering of `cbuffer` declarations, including the default constant buffer `$Globals`. Design for the `ConstantBuffer<T>` resource class is still work in progress. * Update proposal number on constant buffers proposal (llvm#188) * [NNNN] Target Extension Types for Inline SPIR-V and Decorated Types (llvm#105) This adds target extension types to represent `SpirvType` from [HLSL 0011, Inline SPIR-V](https://github.com/microsoft/hlsl-specs/blob/main/proposals/0011-inline-spirv.md). * [0018] SPIRV resource representation (llvm#98) Adds a proposal for how HLSL resources will be represented in llvm-ir when targeting SPIR-V. * [SPIR-V] Add proposal for I/O builtin in Clang (llvm#97) Initial proposal to implement Input/Output built ins with both semantic & inline SPIR-V * [SPIR-V] Add proposal for global & local variable address spaces (llvm#111) This commit adds a proposal on how to implement local and global variables in the SPIR-V backend given HLSL put them in the same address space while SPIR-V requires them to be in 2 distinct ones. --------- Signed-off-by: Nathan Gauër <brioche@google.com> Co-authored-by: Steven Perron <stevenperron@google.com> * [0002] RootSignatures - Add missing Descriptor Ranges `offset` (llvm#191) - it appears the `offset` was mistakenly dropped as discarding this information no longer allows the user to provide a manual offset from the start of the descriptors heap and allow for register aliasing - additionally, we do a small fix-up to update the flag values to be their correct default as we adjust the parameter values Resolves llvm#190 --------- Co-authored-by: Finn Plummer <finnplummer@microsoft.com> * [0002] RootSignatures - Misc updates to spec from testing (llvm#195) This issue addresses the discrepancies found from testing [here](llvm/llvm-project#130826). The pr has been broken up to commits that address the bullet points in the original issue. Briefly: - First 2 commits work to have a concrete EBNF description of the grammar that denotes that all parameter args can be specified in any order - It is also addressed that `NUMBER` can be more restrictive with respect to what the dxc/clang compiler will accept - Missing documentation for `unbounded` is added - Add additional validation of some parameters that surface as errors in dxc - Remove the specification of 'AllowLowTierReservedHwCbLimit' Resolves llvm#192 --------- Co-authored-by: Finn Plummer <finnplummer@microsoft.com> * [0021] Proposal for handling member function address spaces. (llvm#187) As we expose new address spaces in HLSL, we will have a problem with the address space for the `this` pointer in member functions. * Resource Instance Analysis (llvm#207) Fixes llvm#179 Proposes a generic architecture for organizing, resolving, and validating Resource Instance metadata --------- Co-authored-by: Damyan Pepper <damyanp@microsoft.com> Co-authored-by: Helena Kotas <hekotas@microsoft.com> * [0023] Proposal for separate counter resource handle (llvm#208) This is a proposal to create a separte handle for the counter resource in RWStructureBuffer and other that have associated counters. * [0002] RootSignatures - NFC Formatting Grammar to EBNF (llvm#198) Update the formatting of the root signature grammar to use EBNF in a consistent manner: - The first commit just goes through to use `=` instead of `:` and denote statements with ';' to comply with EBNF - The second commit comes from a suggestion [here](llvm#195 (comment)) to just use the `|` notation to specify the parameters in any order but not explicitly denote that they can only occur once Clean up pr to resolve llvm#192 --------- Co-authored-by: Finn Plummer <finnplummer@microsoft.com> * Implicit resource binding - document current DXC behavior (llvm#193) Initial commit of the Implicit Resource Binding proposal that includes: - brief overview section on resource bindings - number of examples documenting how are implicit resource bindings are assigned in DXC Closes llvm#176 * Implicit resource bindings design (llvm#196) Proposed design for implicit resource bindings in Clang. Closes llvm#177 * Resource constructors proposal (llvm#197) Proposal for resource classes constructors. Closes llvm#209 * Remove tools/hlslpm (llvm#228) As the process evolves, it becomes more effort to keep tools/hlslpm up to date. This change removes tools/hlslpm rather than keep a stale version around. * Update issue_tracking.md for latest thinking (llvm#229) Describe epics, scenarios, deliverables and tasks, and the custom fields used in the HLSL Support project. --------- Co-authored-by: Finn Plummer <canadienfinn@gmail.com> * Add "Review" value for the "blocked" field (llvm#257) Some issues are blocked on design review. This value can be used to identify them. * Resource binding: add another example and notes about resources in structs (llvm#214) Add one more example showing binding of resource arrays in user-defined structs. Add a note to re-evaluate whether to bind resource arrays in structs individually or as a continuous descriptor range later on when we start working on the resources in structs design (llvm/wg-hlsl#llvm#212). * [0026] Add proposal for symbol visibility. (llvm#272) Section 3.6 of the [HLSL specification](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf) defined the possible linkages for names. This proposal updates how these linkages are represented in LLVM IR. The current implementation presents challenges for the SPIR-V backend due to inconsistencies with OpenCL. In HLSL, a name can have external linkage and program linkage, among others. If a name has external linkage, it is visible outside the translation unit, but not outside a linked program. A name with program linkage is visible outside a partially linked program. We propose that names with program linkage in HLSL should have external linkage and default visibility in LLVM IR, while names with external linkage in HLSL should have external linkage and hidden visibility in LLVM IR. They both have external linkage because they are visible outside the translation unit. Default visibility means the name is visible outside a shared library (program). Hidden visibility means the name is not visible outside the shared library (program). * Update proposals for implicit binding and resource constructors to match implementation (llvm#282) * Add missing titles to proposals (llvm#283) Adding title to proposals that were missing one. * Unify new line endings to LF (llvm#286) Add .gitattributes and set new line endings to LF. Normalize existing files by running `git add --renormalize`. * [NNNN] Implementation for `vk::constant_id` (llvm#287) Design for the Clang implmentation of`vk::constant_id`. --------- Signed-off-by: Nathan Gauër <brioche@google.com> Co-authored-by: Finn Plummer <50529406+inbelic@users.noreply.github.com> Co-authored-by: Justin Bogner <mail@justinbogner.com> Co-authored-by: Helena Kotas <hekotas@microsoft.com> Co-authored-by: Cassandra Beckley <cbeckley@google.com> Co-authored-by: Steven Perron <stevenperron@google.com> Co-authored-by: Nathan Gauër <github@keenuts.net> Co-authored-by: Finn Plummer <finnplummer@microsoft.com> Co-authored-by: Ashley Coleman <ascoleman@microsoft.com> Co-authored-by: Damyan Pepper <damyanp@microsoft.com> Co-authored-by: Finn Plummer <canadienfinn@gmail.com>

Resource constructors - initial commit

61cc4fa

github-project-automation bot added this to HLSL Support Mar 28, 2025

damyanp reviewed Mar 28, 2025

View reviewed changes

hekota added 4 commits March 28, 2025 17:07

Add info about where constructors calls with bindings are created; fl…

9378ebc

…ip the order of space and register

fix wording

261a777

Make range signed; add summary with full class def

60a3beb

Remove Binding struct, make binding constructors private, mention pos…

103be20

…sibly not needing __handle as builtin param

hekota mentioned this pull request Apr 2, 2025

[HLSL] Implement resource initialization by constructors llvm/llvm-project#134154

Closed

hekota requested a review from llvm-beanz April 7, 2025 20:09

bob80905 reviewed Apr 8, 2025

View reviewed changes

proposals/NNNN-resource-constructors.md Outdated Show resolved Hide resolved

proposals/NNNN-resource-constructors.md Show resolved Hide resolved

proposals/NNNN-resource-constructors.md Outdated Show resolved Hide resolved

Make operator = default; fix typo

057ffc3

bob80905 approved these changes Apr 8, 2025

View reviewed changes

hekota mentioned this pull request Apr 10, 2025

[HLSL] Resource initialization by constructors llvm/llvm-project#135120

Merged

hekota self-assigned this Apr 10, 2025

llvm-beanz reviewed Apr 16, 2025

View reviewed changes

llvm-beanz approved these changes Apr 16, 2025

View reviewed changes

hekota mentioned this pull request Apr 21, 2025

Dynamic resources design #204

Open

hekota added 2 commits April 21, 2025 12:17

Merge branch 'main' of https://github.com/llvm/wg-hlsl into resource-…

ade86ea

…constructors

Update proposal number to 0025

0db6ce0

hekota merged commit 3055d46 into llvm:main Apr 21, 2025

damyanp moved this to Closed in HLSL Support Apr 25, 2025

damyanp removed this from HLSL Support Jun 25, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Resource constructors proposal #197

Resource constructors proposal #197

Uh oh!

hekota commented Mar 28, 2025 •

edited

Loading

Uh oh!

damyanp left a comment

Uh oh!

hekota commented Mar 28, 2025 •

edited

Loading

Uh oh!

damyanp commented Mar 28, 2025

Uh oh!

hekota commented Mar 28, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bob80905 left a comment

Uh oh!

llvm-beanz Apr 16, 2025

Uh oh!

llvm-beanz left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		### Dynamically-bound resources

		TBD

Resource constructors proposal #197

Resource constructors proposal #197

Uh oh!

Conversation

hekota commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

damyanp left a comment

Choose a reason for hiding this comment

Uh oh!

hekota commented Mar 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

damyanp commented Mar 28, 2025

Uh oh!

hekota commented Mar 28, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bob80905 left a comment

Choose a reason for hiding this comment

Uh oh!

llvm-beanz Apr 16, 2025

Choose a reason for hiding this comment

Uh oh!

llvm-beanz left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

hekota commented Mar 28, 2025 •

edited

Loading

hekota commented Mar 28, 2025 •

edited

Loading