-
Notifications
You must be signed in to change notification settings - Fork 148
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
Reflecting resource usage #99
Comments
Hi, The NON_WRITABLE / NON_READABLE has been raised before. But it's been over a year ago. The last time I visited this with @dneto0, I think the conclusion was that NON_READABLE was actually difficult to determine conclusively. I might be misremembering though. Regarding the 'accessed' member - by this do you mean block member variables? If that's the case Let me know if I missed something from your questions. |
Yep, I'm already using the accessed member. But that is just a boolean as far as I can tell. What I'd like though is for resources that can be both read from and written to such as storage images and storage buffers, information about whether the shader contains writes (imageStore() or assignment), or reads (imageLoad() or reads) from those storage image or buffers. |
To aid in making minimal memory buffers flag choices in Vulkan, it would be great to get more information from reflection about resource usage. I see there is already SPV_REFLECT_DECORATION_NON_WRITABLE. Having a SPV_REFLECT_DECORATION_NON_READABLE could be useful as well.
However even better would be if the 'accessed' member (or similar) could be more specific and say if a resources is written to, read from, or both, within a stage. This would be done based on actual potential usage vs. just the decoration hint. This would allow for more exact choices for src and dst access flags when creating my Vulkan memory barriers for an arbitrary shader.
Is this hidden anywhere right now, or would it be considered to be added?
Thanks for your consideration.
The text was updated successfully, but these errors were encountered: