You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: proposals/030-coherent-pointers.md
+31-13Lines changed: 31 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# SP\#030: Coherent Pointers
1
+
# SP\#030: Coherent Pointers & Pointer Access
2
2
3
3
## Status
4
4
@@ -13,6 +13,8 @@ Reviewer:
13
13
14
14
GPUs have a concept known as coherent operations. Coherent operations flush cache for reads/writes so that when **thread A** modifies memory, **thread B** may read that memory, seeing all changes to memory done by a different thread. When flushing cache it is important to note that not all caches will be flushed. If a user wants coherence to `WorkGroup` memory, only the levels of cache up to `WorkGroup` memory will need to be flushed.
15
15
16
+
Additionally, pointers will be permitted to be marked as read-only or read/write. A read-only pointer will be immutable (unable to modify the data pointed to).
17
+
16
18
### Prior Implementations
17
19
18
20
* HLSL – `globallycoherent` keyword can be added to declarations (`globallycoherent RWStructuredBuffer<T> buffer`). This keyword ensures coherence with all operations to a tagged object. Memory scope of coherence is device memory. `groupshared` objects are likely coherent, specification does not specify.
@@ -45,10 +47,12 @@ If we specify `MakePointerAvailable/MakePointerVisible` with `OpStore`/`OpLoad`
45
47
46
48
## Proposed Solution
47
49
48
-
### Frontend For Coherent Pointers
50
+
### Frontend For Coherent Pointers & Pointer Access
49
51
50
52
We propose to implement coherence on a per-operation level for only SPIR-V targets. This will be accomplished through modifying `Ptr` to include the new generic argument `CoherentScope coherentScope`.
51
53
54
+
We also propose the new generic argument `Access access` to specify if a pointer is read-only or not.
@@ -104,19 +117,24 @@ Any access through a coherent-pointer to a `groupshared` object is coherent; Sin
104
117
105
118
We will allow pointers with different `CoherentScope` to be explicitly castable to each other. For example, `CoherentPtr<int, CoherentScope::Device>` will be castable to `CoherentPtr<int, MemoryScope.Workgroup>`.
106
119
120
+
### Casting and Pointer access
121
+
122
+
We will not allow casting between pointers of different `Access`.
123
+
107
124
### Banned keywords
108
125
109
126
HLSL style `globallycoherent T*` and GLSL style `coherent T*` will be disallowed.
110
127
111
128
### Order of Implementation
112
129
113
-
1. Support for workgroup memory pointers.
114
-
2. Frontend for coherent pointers
115
-
3. Support for coherent buffers and textures
116
-
4. Support for coherent workgroup memory
117
-
5. Support for coherent cooperative matrix & cooperative vector
118
-
6. Support casting between pointers with different `CoherentScope`
119
-
7. disallow `globallycoherent T*` and `coherent T*`
130
+
* Frontend for coherent pointers & pointer access
131
+
* Logic for pointer access
132
+
* Support for coherent buffers and textures
133
+
* Support casting between pointers with different `CoherentScope`
134
+
* Support for workgroup memory pointers.
135
+
* Support for coherent workgroup memory
136
+
* Support for coherent cooperative matrix & cooperative vector
137
+
* disallow `globallycoherent T*` and `coherent T*`
0 commit comments