Specify aliasing and address space for vk::BufferPointer#53
Conversation
s-perron
left a comment
s-perron
left a comment
There was a problem hiding this comment.
I think this needs to be expanded a little. As stated, it would be nearly impossible to write a vaild program because any copy of a buffer pointer breaks the rules.
|
|
||
| ### Buffer Pointers and Aliasing | ||
|
|
||
| All buffer pointers are considered restricted pointers. In other words, given two different objects of buffer pointer type, it is assumed that their pointees do not overlap by default. |
There was a problem hiding this comment.
In other words, given two different objects of buffer pointer type, it is assumed that their pointees do not overlap by default.
This definition is too general. I think you need to define something like the "base", as you mentioned in #42 (comment).
The WGSL spec does this well. The call it the "root identifier" instead.
Don't try to stick too close to the spir-v aliasing rules. They need to be updated: https://gitlab.khronos.org/spirv/SPIR-V/-/issues/731
There was a problem hiding this comment.
You might also simply reference the C standard for the definition of restrict to make it more precise.
There was a problem hiding this comment.
Firstly, sorry for the delayed response. I will try to respond in a more timely fashion going forward.
I think this needs to be expanded a little. As stated, it would be nearly impossible to write a valid program because any copy of a buffer pointer breaks the rules.
It is not having copies of pointers that breaks the rules. It is dereferencing the copies in a way that depends on them overlapping that breaks the rules.
So my question is: is there a useful graphics shader that cannot be written when disallowing aliasing between "different" pointer values?
There was a problem hiding this comment.
If we decide that allowing aliasing between "different" pointer values is necessary, then I would allow aliasing only in the following cases:
-
Dereferences from the same named pointer variable or member of a named buffer.
-
Dereferences from a cast of the same named uint64_t variable or member of a named buffer to the same buffer pointer type.
-
Create an attribute vk::aliased which can be applied to a variable or member. Any dereferences from such pointers are assumed to be aliased.
There was a problem hiding this comment.
I think we are talking past each other. In general, I think we agree on what should happen, we just disagree that the current wording captures what you want. I find the single sentence
In other words, given two different objects of buffer pointer type, it is assumed that their pointees do not overlap by default.
to simplistic to capture a concept that the C standard felt needed to be must more involved. See https://en.cppreference.com/w/c/language/restrict.
I would suggest you ignore my first comment in this thread, and do the second one. Reference the C99 standard of the restrict type qualifier to define restrict.
Something like
By default, buffer pointers are assumed to be restrict pointers as defined by the C99 standard.
should be good enough.
|
@llvm-beanz Anything else needed here? |
|
|
||
| ### Buffer Pointers and Address Space | ||
|
|
||
| All buffer pointers are presumed to point into the same address space. No new address space attributes are proposed. |
There was a problem hiding this comment.
Which address space? The default address space in HLSL is thread-local memory, which I assume isn't where these are expected to refer. I assume these are host memory, so we should state that explicitly.
* 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.
3 participants
Fixes #42.