Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[0006] Propose the set of resource attributes that are needed to describe texture resources #42

Closed
wants to merge 5 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions proposals/0006-resource-attributes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
<!-- {% raw %} -->
* Proposal: [0006](0004-register-types-and-diagnostics.md)
* Author(s): [Joshua Batista](https://github.com/bob80905)
* Sponsor: TBD
* Status: **Under Consideration**
* Impacted Project(s): (LLVM)
* PRs: []
* Issues: [#39](https://github.com/llvm/wg-hlsl/issues/39)

## Introduction
In DXC, binding textures to registers will result in the decl representing
the texture resource having an attribute added to it. This attribute, the
`HLSLResource` attribute, contains the `ResourceKind` enum that contains
an enumeration of all possible resource types. This data is used to inform
codegen on how to construct the dxil handle that represents the declared
resource.

## Motivation

In LLVM, it is no longer desired to retain this resource kind data within
the `HLSLResource` attribute, and the attribute itself will be removed.
However, after removing this attribute, there will not be sufficient
information on how to construct the dxil handle. For example, the
resource kind may specify `Texture2DMS`, which would inform the codegen
pass that the given texture has a multi-sample texture type.
With the planned removal of the `HLSLResource` attribute, we need to
substitute the attribute with other attributes that contain enough
information to construct the dxil handle that needs to be constructed.
For example, an attribute should exist to preserve the information that
the given resource is a texture, and has a multi-sample texture type.

To properly substitute the `HLSLResource` attribute, it should be
confirmed that the proposed substitute attributes are sufficient to
directly reconstruct all defined resource types.

## Proposed Solution
The table below specifies all texture types that exist in HLSL, and
the attributes we would expect to see on the type that defines these
texture variables. We should expect that given any combination of
attributes and values of the attributes, we can directly infer what
the texture type is and how to construct the associated dxil handle.
For example, a `RWTexture2DMSArray` texture would have a definition
in an HLSL header, and the type itself would be constructed with
specific attributes attached to it: `hlsl::resource_class` would be
`SRV`, `hlsl::is_rov` would not be present, `hlsl::texture_dimension`
would be `2DArray`, and `hlsl::texture_type` would be `MS`.

| HLSL Texture Type | hlsl::resource_class | hlsl::is_rov | hlsl::texture_dimension | hlsl::is_cube | hlsl::is_ms | hlsl::is_feedback | hlsl::is_array |
| ------------------------------- | -------------------- | ------------ | ----------------------- | ------------- | ----------- | ----------------- | -------------- |
| Texture1D | SRV | - | 1 | - | - | - | - |
| RWTexture1D | UAV | - | 1 | - | - | - | - |
| RasterizerOrderedTexture1D | UAV | yes | 1 | - | - | - | - |
| Texture1DArray | SRV | - | 1 | - | - | - | yes |
| RWTexture1DArray | UAV | - | 1 | - | - | - | yes |
| RasterizerOrderedTexture1DArray | UAV | yes | 1 | - | - | - | yes |
| Texture2D | SRV | - | 2 | - | - | - | - |
| RWTexture2D | UAV | - | 2 | - | - | - | - |
| RasterizerOrderedTexture2D | UAV | yes | 2 | - | - | - | - |
| Texture2DArray | SRV | - | 2 | - | - | - | yes |
| RWTexture2DArray | UAV | - | 2 | - | - | - | yes |
| RasterizerOrderedTexture2DArray | UAV | yes | 2 | - | - | - | yes |
| Texture3D | SRV | - | 3 | - | - | - | - |
| RWTexture3D | UAV | - | 3 | - | - | - | - |
| RasterizerOrderedTexture3D | UAV | yes | 3 | - | - | - | - |
| TextureCUBE | SRV | - | 3 | yes | - | - | - |
| TextureCUBEArray | SRV | - | 3 | yes | - | - | yes |
| Texture2DMS | SRV | - | 2 | - | yes | - | - |
| Texture2DMSArray | SRV | - | 2 | - | yes | - | yes |
| RWTexture2DMS | UAV | - | 2 | - | yes | - | - |
| RWTexture2DMSArray | UAV | - | 2 | - | yes | - | yes |
| FeedbackTexture2D | SRV | - | 2 | - | - | yes | - |
| FeedbackTexture2DArray | SRV | - | 2 | - | - | yes | yes |
| TypedBuffer | SRV | - | - | - | - | - | - |
| RawBuffer | SRV | - | - | - | - | - | - |
| StructuredBuffer | SRV | - | - | - | - | - | - |
Comment on lines +73 to +75
Copy link
Collaborator

Choose a reason for hiding this comment

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

The three buffer types are indistinguishable according to these attributes, and I expect we want to cover the missing ConstantBuffer and TextureBuffer types here as well.

Here are some ideas for extending the attributes to distinguish buffer types and incorporate ConstantBuffer/TextureBuffer:

  • Add [[hlsl::row_layout]] for ConstantBuffer and TextureBuffer to identify where special cbuffer row layout rules are used with untranslated components from the constant buffer or typed buffer.
  • [[hlsl::row_layout]] would be combined with [[hlsl::resource_class(CBV)]] for ConstantBuffer or [[hlsl::resource_class(SRV)]] for TextureBuffer.
  • Add [[hlsl::raw_buffer]] for RawBuffer and StructuredBuffer.
  • Add [[hlsl::struct_stride(n)]] for StructuredBuffer, where n is the stride for the structured buffer in bytes.



## Detailed design

## Acknowledgments (Optional)
* Damyan Pepper
<!-- {% endraw %} -->