Document Fast-track process (#253)

This updates the process docs to add a new documented "fast-track"
process for introducing conforming extensions to HLSL.

This new process is intended to make it easy to quickly add vendor or
platform specific extensions as long as they conform to the existing
language definition.

Co-authored-by: Steven Perron <[email protected]>

docs/Process.md

@@ -2,15 +2,16 @@
 
 The primary purpose of this repository is to provide visibility into the feature
 development process for HLSL and solicit feedback from the wider community.
-Despite the openness of this process there are three significant caveats that
+Despite the openness of this process there are two significant caveats that
 should be noted:
 
 1. Final decisions about what features are included or excluded from HLSL are
    made by the MSFT HLSL Team. Our goals are to make HLSL the best programming
    language across all supported runtime targets, not just DirectX or Vulkan.
-2. Some HLSL features may not go through this process, and may be kept secret
-   during development. We will try to restrict this only to features that
-   require NDAs with hardware vendors, but that may not always be the reason.
+2. Some HLSL features may instead go through a
+
+   [Fast-track](#fast-track-for-extensions) process. This process is reserved
+   for platform and vendor extensions and is not suitable to all features.
 
 Feature proposals from outside the HLSL team will be interpreted as requests,
 and may be considered or rejected based on team and release priorities. You
@@ -178,3 +179,62 @@ When filing issues relating to a currently in-progress proposal (i.e. any propos
 
 When filing issues relating to a completed feature or specification document
 please use the _Spec_ template.
+
+## Fast-Track for Extensions
+
+Some features for HLSL expose new hardware capabilities and require years of
+development before they can be made public. For these features we have a
+fast-track process to incorporate platform-specific and vendor-specific
+extensions to HLSL as long as they are _conforming extensions_. Extension
+proposals should use the [Extension
+Template](/proposals/templates/extension-template.md).
+
+### Conforming Extensions
+
+Conforming extensions are language features which do not add new language
+behavior or syntax. They cannot remove or deprecate functionality, and they
+cannot be breaking changes. They can add new builtin function declarations,
+builtin data types, and attributes as long as the added features do not change
+the rules of the language. All added declarations must be under a namespace, and
+cannot be under the `hlsl`, `std` or global namespaces which are reserved for
+core language features.
+
+#### Extension Attribute Restrictions
+
+Additionally there are limitations specifically for attributes. Added attributes
+may not modify canonical types, or otherwise change how HLSL code is
+interpreted. They can compile down to metadata that produces annotations, and
+they can be used for analysis and verification. Adding attributes that change
+language behavior must be done through the full review process. As some concrete
+examples:
+
+* Type attributes like `precise` and `groupshared` _can not_ be added as
+  extension attributes, because they (1) modify underlying canonical types, and
+  (2) are not namespaced.
+* Type attributes like `[vk::ext_reference]` _can not_ be added as extension
+  attributes, because it modifies the underlying canonical type.
+* Parameter attributes like `[vk::ext_literal]` _can_ be added as an extension
+  attribute, because it does not modify the type or behavior of the language it
+  just annotates a declaration for additional verification.
+* Entry attributes like `[NodeIsProgramEntry]` _can not_ be added as an extension
+  attribute, because it is not namespaced. If instead it were spelled
+  `[dx::NodeIsProgramEntry]` it would comply since it does not modify the code
+  generation of the function it only changes generated metadata.
+
+### Fast-Track Process
+
+Features that meet the definition of a conforming extension can be merged
+directly as **Accepted** features with only a PR review. During that review a
+feature will only be rejected if it does not meet the restrictions of a
+conforming extension, in which case it will need to either be revised to meet
+that definition or go through the full review process.
+
+### Extension Deprecation Process
+
+If a significant number of user bugs arise with an extension and the platform or
+vendor who contributed the feature abandons maintenance and no other party takes
+up the maintenance an extension may be deprecated and removed following a
+deprecation period of no less than 6 months.
+
+Decisions to deprecate an extension will not be taken lightly, however carrying
+broken features in the compiler will cause more harm to users than good.

proposals/templates/extension-template.md

@@ -0,0 +1,116 @@
+<!-- {% raw %} -->
+
+# Feature name
+
+## Instructions
+
+> This template is a guideline for documenting a platform or vendor extension.
+> For a feature to be a conforming extension it must not change language
+> behaviors. It can introduce new builtin functions, data types, and annotating
+> attributes, but cannot introduce new language behaviors or rules.
+>
+> This template wraps at 80-columns. You don't need to match that wrapping, but
+> having some consistent column wrapping makes it easier to view diffs on
+> GitHub's review UI. Please wrap your lines to make it easier to review.
+>
+> Delete this Instructions section including the line below.
+
+---
+
+* Proposal: [NNNN](NNNN-filename.md)
+* Author(s): [Author 1](https://github.com/author_username)
+* Sponsor: TBD
+* Status: **Accepted**
+* Required Version: Shader Model X.Y, Vulkan X.Y, and/or HLSL 20XY
+* PRs: [#NNNN](https://github.com/microsoft/DirectXShaderCompiler/pull/NNNN)
+* Issues:
+  [#NNNN](https://github.com/microsoft/DirectXShaderCompiler/issues/NNNN)
+
+## Introduction
+
+10,000 ft view of the change being proposed. Try to keep to one paragraph and
+less than 10 sentences.
+
+## Motivation
+
+Describe the problems users are currently facing that this feature addresses.
+Include concrete examples, links to related issues, and any relevant background.
+
+The point of this section is not to convince reviewers that you have a solution,
+but rather that HLSL has a problem that needs to be resolved.
+
+If there is an existing extension that solves a similar use case explain why it
+is insufficient, and how this extension is an improvement.
+
+## High-level description
+
+Describe your solution to the problem. Provide examples and describe how they
+work. Show how your solution is better than current workarounds: is it cleaner,
+safer, or more efficient?
+
+## Detailed design
+
+This section should describe the feature in enough technical detail that someone
+other than the author could implement it. Each feature will need different levels
+of detail here, but some common things to think through are:
+
+### HLSL Additions
+
+* What new APIs and data types are added?
+* How does it interact with different shader stages?
+* How does it work interact other HLSL features (semantics, buffers, etc)?
+* Does this have implications for existing HLSL source code compatibility?
+* How will users detect if the compiler supports this feature?
+
+### Interchange Format Additions
+
+* What DXIL and/or SPIR-V changes does this change require?
+* What Metadata changes does this require?
+* How will each new API and data type be lowered to the target format?
+
+### Diagnostic Changes
+
+* What additional errors or warnings does this introduce?
+* What existing errors or warnings does this remove?
+
+#### Validation Changes
+
+* What additional validation failures does this introduce?
+* What existing validation failures does this remove?
+
+### Runtime Additions
+
+#### Runtime information
+
+* What information does the compiler need to provide for the runtime and how?
+
+#### Device Capability
+
+* How does it interact with other platform or vendor extension options?
+* What underlying target requirements are prerequisite for the feature?
+* What portions are require an existing or new optional feature?
+* Can this feature be supported through emulation or some other means
+  in older drivers/runtimes?
+
+## Testing
+
+* How will correct codegen for DXIL/SPIRV be tested?
+* How will the diagnostics be tested?
+* How will validation errors be tested?
+* How will validation of new DXIL elements be tested?
+* How will the execution results be tested?
+
+## Alternatives considered (Optional)
+
+If alternative solutions were considered, please provide a brief overview. This
+section can also be populated based on conversations that occur during
+reviewing. Having these solutions and why they were rejected documented may save
+trouble from those who might want to suggest feedback or additional features that
+might build on this on. Even variations on the chosen solution can be interesting.
+
+## Acknowledgments (Optional)
+
+Take a moment to acknowledge the contributions of people other than the author
+and sponsor.
+
+<!-- {% endraw %} -->