slang.git/tests/vkray/callable.slang, branch master

Defer immutable buffer loads when emitting spirv. (#7579)

2025-07-02T02:09:29+00:00

* Defer immutable buffer loads when emitting spirv. * Fix. * Fix. * Fix. * Fix tests. * Fix test.

Update spirv-header and spirv-tools to Jun/2024 (#4679)

2024-07-18T20:21:12+00:00

The following external directories are updated. It is to use a new SPIRV keyword, "OpExtInstWithForwardRefs". Related to #4304 external/spirv-header: > commit 2acb319af38d43be3ea76bfabf3998e5281d8d12 > Author: Kévin Petit kevin.petit@arm.com > Date: Wed Jun 12 16:41:14 2024 +0100 > SPV_ARM_cooperative_matrix_layouts (#433) external/spirv-tools: > commit ce46482db7ab3ea9c52fce832d27ca40b14f8e87 > Author: Nathan Gauër brioche@google.com > Date: Thu Jun 6 12:17:51 2024 +0200 > Add KHR suffix to OpExtInstWithForwardRef opcode. (#5704) > The KHR suffix was missing from the published SPIR-V extension. > This is now fixed, but requires some patches in SPIRV-Tools. external/spirv-tools-generated: This is generated from spirv-tools

Improve Direct SPIRV Backend Test Coverage (#4396)

2024-06-14T16:56:59+00:00

'raytracing' and 'texture-footprint' tests fixed texture-footprint bug changed when we emit raytracing/rayquery extensions with glsl backend (to reduce incorrect extension emitting)

Switch to direct-to-spirv backend as default. (#4002)

2024-04-23T19:14:21+00:00

* Switch to direct-to-spirv backend as default. * Fix slang-test. * Fix. * Fix.

Add all RayQuery SPIRV Intrinsics. (#3204)

2023-09-13T16:48:32+00:00

* Add all RayQuery SPIRV Intrinsics. * Fix * Fix. * fix. * Fix. * Fix. * Fix. --------- Co-authored-by: Yong He

Use "capability" system to select VKRT extension (#1647)

2021-01-05T17:00:00+00:00

* Use "capability" system to select VKRT extension Slang currently supports translation of ray tracing shader code to Vulkan GLSL code that uses the `GL_NV_ray_tracing` extension. A multi-vendor equivalent of that extension has been released as `GL_EXT_ray_tracing` and we want Slang to support that extension as well. At the simplest, making the change from one extension to the other is just a matter of changing a few strings, since it does not appear that anything of significance was changed at the GLSL level (or even in SPIR-V). Where this gets trickier is when we have users who want us to support *both* extensions, and to be able to switch between them. The solution we've implemented here more or less amounts to: * If you don't tell the compiler which extension to use, it will default to `GL_EXT_ray_tracing` (the newer multi-vendor one). * If you explicitly want the older extension, you can opt into it using the `-profile` option or via a new API for explicitly adding capabilities to your target. Making that work required a few different kinds of changes: * The options parsing and public API needed ways to add optional capabilities to a target. * During GLSL code emit, we can check the capabilities that were added to the target to see if the `GL_NV_ray_tracing` extension was explicitly enabled and, if not, default to using the `GL_EXT_ray_tracing` names for things. This step is needed because some of the modifiers/attributes involved in the extension have to be handled explicitly in the code generator rather than implicitly as part of mapping intrinsic functions. * We add two different translations to the relevant operatiosn in the stdlib, one marked with each of the extensions. If profile/capability-based overload resolution can be relied on to pick the right one, this should Just Work. * Next, a bunch of work had to go into making capability-based overloading Just Work for the purposes of this change. There's been a nearly complete reworking of the implementation of `CapabilitySet` here to make it more suitable for our needs. * The tests that were using ray tracing translation for Vulkan needed to be updated. For some of them I updated their baselines to use `GL_EXT_ray_tracing` so that they can test the new path. For others, I updated the command line for the test case so that it explicitly opts into using `GL_NV_ray_tracing`. The result is that we have some coverage of each extension. I would have liked to have each test run in both modes, but our pass-through glslang support doesn't support `-D` options, so I couldn't take that step easily. This change does *not* add support for `GL_EXT_ray_query`, the extension that supports "DXR 1.1" style queries under Vulkan. Adding support for that extension should hopefully be a smaller step because it doesn't have the same multiple-extensions issue. This change does *not* address a lot of possible avenues for improvement or cleanup around the capability system. It focuses only on those changes that are necessary to make the ray tracing feature work and leaves the rest for future work. * fixup: infinite loop * Comment-only change to retrigger TC build

Add callable shader support for Vulkan ray tracing (#718)

2018-11-12T17:57:46+00:00

* 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

` 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