https://github.com/shader-slang/slang
Tip revision: 45ae0eb9ada14b8ead3c9785e16cc234a4d31ef0 authored by Yong He on 01 November 2021, 17:53:42 UTC
Disable aarch64 build for releases. (#2000)
Disable aarch64 build for releases. (#2000)
Tip revision: 45ae0eb
slang-capability-defs.h
// slang-capability-defs.h
// This file uses macros to define the capability "atoms" that
// are used by the `CapabilitySet` implementation.
//
// Any file that `#include`s this file is required to set
// the `SLANG_CAPABILITY_ATOM` macro before including it.
//
#ifndef SLANG_CAPABILITY_ATOM
#error Must define SLANG_CAPABILITY_ATOM before including.
#endif
//
// It is not necessary to `#undef` the macro in the client
// file, because this file will `#undef` it at the end.
// Our representation allows each capability atom to define
// a number of other base atoms that it "inherits" from.
//
// Different atoms will need different numbers of bases,
// so we will define a few different macros that wrap
// `SLANG_CAPABILITY_ATOM` and let us handle the cases
// more conveniently.
//
// TODO: There is probably a way to handle this with
// variadic macros.
//
#define SLANG_CAPABILITY_ATOM4(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1, BASE2, BASE3) \
SLANG_CAPABILITY_ATOM(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1, BASE2, BASE3)
#define SLANG_CAPABILITY_ATOM3(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1, BASE2) \
SLANG_CAPABILITY_ATOM(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1, BASE2, Invalid)
#define SLANG_CAPABILITY_ATOM2(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1) \
SLANG_CAPABILITY_ATOM(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, BASE1, Invalid, Invalid)
#define SLANG_CAPABILITY_ATOM1(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0) \
SLANG_CAPABILITY_ATOM(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, BASE0, Invalid, Invalid, Invalid)
#define SLANG_CAPABILITY_ATOM0(ENUMERATOR, NAME, KIND, CONFLICTS, RANK) \
SLANG_CAPABILITY_ATOM(ENUMERATOR, NAME, KIND, CONFLICTS, RANK, Invalid, Invalid, Invalid, Invalid)
// Several capabilities represent the target formats in which we generate code.
// Because we can only generate code in one format at a time, all of these are
// marked as conflicting with one another along the `TargetFormat` axis.
//
// Note: We are only including here the source code formats we initially generate
// code in and not the formats that code might be translated into "downstream."
// Trying to figure out how to integrate both kinds of formats into our capability
// system will be an interesting challenge (e.g., can we compile code for `hlsl+spirv`
// and for `glsl+spirv` or even just for `spirv`, and how should all of those impact
// overloading).
//
SLANG_CAPABILITY_ATOM0(HLSL, hlsl, Concrete,TargetFormat,0)
SLANG_CAPABILITY_ATOM0(GLSL, glsl, Concrete,TargetFormat,0)
SLANG_CAPABILITY_ATOM0(C, c, Concrete,TargetFormat,0)
SLANG_CAPABILITY_ATOM0(CPP, cpp, Concrete,TargetFormat,0)
SLANG_CAPABILITY_ATOM0(CUDA, cuda, Concrete,TargetFormat,0)
SLANG_CAPABILITY_ATOM0(SPIRV_DIRECT, spirv_direct, Concrete, TargetFormat, 0)
// We have multiple capabilities for the various SPIR-V versions,
// arranged so that they inherit from one another to represent which versions
// provide a super-set of the features of earlier ones (e.g., SPIR-V 1.4 is
// expressed as inheriting from SPIR-V 1.3).
//
SLANG_CAPABILITY_ATOM1(SPIRV, __spirv, Abstract,None,0, GLSL)
SLANG_CAPABILITY_ATOM1(SPIRV_1_0, spirv_1_0, Concrete,None,0, SPIRV)
SLANG_CAPABILITY_ATOM1(SPIRV_1_1, spirv_1_1, Concrete,None,0, SPIRV_1_0)
SLANG_CAPABILITY_ATOM1(SPIRV_1_2, spirv_1_2, Concrete,None,0, SPIRV_1_1)
SLANG_CAPABILITY_ATOM1(SPIRV_1_3, spirv_1_3, Concrete,None,0, SPIRV_1_2)
SLANG_CAPABILITY_ATOM1(SPIRV_1_4, spirv_1_4, Concrete,None,0, SPIRV_1_3)
SLANG_CAPABILITY_ATOM1(SPIRV_1_5, spirv_1_5, Concrete,None,0, SPIRV_1_4)
// The following capabilities all pertain to how ray tracing shaders are translated
// to GLSL, where there are two different extensions that can provide the core
// functionality of `TraceRay` and the related operations.
//
// The two extensions are expressed as distinct capabilities that both are marked
// as conflicting on the `RayTracingExtension` axis, so that a compilation target
// cannot have both enabled at once.
//
// The `GL_EXT_ray_tracing` extension should be favored, so it has a rank of `1`
// instead of `0`, which means that when comparing overloads that require these
// extensions, the `EXT` extension will be favored over the `NV` extension, if
// all other factors are equal.
//
SLANG_CAPABILITY_ATOM1(GLSLRayTracing, __glslRayTracing, Abstract,None,0, GLSL)
SLANG_CAPABILITY_ATOM1(GL_NV_ray_tracing, GL_NV_ray_tracing, Concrete,RayTracingExtension,0, GLSLRayTracing)
SLANG_CAPABILITY_ATOM2(GL_EXT_ray_tracing, GL_EXT_ray_tracing, Concrete,RayTracingExtension,1, GLSLRayTracing, SPIRV_1_4)
#undef SLANG_CAPABILITY_ATOM0
#undef SLANG_CAPABILITY_ATOM1
#undef SLANG_CAPABILITY_ATOM2
#undef SLANG_CAPABILITY_ATOM3
#undef SLANG_CAPABILITY_ATOM4
#undef SLANG_CAPABILITY_ATOM