As an intermediate representation, there is not much you can do with SPIR-V by itself. With any intermediate representation, there is a whole ecosystem around it for tools that both input and output SPIR-V.
)
SPIR-V is the language for Vulkan shaders. The Vulkan-Guide goes over in detail how to map data in Vulkan to the SPIR-V module.
Within the Vulkan specification:
- Appendix A: Vulkan environment for SPIR-V defines requirements for SPIR-V modules when used with Vulkan. For example, it limits what SPIR-V capabilities are supported by Vulkan.
- Section 14. Shader Interfaces defines how data gets into and out of a Vulkan shader, and how those interfaces are expressed in SPIR-V. It also specifies interface matching rules for shaders combined in a single pipeline.
- Many Vulkan extensions add shader features. Such a feature is paired with a corresponding SPIR-V extension. Sometimes the entire content of a Vulkan extension is to enable features from a SPIR-V extension, or to enable a newer version of SPIR-V itself.
- Appendix B: Memory Model
defines a memory consistency model: a detailed specification of how to reason about
concurrent reads and writes to storage, and how to correctly synchronize those accesses.
The model spans both actions in the API, and also operations SPIR-V shaders.
This model is optional in Vulkan versions 1.0, 1.1, and 1.2, and is enabled by opting into
the
VK_KHR_vulkan_memory_modelVulkan extension, and using theVulkanKHRmemory model within a SPIR-V module.
With an increasing number of OpenCL run-times supporting ingestion of SPIR-V, OpenCL developers may wish to use offline compilation to precompile SPIR-V kernels that can be used portably across multiple OpenCL implementations.
There are also projects such as clspv which compile OpenCL C kernels to SPIR-V modules for use with Vulkan. More information can be found from the 2017 Siggraph BOF Presentation (video and slides) and 2018 Siggraph (video and slides)