Support additional shader intrinsics

[Jasper-Bekkers]

Some of these are only available in specific shader stages and should error out in other stages (for example, calculating screenspace derivatives might be unavailable outside pixel shaders). Also some of these may need to add additional capablities (such as SubgropuBallotKHR).

Generic math functions

• Already documented in Intercept calls to (rust) libm and emit a builtin instead of the soft impl #81
• Possibly: OpDot & OpOuterProduct

Bit instructions

• OpBitFieldInsert
• OpBitFieldSExtract / OpBitFieldUExtract
• OpBitReverse
• OpBitCount

Fragment shader functions

• OpDPdx (done)
• OpDPdy (done)
• OpFwidth (done)
• OpDPdxFine (done)
• OpDPdyFine (done)
• OpFwidthFine (done)
• OpDPdxCoarse (done)
• OpDPdyCoarse (done)
• OpFwidthCoarse (done)
• OpKill (we may also want to take a look at OpDemoteToHelperInvocationEXT instead which is probably a nicer alternative depending on platform support; https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/EXT/SPV_EXT_demote_to_helper_invocation.asciidoc and [spirv] PR #2773 prevents usage of discard without SPV_EXT_demote_to_helper_invocation microsoft/DirectXShaderCompiler#2823)

Compute

• OpControlBarrier
• OpMemoryBarrier (see also Add barrier proposal #216)

Subgroup instructions

• Probably all of "3.37.21. Group and Subgroup Instructions" and "3.37.24. Non-Uniform Instructions", but if we want to start with a more limited set the following three are probably fine.
• OpSubgroupBallotKHR
• OpSubgroupFirstInvocationKHR
• OpSubgroupReadInvocationKHR

[khyperia]

Possibly: OpDot & OpOuterProduct

I'm confused. I thought you had the opinion that we should not add vector operation support (like add) because the componentwise operations are good enough - how are these different?

[Jasper-Bekkers]

I'm confused. I thought you had the opinion that we should not add vector operation support (like add) because the componentwise operations are good enough - how are these different?

Yeah that's why I marked them as optional; I think there might be some hw accelerated OpDot's out there but I think they're rare (old desktop parts or mobile gpus).

[khyperia]

"Subgroup instructions" sounds like a good first issue - relatively straightforward, use asm! to implement. Something like this (example for OpGroupAll, Scope = Workgroup), although I haven't compiled this or checked it at all, just pseudocode:

unsafe fn group_all_workgroup(x: bool) -> bool {
  #[cfg(not(target_arch = "spirv"))]
  panic!()
  #[cfg(target_arch = "spirv")]
  {
    let result;
    asm!(
      "%int = OpTypeInt 32 0",
      "%scope = OpConstant %int 2",
      "{1} = OpGroupAll typeof{0} %scope {0}",
      x, result
    );
    result
  }
}

(needs to be unsafe because of the requirement "Behavior is undefined if not all invocations of this module within Execution reach this point of execution.", higher-level safe abstractions could be built on top of this maybe?)

[khyperia]

Moving this to spirv-std since with asm!, it's mostly (entirely?) a library change