If RetroArch only accepts SPIR-V, we would need an explicit build step outside RetroArch first before we could We could also have this metadata outside in a separate file, but juggling more files means more churn, which we should try to avoid. Outside writing custom tools to emit special metadata as debug information or similar with OpSource.
![retroarch border shaders retroarch border shaders](https://retropie.org.uk/forum/assets/uploads/files/1541175050845-before-resized.jpg)
In GLSL, we can quite easily extend with custom #pragmas or similar, but there is no trivial way to do this in SPIR-V This was considered, but there are several convenience problems with having a shading spec around pure SPIR-V.
![retroarch border shaders retroarch border shaders](https://docs.libretro.com/image/shader/shaders-presentation.png)
Which effectively means we can completely sidestep all our current problems with a pure GLSL based shading system.Īnother upside of this is that we no longer have to deal with vendor-specific quirks in the GLSL frontend.Ī common problem when people write for nVidia is that people mistakingly use float2/float3/float4 types from Cg/HLSL, which is supported We can also disassemble back to our desired GLSL dialect in the GL backend based on which GL version we're running, Using, we can then do reflection on the SPIR-V binary to deduce our filter chain layout. which compiles our Vulkan GLSL to SPIR-V. In runtime, we can have a vendor-neutral mature compiler, The good part is that we can use whatever GLSL version we want when writing shaders, as it is decoupled from the GL runtime. Vulkan GLSL is a GLSL dialect designed for Vulkan and SPIR-V intermediate representation. We also want to avoid having to write pseudo-GLSL with some text based replacement behind the scenes.įortunately, there is now a forward looking and promising solution to our problems. We do not want to litter every shader with heaps of #ifdefs everywhere to combat this problem. The problem really is that GLSL shaders are dependent on the runtime GL version, which makes it very annoying and hard to test all shader variants. Lack of standard support for #include to reduce copy-pasta.texture2D vs texture (legacy vs modern).varying/attribute vs in/out (legacy vs modern).We also cannot do the Cg transform in runtime on mobile due to lack of open source Cg runtime, so there's that as well.Īnother alternative is to write straight-up GLSL, but this too has some severe problems.Īll the different GL versions and GLSL variants are different enough that it becomes painful to write portable GLSL code that works without modification. The output is so horribly mangled and unoptimized that it is clearly not the approach we should be taking. It has many warts which are heavily tied in to legacy APIs and systems.įor this reason, we cannot use Cg for newer APIs such as Vulkan and potentially D3D12 and Metal.Ĭg cross compilation to GLSL is barely working and it is horribly unmaintainable with several unfixable issues. This is very problematic since Cg is not a forward compatible platform.
![retroarch border shaders retroarch border shaders](https://forums.libretro.com/uploads/default/original/2X/e/e3ddb57e28c08b195248c08afb6e528924fe7294.jpeg)
Up until now, we have relied on nVidia Cg to serve as a basic foundation for shaders, but Cg has been discontinued for years and is closed source. There was no good ready-made solution for this. The current state of writing high-level shading languages that work "everywhere" is very challenging. While it has served us well, it is not forward-compatible. The current shader subsystem in RetroArch is quite mature with a large body of shaders written for it.