#30 - Coherent Pointers & Pointer Access Proposal #24

ArielG-NV · 2025-06-12T01:20:44Z

This proposal is for implementing (only for SPIR-V targets) coherent loads and stores through pointers. This proposal also implements ReadOnly (immutable) pointers & ReadWrite pointers.

A Slang playground example is provided here to test how MakePointerVisibleKHR and related operands function. This is not an implementation of the proposal.

csyonghe · 2025-06-16T23:14:16Z

proposals/030-coherent-pointers.md

+public enum PointerFlags
+{
+    None = 0,
+    Coherent = 0b1


Can be done in another proposal, but I expect PointerFlags to be extended to also cover Const.

I would worry about overloading a single flags enum to handle too many different axes here. The following all seem, to me, to be reasonably orthogonal (and thus merit distinct generic arguments)

The type of the storage location being pointed to

The address space where the storage location resides

The access modes that are allowed to be performed through the pointer (read-only, write-only, or read-write)

The coherence scope for operations performed through the pointer.

After asking Yong (separately from this PR), there was agreement on the design proposed.

csyonghe · 2025-06-16T23:23:31Z

proposals/030-coherent-pointers.md

+
+### Support The `globallycoherent` Keyword
+
+Slang will implement support for use of the `globallycoherent T*` keyword. This will be an alias to `Ptr<T, PointerFlags.Coherent, MemoryScope.Device>`.


We likely will need some type aliases e.g. CoherentPtr<T, MemoryScope> so that the user does not need to specify the AddressSpace.UserPointer in their Ptr type signature.

Also need to handle the syntax of:

groupshared int * // a pointer to groupshared mem int groupshared * // a same as above coherent int groupshared* // a pointer to groupshared coherent mem groupshared coherent int * // same as above coherent groupshared int* // same as above ... int * groupshared // a groupshared variable that is a global pointer int * coherent groupshared * // a pointer to coherent groupshared mem int * coherent * groupshared // a groupshared variable that is a pointer to coherent global mem ...

This syntax is complex enough that we may want to completely disallow it in the initial implementation with an error on things like globallycoherent int*, and then support it in a separate languauge proposal.

CoherentPtr<T, MemoryScope> worries me a bit since down the line there may be situations where a pointer abides to 2 different memory scopes for whatever reason SPIR-V requires.

Maybe the eventual solution here is named generic parameters: Ptr<type=T, flags=PointerFlags.Coherent, scope=MemoryScope.Device> ptr;

tangent-vector

I think this is important stuff to expose, but it also touches on a lot of big-picture topics in the language design that I wouldn't want us to bake too soon.

tangent-vector · 2025-06-18T20:51:31Z

proposals/030-coherent-pointers.md

+public enum PointerFlags
+{
+    None = 0,
+    Coherent = 0b1


I would worry about overloading a single flags enum to handle too many different axes here. The following all seem, to me, to be reasonably orthogonal (and thus merit distinct generic arguments)

The type of the storage location being pointed to

The address space where the storage location resides

The access modes that are allowed to be performed through the pointer (read-only, write-only, or read-write)

The coherence scope for operations performed through the pointer.

tangent-vector · 2025-06-18T20:55:12Z

proposals/030-coherent-pointers.md

+    Coherent = 0b1
+}
+
+__generic<T, uint64_t addrSpace=AddressSpace::UserPointer, PointerFlags flags=PointerFlags.None, MemoryScope coherentMemoryScope=MemoryScope.Device>


It would be nice to fold the PointerFlags.Coherent part together with the coherentMemoryScope part, because there's a strong relationship between the two:

It is meaningless to specify a scope without also specifying the Coherent flag, but this is allowed and means that code could look like it does something it doesn't. E.g., if they write Ptr<T, PointerFlags.None, MemoryScope.WorkGroup> that might look like there's something meaningful being communicated via the WorkGroup argument, but there really isn't.

A programmer really shouldn't be saying something is Coherent without taking a second to think about the scope of coherency they want.

I would propose that the simplest fix is to support a "scope" that represents operations only being guaranteed coherent within the current thread/work-item/lane/whatever-you-like-to-call-it.

This will be implemented (per param, 1 unique enum) as per suggested in #24 (comment)

example (not final):

enum CoherentPtrFlags { NotCoherent, CoherentToDevice, CoherentToWorkgroup, ... }

tangent-vector · 2025-06-18T20:57:12Z

proposals/030-coherent-pointers.md

+groupshared T* // a pointer to groupshared memory: Ptr<T, AddressSpace::GroupShared>
+T groupshared* // a same as above
+
+coherent T groupshared* // a pointer to groupshared coherent memory: Ptr<T, AddressSpace::GroupShared, PointerFlags.Coherent, MemoryScope::WorkGroup>
+groupshared coherent T* // same as above
+coherent groupshared T* // same as above
+...
+int* groupshared // a groupshared variable that is a global pointer: groupshared Ptr<T, MemoryScope::Device>
+int* coherent groupshared* // a pointer to coherent groupshared memory: Ptr<T, AddressSpace::GroupShared, PointerFlags.Coherent, MemoryScope::WorkGroup>
+int* coherent* groupshared // a groupshared variable that is a pointer to coherent global memory: groupshared Ptr<T, PointerFlags.Coherent, MemoryScope::Device>
+
+globallycoherent T* // pointer which is coherent to global memory: groupshared Ptr<T, PointerFlags.Coherent, MemoryScope::Device>


I strongly object to a lot of this, just because it adds more modifiers and more keyword soup to Slang. We should be very cautious about adding tons of keywords and especially about keywords that can be used to qualify pointers...

I personally have a conflicting opinion of these sorts of things:

people moving from HLSL->Slang would want the soup of modifiers/keywords because it looks like HLSL

This mess of modifiers/keywords is antagonistic to writing good generic code & is confusing.

keywords promote not thinking about the non-keyword memory-scopes, this is the same problem we have with HLSL/GLSL/...

keywords promote not using generics with Ptr<> types since the underlying type is obfuscated

int* coherent groupshared* != int* coherent* groupshared is bound to confuse people due to the small and nuanced differences in meaning.

@csyonghe had originally proposed the addition here

Final decision made: We are to remove this feature as a "next step". We should not have a stance on this currently.

tangent-vector · 2025-06-18T20:58:44Z

proposals/030-coherent-pointers.md

+
+```c#
+RWStructuredBuffer<int> val; // Texture works as well.   
+Ptr<int, PointerFlags.Coherent, MemoryScope.Subgroup> p = &val[0];


This line of code already opens up a line of questions that I think is really important for this proposal to address: what are the conversion rules for Ptr values under this proposal? Can a pointer with Coherent be converted to one without? Vice-versa? Can one with a narrow coherency scope be converted to one with a wider scope? Why or why not?

Thinking about it more, the big question I have is: what are the circumstances where a function would use a Ptr type in its signature that has the Coherent flag set, and in those circumstances what is the functions signature actually communicating?

If pointers with/without coherency and with different scopes are inter-convertible, then putting any of that information in a function signature is effectively meaningless to the code that wants to call it. It would be one of those things like marking a function parameter const (not a pointer-to-const, but just a const parameter) where it is sitting there in the signature and thus gets exposed to callers, but in practice it is only significant to the implementer of a function, for the code they write in the function body.

I think this gets into the bigger question on whether or not we should encode coherency in the pointer type itself.

The convenience of encoding it as part of the type is such that it propagates through pointer access chains, and the load/store site is automatically obeying to coherent access rules.

The downside is it complicates type coercion in a way that doesn't provide any actual meaning regarding caller/callee contract. I can't think of a case where a caller needs to know if a pointer is being accessed in a coherent way or not.

I think allowing to freely cast is a give and take here (rather than just all bad as with const).

Users are likely to mix Coherent and Non-Coherent operations (expected behavior), hence casting freely will be useful. It is expected that a user will always need access to 2 variations of a CoherentPtr

This is a contrast to const since for all const variables, casting away const is always a bad idea and almost always a source of bugs when passing around as parameters.

Coherence is much more comparable to atomic operations, "do we want the types to be atomic? Do we want per operation atomics?". Both approaches are used.

csyonghe · 2025-07-01T03:09:26Z

proposals/030-coherent-pointers.md

+
+### Additional Pointer Arguments
+
+`Volatile` and `Const` are planned features for `Ptr`.


Why Volatile when there is already coherent?

Volatile is functionally different than Coherent: "This access cannot be eliminated, duplicated, or combined with other accesses.".

Therefore Volatile is a potential future addition (although I doubt high priority).

csyonghe · 2025-07-01T03:12:45Z

proposals/030-coherent-pointers.md

+
+```c#
+__generic<T, CoherentScope coherentScope>
+typealias CoherentPtr = Ptr<T, AddressSpace::UserPointer, coherentScope>;


I think this should be:

typealias CoherentPtr<T> = Ptr<T, AddressSpace::UserPointer, MemoryScope::Device>;

For anything else, the user should just use Ptr<> type.

I wonder if we should move the AddressSpace::... param to the end of Ptr given this change (although this would make the change a breaking-change)?

csyonghe · 2025-07-01T03:13:24Z

proposals/030-coherent-pointers.md

+
+### Support Casting Pointers With Different `CoherentScope`
+
+We will allow pointers with different `CoherentPtr` to be explicitly castable to each other. For example, `CoherentPtr<int, CoherentScope.Device>` will be castable to `CoherentPtr<int, MemoryScope.Workgroup>`.


... with different CoherentScope to be explicitly...

csyonghe · 2025-07-01T03:13:42Z

proposals/030-coherent-pointers.md

+4. Support for coherent workgroup memory  
+5. Support for coherent cooperative matrix & cooperative vector  
+6. Support casting pointers with different coherent `MemoryScope`  
+7. Support the `globallycoherent` keyword


Probably delete 7.

We should make globallycoherent T* an error.

csyonghe

Looks good overall, some minor comments.

csyonghe · 2025-07-01T03:16:44Z

I think we want access to appear before coherency scope, so people can do Ptr<int, AddressSpace.Device, Access.Read> to refer to non-coherent, immutable pointer. So in the implementation, we may just want to put in the access parameter even when we don't implement it at first.

csyonghe · 2025-07-01T03:17:17Z

Perhaps we should just extend this proposal to also introduce access.

csyonghe · 2025-07-02T04:44:18Z

proposals/030-coherent-pointers.md

+    Subgroup = MemoryScope::Subgroup,
+    Invocation = MemoryScope::Invocation,
+    QueueFamily = MemoryScope::QueueFamily,
+    ShaderCallKHR = MemoryScope::ShaderCallKHR,


Remove "KHR".

removed 👍

add proposal

7f86c61

ArielG-NV requested review from tangent-vector, csyonghe and expipiplus1 as code owners June 12, 2025 01:20

ArielG-NV and others added 2 commits June 11, 2025 18:35

change header format

f1f0aa3

clear up the ext and cap needed for workgroup ptr's

ec22fab

csyonghe reviewed Jun 16, 2025

View reviewed changes

ArielG-NV added 2 commits June 16, 2025 16:33

add Volatile and Const as future work.

6d407ce

add future steps for syntax alias'ing

9650752

tangent-vector reviewed Jun 18, 2025

View reviewed changes

ArielG-NV and others added 3 commits June 24, 2025 15:59

address review and amend spec

6ad6192

Update 030-coherent-pointers.md

2c0a7eb

Update 030-coherent-pointers.md

38e4cf0

csyonghe reviewed Jul 1, 2025

View reviewed changes

ArielG-NV added 2 commits June 30, 2025 20:59

update spec

906ad05

clean up syntax

23f419d

ArielG-NV changed the title ~~#30 - Coherent Pointers Proposal~~ #30 - Coherent Pointers & Access Proposal Jul 1, 2025

ArielG-NV changed the title ~~#30 - Coherent Pointers & Access Proposal~~ #30 - Coherent Pointers & Pointer Access Proposal Jul 1, 2025

update spec changes: include access

59493c7

csyonghe reviewed Jul 2, 2025

View reviewed changes

remove KHR

e69a7e4

ArielG-NV mentioned this pull request Jul 7, 2025

[CBP] Create formal proposal for adding coherent operations through pointers shader-slang/slang#7408

Closed

csyonghe merged commit 9bc0fc0 into shader-slang:main Jul 9, 2025
1 check passed


		### Support The `globallycoherent` Keyword

		Slang will implement support for use of the `globallycoherent T*` keyword. This will be an alias to `Ptr<T, PointerFlags.Coherent, MemoryScope.Device>`.


		### Additional Pointer Arguments

		`Volatile` and `Const` are planned features for `Ptr`.


		### Support Casting Pointers With Different `CoherentScope`

		We will allow pointers with different `CoherentPtr` to be explicitly castable to each other. For example, `CoherentPtr<int, CoherentScope.Device>` will be castable to `CoherentPtr<int, MemoryScope.Workgroup>`.

#30 - Coherent Pointers & Pointer Access Proposal #24

#30 - Coherent Pointers & Pointer Access Proposal #24

Uh oh!

Conversation

ArielG-NV commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tangent-vector left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArielG-NV Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArielG-NV Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

csyonghe Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ArielG-NV Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

csyonghe left a comment

Choose a reason for hiding this comment

Uh oh!

csyonghe commented Jul 1, 2025

Uh oh!

csyonghe commented Jul 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ArielG-NV commented Jun 12, 2025 •

edited

Loading

ArielG-NV Jun 24, 2025 •

edited

Loading

ArielG-NV Jun 24, 2025 •

edited

Loading

csyonghe Jul 1, 2025 •

edited

Loading

ArielG-NV Jul 1, 2025 •

edited

Loading