SPIR-V backend

[Corillian]

I haven't been able to find a way to PM @johnkslang nor any forums or anything where compiling to SPIR-V is being discussed so this is as much a question as an issue. As far as I can tell it looks like LunarGLASS doesn't provide a way to compile to SPIR-V and the only way to do so at the moment is through glslang. Going through the glslang source it doesn't look like it performs any sort of optimization which isn't entirely surprising given that it's a reference implementation. My issue/question is whether or not a SPIR-V backend is planned for LunarGLASS? My interpretation of the LunarGLASS documentation is that it will be the full, production quality optimizing compiler for Vulkan however it looks like it's still very much a work in progress. I suppose I could run GLSL through LunarGLASS and then pipe the optimized output GLSL back through glslang in the interim?

[johnkslang]

The only graphics-specific path here so far is glslang[GLSL] -> SPIR-V[non-optimized] -> LLVM[optimized].

For OpenCL, there is also a round-trip path using clang/LLVM to create SPIR-V.

There is certainly room for lots of interesting work to happen here...!

[greg-lunarg]

To summarize, we are not aware of any planned efforts for a SPIR-V backend for LunarGLASS. As for "optimized" SPIR-V, spirv-remap (in glslang) does some very rudimentary optimizations (dead code elimination, store/load optimization, stripping of names and other debug info). Your mileage may vary.

[Corillian]

Maybe I'm missing something but I don't understand why you guys wouldn't be planning a SPIR-V backend. Isn't the point of LunarGLASS to provide a compiler toolchain for shaders which ultimately must end with SPIR-V? It seems a bit odd and in no way obvious that the anointed path for compiling shaders would be glslang -> LunarGLASS -> glslang -> Final shader SPIR-V. I'm pretty amazed that the Vulkan SDK doesn't come with a way to call something like VkCompileShader(...) to get an optimized SPIR-V blob when both D3D and OpenGL (sort of) have supported this for years.

[gzorin]

What do you think would be a more fruitful path to take to pursue such interesting work - writing a new backend for LunarGLASS that targets SPIR-V, or adding bits to SPIRV-LLVM to emit SPIR-V for graphics devices? (Or do I misunderstand SPIRV-LLVM - is that project only intended to produce OpenCL-like programs?)

[johnkslang]

I think it's a pretty valuable path to pursue, to have a graphics-non-lossy path like glslang -> SPIR-V -> LunarGLASS -> SPIR-V.

Reopening to track the possibility of doing this.

[Corillian]

It seems like LunarGLASS and SPIRV-LLVM (which I had previously been unaware of) should be merged, I don't know what the advantage of maintaining 2 separate LLVM stacks is? Looking at Anandtech's benchmarks for The Talos Principle (http://www.anandtech.com/show/10047/quick-look-vulkan-performance-on-the-talos-principle) they seem to clearly indicate the game is fill rate limited in all 3 rendering paths. If we assume that the GLSL shaders are a 1:1 port from D3D11 HLSL then it seems like the significant performance differential can likely be explained by a lack of shader optimization in the Vulkan rendering path.

A ~50% performance hit due to lack of shader optimization is quite serious in my opinion and it's concerning that Khronos has shipped Vulkan without a clear roadmap for solving this problem.

[CommanderAlchemy]

@Corillian Um their Vulkan renderer is quite underdeveloped to even try to compare it to D3D11 is to early. Check the notes that the devs themselves posted about their current status of the Vulkan renderer. It's not even using threads (something that their D3D11 path does) same goes for allot more featues that are missing since they just did a fast implementation.

[Corillian]

As I mentioned before the game appears to be fill rate limited - this does not suggest a problem with the API. Is it possible that the entire perf hit is due to problems with a lack of optimization in the beta driver compiler when going from SPIR-V to ISA? Yes however that seems unlikely given that we see similar problems with fill rate in the OpenGL benchmark. Coincidentally they're nearly identical. The more likely culprit is the lack of optimization in the GLSL -> SPIR-V compiler which is reinforced by the fact that OpenGL skips that step and D3D11's HLSL compiler doesn't. Lastly if you look at the glslang source code, which is the compiler that ships with the Vulkan SDK, you'll notice that it does little to no optimization. Most people probably don't even know that LunarGLASS exists.

[redorav]

I'm surprised that after a year since the introduction of Vulkan this problem remains when other APIs provide such a clear shader optimization pipeline. As has been mentioned before, glslang produces very straightforward, suboptimal shaders (as is the idea) but there is no tool that will perform even the most basic passes directly on SPIRV. Some of our code relies on being able to detect which interpolants are being used, and all other APIs (DirectX, all consoles, the already quite old Cg compiler) can do this almost trivially. I wanted to ask whether LunarGLASS is going to be continued/expanded on, or the plan is to concentrate the optimization efforts on spirv-opt from now on.

[greg-lunarg]

LunarG is currently being contracted to add size reduction optimizations to spirv-opt. They are documented in issues 537-542 at github.com/KhronosGroup/SPIRV-Tools.

Issue 537 (the inliner) has just recently been delivered. The inliner is intended to enable analysis and optimization across function calls by the subsequent passes.

The remaining functionality is implemented in a private branch and will be rolled out over the following weeks. When complete, it will eliminate all function scope variables and references that are not dynamically indexed. It will also perform dead code and dead control flow elimination and consolidate uniform memory accesses.

Adding a SPIR-V backend to LunarGLASS is not planned at this time.

There is discussion of SPIR-V at this week's LLVM Developers conference: https://eurollvm2017.sched.com/event/9wE6/spir-v-and-its-place-in-the-llvm-ecosystem

[redorav]

Adding a SPIR-V backend to LunarGLASS is not planned at this time.

Thank you, that's what I wanted to know. I'll follow the progress of spirv-opt in that case. Do we have an estimated timeframe on when the features will be rolled out?

Thank you for the link as well, I'll have to wait till the slides/videos are up to be able to see them but it certainly looks interesting.

[greg-lunarg]

Do we have an estimated timeframe on when the features will be rolled out?

Over the next month or so.