summaryrefslogtreecommitdiffstats
path: root/examples/model-viewer
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2018-11-12 09:57:46 -0800
committerGitHub <noreply@github.com>2018-11-12 09:57:46 -0800
commit039c233d9e4617ba9edd702a8275df0837ca8365 (patch)
tree75d22b74eb2e163bf5d57dc1a202b1b90aba10bd /examples/model-viewer
parentc07f60af241b1b0f7b7eba62c65d9fe750f8f3b7 (diff)
Add callable shader support for Vulkan ray tracing (#718)
* Add callable shader support for Vulkan ray tracing This change extends the previous work to update Vulkan ray tracing support for the finished `GL_NV_ray_tracing` spec. One of the features missing in the experimental extension that was added to the final spec is "callable shaders," which allow ray tracing shaders to call other shaders as general-purpose subroutines. Most of the implementation work here mirrors what was done for the `TraceRay()` function to map it to `traceNV()`. We map the generic `CallShader<P>` function to the non-generic `executeCallableNV`, with a payload identifier that indicates a specific global variable of type `P` (the global variable being generated from a `static` local in `CallShader`). A new modifier is added to identify the payload structure, and the parameter binding/layout logic introduces a new resource kind for callable-shader payload data (where previously the logic had assumed ray and callable payloads should use the same resource kind). Two test shaders are included: one for the callable shader (`callable.slang`) and one for a ray generation shader that calls it (`callable-caller.slang`). Just for kicks, the payload data type is defined in a shared file so that we can be sure the two agree (trying to emulate what might be good practice, and ensure that ray tracing support works together with other Slang mechanisms). * Typo fix: assocaited->associated One instance was found in review, but I went ahead and fixed a bunch since I seem to make this typo a lot. * Typo fix: defintiion->definition
Diffstat (limited to 'examples/model-viewer')
-rw-r--r--examples/model-viewer/shaders.slang4
1 files changed, 2 insertions, 2 deletions
diff --git a/examples/model-viewer/shaders.slang b/examples/model-viewer/shaders.slang
index 9b6538577..15ce0120d 100644
--- a/examples/model-viewer/shaders.slang
+++ b/examples/model-viewer/shaders.slang
@@ -155,7 +155,7 @@ struct SimpleMaterial : IMaterial
// To satisfy the requirements of the `IMaterial` interface, our
// material type needs to provide a suitable `BRDF` type. We
// do this by using a simple `typedef`, although a nested
- // `struct` type can also satisfy an assocaited type requirement.
+ // `struct` type can also satisfy an associated type requirement.
//
// A future version of the Slang compiler may allow the "right"
// associated type definition to be inferred from the signature
@@ -459,7 +459,7 @@ float4 fragmentMain(
// from different light sources.
//
// Note that the return type here is `TMaterial.BRDF`,
- // which is the `BRDF` type *assocaited* with the (unknown)
+ // which is the `BRDF` type *associated* with the (unknown)
// `TMaterial` type. When `TMaterial` gets substituted for
// a concrete type later (e.g., `SimpleMaterial`) this
// will resolve to a concrete type too (e.g., `SimpleMaterial.BRDF`