-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Construct OpAccessChains
for RawBufferLoad
properly, or overhaul the API
#4986
Comments
I don’t see what the issue with casting is. It is within the SPIR-V specification that OpBitcast can be used to convert integers into pointers. Further, I see correct runtime behavior with both raw buffer load and store, on Intel, NVIDIA and AMD GPUs. Can you articulate what exactly the advantage would be in switching from the bitcast to the OpAccessChain pattern here? |
The You will see correct behaviour*, but its up to the Driver SPIR-V to internal IR lowering compiler whether these loads and stores will get optimized. This is functionally identical to GLSLTest* v36;
float v38;
Test v37 = *v36;
v38 = v37.mem2; HLSLTest* v24;
float v28;
v28 = v24->mem2; *Now imagine I wanted to do a read-modify write on a coherent/volatile pointer. |
Wrt atomics, I’ve outlined in my issue how such behavior would work, and it certainly would work if the SPIR-V spec is to be believed… Simply use the OpAtomicCompareExchange instruction… With a static single assignment compiler like LLVM, I don’t see why these cases couldn’t be trivially optimized. |
yes they can be optimized, but the SPIR-V can't be, you'll be doing an Also for atomics you just simply wouldn't be able to perform one within the confines of the current AST/compiler, without doing your own pointer arithmetic to find the Which wont get optimized away if someone throws coherent/volatile into the mix on them. Anyway I see that this issue should be a part of #4289 |
Currently users do their own arithmetic on addresses with the raw buffer calls, as HLSL does not support pointer types. I’m confused by what you mean this can’t be done re atomics. I can quite literally emit the SPIR-V described in my issue and the atomic compare and exchange works just fine on a raw device address to an integer. |
Is this related to this issue ? vk::RawBufferLoad for some reason compiles differently from ByteAddressBuffer.Load in dxc. |
There's actually this repo from LunarG which proposes a [in my opinion beautiful] syntax change Which will actually emit the proper |
What’s the proposed syntax change? Doing a quick glance at the link you provided, I can’t seem to find it… |
I’ve ran into a similar issue storing structs of data to memory, but have found it depends on the GPU vendor. Intel Arc properly handles structure storage with the current (non-opchain) approach, but NVIDIA produces the errors described in the issue you mention, and AMD crashes altogether. I worry opchains aren’t going to fix driver bugs. Maybe storing fields one by one in a struct would solve some of these issues, but I’ve also ran into a crash on AMD when attempting to store float4x4’s and float3x4s. |
I was given some examples privately by the author, but would need to check if its okay to share them. |
Yes, by all means, feel free to share. All the samples are sharable. One is derived from Baldur Karlson's demo of VK_EXT_Buffer_Address in his RenderDoc repo. He used a GLSL shader. I tried to keep my HLSL-based design close to what is in GLSL. |
I am close to trying to merge that branch. I just have one more detail to implement: the buffer reference alignment. |
[[vk::buffer_ref(16)]] typedef struct Globals_s
{
float4 g_vSomeConstantA;
float4 g_vTestFloat4;
float4 g_vSomeConstantB;
} Globals_t;
struct TestPushConstant_t
{
Globals_t m_nBufferDeviceAddress;
};
[[vk::push_constant]] TestPushConstant_t g_PushConstants;
float4 MainPs(void) : SV_Target0
{
float4 vTest = g_PushConstants.m_nBufferDeviceAddress.g_vTestFloat4;
return vTest;
} produces:
|
Here are other samples Greg sent me... |
@greg-lunarg do you have any tests & examples of SPIR-V emitted if I try to do something funky like atomics? P.S. Also where would I put my |
I haven't looked at atomics or StructuredBuffers yet. If you can point me to some sample shaders and what you want to do I might be able to give some ideas. |
I'm going to withdraw my suggestion to fix this with
as it looks pretty ironed out in proposal microsoft/hlsl-specs#84 and we just need the proposal implemented. |
Glslang with
GL_EXT_buffer_reference
DXC with
vk::RawBufferLoad<Test>(addr).mem2
Now imagine I declared a large array for histogram or something as a member variable.
This is probably a dup of some issue (searched but couldn't find it in the ocean of open SPIR-V issues), since I'm certainly not the first person to discover this.
My suggestion to fix this is
or whatever else you're able to craft with the AST privilaged access you have, such as working out the
OpAccessChain
while looking at AST branch the.
member operators will emit.The text was updated successfully, but these errors were encountered: