[Mlir-commits] [mlir] 25e8668 - [mlir][SPIR-V] Fix wrongly placed Rationale section.
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Thu Aug 6 11:52:13 PDT 2020
Author: MaheshRavishankar
Date: 2020-08-06T11:51:42-07:00
New Revision: 25e8668e88bb1fa7bfa359b56ba7c663ebec5d3b
URL: https://github.com/llvm/llvm-project/commit/25e8668e88bb1fa7bfa359b56ba7c663ebec5d3b
DIFF: https://github.com/llvm/llvm-project/commit/25e8668e88bb1fa7bfa359b56ba7c663ebec5d3b.diff
LOG: [mlir][SPIR-V] Fix wrongly placed Rationale section.
Differential Revision: https://reviews.llvm.org/D85461
Added:
Modified:
mlir/docs/Dialects/SPIR-V.md
Removed:
################################################################################
diff --git a/mlir/docs/Dialects/SPIR-V.md b/mlir/docs/Dialects/SPIR-V.md
index 021a0622d927..04e15ddd3a6b 100644
--- a/mlir/docs/Dialects/SPIR-V.md
+++ b/mlir/docs/Dialects/SPIR-V.md
@@ -1149,18 +1149,9 @@ There are also common utilities when targeting SPIR-V from any dialect:
These common utilities are implemented in the `MLIRSPIRVTransforms` library.
-## Contribution
-
-All kinds of contributions are highly appreciated! :) We have GitHub issues for
-tracking the [dialect][GitHubDialectTracking] and
-[lowering][GitHubLoweringTracking] development. You can find todo tasks there.
-The [Code organization](#code-organization) section gives an overview of how
-SPIR-V related functionalities are implemented in MLIR. This section gives more
-concrete steps on how to contribute.
-
## Rationale
-## Lowering `memref`s to `!spv.array<..>` and `!spv.rtarray<..>`.
+### Lowering `memref`s to `!spv.array<..>` and `!spv.rtarray<..>`.
The LLVM dialect lowers `memref` types to a `MemrefDescriptor`:
@@ -1183,14 +1174,14 @@ is lowered directly to a `!spv.ptr<!spv.array<nelts x elem_type>>` when the
below.
1. Inputs/output buffers to a SPIR-V kernel are specified using
- [`OpVariable`][SpirvOpVariable] inside
- [interface storage classes][VulkanShaderInterfaceStorageClass] (e.g.,
- Uniform, StorageBuffer, etc.), while kernel private variables reside in
- non-interface storage classes (e.g., Function, Workgroup, etc.). By default,
- Vulkan-flavored SPIR-V requires logical addressing mode: one cannot
- load/store pointers from/to variables and cannot perform pointer arithmetic.
- Expressing a struct like `MemrefDescriptor` in interface storage class
- requires special addressing mode
+ [`OpVariable`][SpirvOpVariable] inside [interface storage
+ classes][VulkanShaderInterfaceStorageClass] (e.g., Uniform, StorageBuffer,
+ etc.), while kernel private variables reside in non-interface storage
+ classes (e.g., Function, Workgroup, etc.). By default, Vulkan-flavored
+ SPIR-V requires logical addressing mode: one cannot load/store pointers
+ from/to variables and cannot perform pointer arithmetic. Expressing a
+ struct like `MemrefDescriptor` in interface storage class requires special
+ addressing mode
([PhysicalStorageBuffer][VulkanExtensionPhysicalStorageBuffer]) and
manipulating such a struct in non-interface storage classes requires special
capabilities ([VariablePointers][VulkanExtensionVariablePointers]).
@@ -1209,10 +1200,10 @@ below.
further advantages:
* All the dynamic shape/stride information of the `memref` can be combined
- into a single descriptor. Descriptors are
- [limited resources on many Vulkan hardware][VulkanGPUInfoMaxPerStageDescriptorStorageBuffers].
- So combining them would help make the generated code more portable
- across devices.
+ into a single descriptor. Descriptors are [limited resources on many
+ Vulkan hardware][VulkanGPUInfoMaxPerStageDescriptorStorageBuffers]. So
+ combining them would help make the generated code more portable across
+ devices.
* If the shape/stride information is small enough, they could be accessed
using [PushConstants][VulkanPushConstants] that are faster to access and
avoid buffer allocation overheads. These would be unnecessary if all
@@ -1223,6 +1214,15 @@ below.
frequently than the data stored in the buffers. They could be part of
diff erent descriptor sets.
+## Contribution
+
+All kinds of contributions are highly appreciated! :) We have GitHub issues for
+tracking the [dialect][GitHubDialectTracking] and
+[lowering][GitHubLoweringTracking] development. You can find todo tasks there.
+The [Code organization](#code-organization) section gives an overview of how
+SPIR-V related functionalities are implemented in MLIR. This section gives more
+concrete steps on how to contribute.
+
### Automated development flow
One of the goals of SPIR-V dialect development is to leverage both the SPIR-V
More information about the Mlir-commits
mailing list