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
I'd like to be able to use HLSL's InterlockedXYZ calls to do things like atomically compute bounding boxes, rasterize into grids, etc.
At the moment, GPRT uses Vulkan's raw device addressing capabilities to load and store data to and from memory. But these raw addresses aren't compatible with HLSL's interlocked calls, since those calls currently require a "Resource variable type" like a RWStructuredBuffer.
The text was updated successfully, but these errors were encountered:
natevm
changed the title
How to use atomics?
Current atomics scheme fail when users forget to update the shader binding table
Nov 3, 2023
Hitting an issue where if I launch a kernel using push constants and forget to update the shader binding table beforehand, gprt atomics silently fail. The reason for this is because we're computing buffer addresses and updating the corresponding descriptor set as part of the SBT build. When buffer handles are uploaded into the push constants structure, they return addresses that aren't available yet in the underlying variable length buffer descriptor set.
Another issue is that when an atomic operation is performed on a RWByteAddressBuffer, threads using the raw buffer load and store commands do not receive updates, since "globallycoherent" storage classes don't seem to be supported...
I'd like to be able to use HLSL's InterlockedXYZ calls to do things like atomically compute bounding boxes, rasterize into grids, etc.
At the moment, GPRT uses Vulkan's raw device addressing capabilities to load and store data to and from memory. But these raw addresses aren't compatible with HLSL's interlocked calls, since those calls currently require a "Resource variable type" like a RWStructuredBuffer.
The text was updated successfully, but these errors were encountered: