Possible SpirV compilation pipeline

[leios]

Ok, this is an info dump, but I think this is the ideal path forward for Fable performance and also fixes #66 .

Ideally we...

• [ ] Use the @fum macro to siphon out the function bodies and create large function bodies like before the #64 update; however, we will also allow for configurable keyword arguments so we do not need to recompile the function too many times for dynamic scenes.
• [ ] Compile this to SpirV using some form of compute shader (note that we want to use the graphics pipeline if possible)
  • Try to compile directly to a GLSL string and then compile with a GLSLangValidator.jl (or something)?
  • Also note that this strategy is similar to what needs to be done for oneAPI.jl: https://github.com/JuliaGPU/oneAPI.jl/blob/master/src/compiler/compilation.jl
• [ ] Pass that SpirV to Vulkan(.jl)
• [ ] Find a way to wrap a window library (whatever Makie / Plots use or maybe GLFW) for dynamic / realtime output.

Note that this will remove the dependencies on KernelAbstractions and any GPU vendor because we can rely on Vulkan for these steps, which would greatly reduce precompile time and hopefully speed up the process for PkgCompiler so we could make executables (games?) with this application.

[leios]

It might be interesting to look at what OneAPI.jl does already for the OpenCL -> SPIRV compiler. Then pass that to vulkan(.jl)?

Keep in mind that this is essentially LLVM -> SPIRV, which means you still need to go through LLVM, which is currently part of the issue.

The only real way would be to find a way to create SPIRV IR in Julia (emit_spirv, similar to emit_llvm)

[leios]

Note that by switching to vulkan / spirv, we lose Enzyme AD, which could be a really important step.

Instead, it might be better to do interop for realtime visualizations:

1. https://github.com/ROCm/rocm-examples/tree/develop/HIP-Basic/vulkan_interop
2. https://github.com/NVIDIA/cuda-samples/tree/master/Samples/5_Domain_Specific/vulkanImageCUDA