[SM6.8] Add proposal for DXIL 1.8 #77
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change proposes an abbreviated DXIL 1.8 specification. We should fill this out with more detail as appropriate, but this should document the basic bits that we need to verify the compiler implementation.
llvm-beanz
added
the
Requires Shader Model
|
While a new shader model is introduced, do you think it might be possible to also deprecate constant buffer layout usage (with a flag) at the same time? Or would that introduce too much risk to the shader model release? I'm thinking the later that gets pushed out, the further into the future we'd have to maintain all that legacy cbuffer layout code :) |
This updates the new barrier instruction signatures.
Unfortunately, the non-legacy cbuffer layout has lots of bugs and fixing those is out of scope for SM 6.8 (we're too late in the process). It is on our mind as a change we want to get resolved for the future, but it will miss SM 6.8 |
pow2clk
approved these changes
Sep 26, 2023
This updates the DXIL 1.8 additions document with the expected changes to SM 6.8 features.
pow2clk
reviewed
Jan 17, 2024
tex3d
reviewed
Mar 9, 2024
tex3d
approved these changes
Apr 3, 2024
There was a problem hiding this comment.
I'm going to approve so we may add the document. However, there are a lot of deficiencies to address after we add the document, which should be captured as follow-up issues/tasks.
We should probably update the status to reflect the fact that we have already shipped this as well.
Besides the review feedback so far, there is also:
- Missing feature details for: expanded-comparison-sampling and extended-command-info
- Lacking descriptions for each new DXIL intrinsic and their parameters.
- Lacking descriptions for new metadata
- Lacking new feature flags and descriptions
There may be more missing that I'm not thinking of right now, but we can address that as we update the document and these things come up.
Co-authored-by: Tex Riddell <texr@microsoft.com>
Co-authored-by: Tex Riddell <texr@microsoft.com>
Co-authored-by: Tex Riddell <texr@microsoft.com>
* Add pseudo-class definition to vk::BufferPointer spec Fixes microsoft#45 * Change default alignment to alignof(S)
* Add type punning rules to vk::BufferPointer Fixes microsoft#43 * Clarify that type punning with buffer pointers leads to undefined behavior.
* Add writability to vk::BufferPointer pointees Fixes microsoft#41 * Add example of write through vk::BufferPointer * Add SPIR-V for write through buffer pointer.
* Add feature check for vk::BufferPointer Fixes microsoft#40 * Fix typo. --------- Co-authored-by: Chris B <cbieneman@microsoft.com>
* Add casting to buffer pointer proposal. * Add undefined behavior for null or invalid vk::BufferPointer * Review fixes. Specifically add a new vk::pointer_cast operator and allow casting of vk::BufferPointer to bool. * Fix white space error. * Create static and reinterpret casts. Use constructor for uint64_t.
* Specify aliasing and address space for vk::BufferPointer Fixes microsoft#42. * Refer to C99 for definition of restrict pointer. * Explicitly specify buffer pointers point into host memory address space.
This starts the review period for the spec. See issue microsoft#84 for more details.
Add the proposal for improvements to inline spirv.
The C++ specification talks in terms of module, external, internal, and no linkage. These linkages in C++ refer to translation units. For HLSL, we have some differences in how programs are built and linked that can't be fully expressed in that language. Specifically, we have a notion of a program-export (entry functions, export keyword), that denotes a linkage that is more external than just cross translation unit. This change introduces a term _program linkage_ to refer to names that have linkage outside a linked or freestanding program.
The comparison value was placed just after the locations in the implementation of SampleCmpBias and SampleCmpGrad. This moves the param in the spec to match.
This propsal will expose the [VK_KHR_cooperative_matrix](https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_cooperative_matrix.html) extension in HLSL.
Previously the spec had allowed trunction conversions to produce cxvalues which enabled them to be used in output arguments. This is inconsistent with the DXC and FXC implementation, which disallows binding trunctions to output arguments. The spec also previously did not allow trunction to scalar values. Initially that was excluded due to discussions around truncations and extensions of output arguments. Since DXC and FXC both disallow trunction in output arguments, it seems safe to support truncation to scalar here with a cooresponding warning. This will allow the spec to more consistently align with the reference implementations. This has no change to overload resolution except that a vector argument can be truncated to a scalar producing a Trunctaion, Truncation Promotion, or Truncation Conversion implicit conversion sequence.
…icrosoft#276) * Add a proposal on how to handle the loop unroll factor in HLSL 202x * update proposal
This wording went through a few iterations and it ended up in a silightly confused state. This just tries to simplify and clarify the ordering of the ranks.
There are a few discrepancies between what I originally wrote here and what DXC does. These changes adjust to the actual behavior and more closely align with implicit conversion sequences. Fixes microsoft#308
This somewhat future proofs some aspects of the language here by saying that [in]out parameter initialization is copy-initialization, but the writeback assignment is _assignment_. That allows for clarity around overloaded operators so that the argument life becomes something like this: ``` auto &ArgTmp = (Arg); // Evaluate the argument expr saving it. T Param = ArgTmp; // Copy-initialize Param with Arg's result. call(Param); // Call the function. ArgTmp = Param; // Assign back the Param result with =. ```
Having overloading before declarations was wrong. This just moves the chapter later.
This proposal is for HLSL 202y to adopt C++ 11 as its base C++ language version and encorporate as many of C++ 11's features as reasonably fit within HLSL's language design.
The sample uses an invalid syntax for initializing a vk::BufferPointer. This fixes up the syntax. Fixes microsoft#332.
The Opacity Micromaps (OMM) feature allows DirectX Ray Tracing developers to allow ray-triangle hits to be trivially classified as miss or hit without having to invoke an any-hit shader. This spec is narrowly focused on the HLSL compiler related aspects required to implement and test the feature from the compiler perspective.
This adds `needs-triage` to any PR that changes the proposals folder, which will cause it to appear on our triage board.
…rrays. (microsoft#323) WRT Workgraphs Feature: This is the HLSL counterpart of the proposal to new node output attribute called MaxRecordsPerNode. This parameter is only required for output node arrays. This attribute specifies the maximum number of records that can be written to any single output node within a node array. When determining backing store memory requirements, an implementation must assume the worst-case of MaxRecords written to any single node in the output array. However, a common use-case is for a small number records to be written to select nodes in a very large array of nodes. Some implementations can take advantage of this knowledge to significantly reduce the backing store memory requirements while maintaining peak performance. --------- Co-authored-by: Anupama Chandrasekhar <anupamac@nvidia.com> Co-authored-by: Tex Riddell <texr@microsoft.com>
It needs to checkout the repo before it can run the labeler.
Proposing HLSL vector types with length > 4. Co-authored-by: Anupama Chandrasekhar <anupamac@nvidia.com> Co-authored-by: Tex Riddell <texr@microsoft.com> Co-authored-by: Chris B <beanz@abolishcrlf.org>
* Start working on HLSL initialization lists This one is a bit gnarly because it involves a lot of depth-first traversing of declarations, types, and initialization expressions. Questions and suggestions on how to clarify are greatly appreciated! Co-authored-by: Greg Roth <grroth@microsoft.com>
This PR adds documentation and process outlines for the public design meetings that we will begin holding next week. Co-authored-by: Damyan Pepper <damyanp@microsoft.com>
…located on wg-hlsl. (microsoft#368) Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
…ft#339) * Add ALLOW_OPACITY_MICROMAPS template flag to RayQuery object Inline raytracing needs to be aware OMMs may be used, just like non-inline raytracing does. Non-inline raytracing has RAYTRACING_PIPELINE_FLAG_ALLOW_OPACITY_MICROMAPS. But raytracing pipeline state doesn't apply to inline raytracing. So for in the inline case, add a RAYQUERY_FLAG_ALLOW_OPACITY_MICROMAPS flag to the template parameters for instantiating the RayQuery object. * Update 0024-opacity-micromaps.md wording clarification
Co-authored-by: Greg Roth <grroth@microsoft.com> Co-authored-by: Tex Riddell <texr@microsoft.com> Co-authored-by: Radek Drabinski <radoslaw.drabinski@intel.com>
Adding meeting minutes from the 2025/01/21 design meeting.
…on (microsoft#373) Now that we know which AgilitySDK version will support hash bypass, the "TBD" in the spec can be replaced with the actual version. Also consider whether to move this out of "proposal" state, perhaps as soon as that AgilitySDK becomes available?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change proposes an abbreviated DXIL 1.8 specification. We should fill this out with more detail as appropriate, but this should document the basic bits that we need to verify the compiler implementation.