-
Notifications
You must be signed in to change notification settings - Fork 195
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
Ray Tracing Support (glsl->spv) #2289
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #2289 +/- ##
==========================================
- Coverage 81.96% 81.85% -0.12%
==========================================
Files 80 80
Lines 43312 43401 +89
==========================================
+ Hits 35502 35524 +22
- Misses 7810 7877 +67
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
@@ -861,6 +869,8 @@ pub struct GlobalVariable { | |||
pub space: AddressSpace, | |||
/// For resources, defines the binding point. | |||
pub binding: Option<ResourceBinding>, | |||
/// For some ray-tracing storage qualifiers, define the location | |||
pub location: Option<u32>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this need to work differently from the existing mechanism of passing locations? Currently, struct Binding
has a location, and it's carried for entry point inputs/outputs. The incoming ray payload should probably just be an argument to the entry point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moreover, we should probably consider just merging the IncompingRayPayload
address space into Input
, since it's non-ambiguous and likely has the same constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All new storage classes are somewhere between StorageQualifier::Output
and StorageQualifier::AddressSpace
.
They are read and write, have a location, no interpolation, no binding.
Additionally storage classes are mapped from AddressSpaces.
So StorageQualifier::AddressSpace
seemed to be the better fit.
A new StorageQualifier may even be best.
Hello, thank you for your PR against Naga! As part of gfx-rs/wgpu#4231, we have moved development of Naga into the wgpu repository in the Naga subfolder. We have transferred all issues, but we are unable to automatically transfer PRs. As such, please recreate your PR against the wgpu repository. We apologize for the inconvenience this causes, but will make contributing to both projects more streamlined going forward. We are leaving PRs open, but once they are transferred, please close the original Naga PR. |
Support for SPV_KHR_ray_tracing (includeng new shader stages)
from glsl to spir-v.
Requires: #2256
I will wait until Ray Query Support is merged, before I continue.