I have a specific set of shaders that, when thrown at vkCreateGraphicsPipeline, hang somewhere deep in the AMD driver on an RX480 (this problem might also exist on other GPUs, but I haven't tested that yet). This happens with the latest drivers (as of June 15th 2018).
The same code works just fine with a lot of other shaders, so I'm reasonably certain that the pipeline I'm trying to create is in fact valid and not something bogus. I have also tried running it with and without supplying the specialization constants, nothing seems to make a difference. Now the interesting part is that this very same SPIR-V shader, when compiled for OpenGL consumption, _also_ hangs the AMD driver, this time in glLinkProgram. I took a look at the shader input and output stages, but it appears that all locations match up nicely, including the underlying types.
Unfortuantely it's not very easy to get any kind of insight on what exactly the driver is sad about. The shader itself was compiled with glslang and it passes the validation from the SPIRV-Tools, so in theory it should be all good. When I transpile the SPIR-V back to GLSL it actually does work in our OpenGL renderer, which further seems to point towards some mismatched shader interface.
I have attached both the vertex and fragment shaders. Maybe someone with more experience can either take a look at them and point out what is going wrong, or if anybody knows of some good tooling to inspect SPIR-V shaders in some easy way, I'd also love to hear about that.
