Vulkan 1.0.9 Specification Released

[Azpegath]

One of the "wouldn't it be nice if..." goals that resurfaces every few years (and with every new stack) is the idea of producing highly optimized IR that can be easily turned into optimized ISA without requiring a full-blown shader compiler. I don't think it's ever worked out particularly well but that seems to be what the first discussion link seems to want.

The problem is that the original poster seems to be telling people that "optimized SPIR-V" is the only way to improve shader performance on the current Vulkan implementations, which I think is just plain wrong but my compiler-fu is pretty weak. What I don't like is the way the overall perception seems to be going:

- Anandtech benchmarks day-one Vulkan implementations with Talos, finds what one developer interpreted as shader performance problems

- other people then started saying "we need optimized SPIR-V, are you doing X ?" (where X doesn't really make sense), LunarG says "no" to generating SPIR-V as the output from LunarGLASS because it doesn't really make sense (LunarGLASS is about producing optimized ISA via a HW-architecture-optimized lower level IR).

- game developers see this discussion and think "gee maybe I should use DX12 and only run on Windows 10"

- nobody seems to be noticing that even a week or two after NDA lift the drivers are improving significantly

What bothers me is that all the discussions seem to be incredibly fact-free, and are all based on first-day drivers and a partially ported game. I doubt the guys who ported Talos to Vulkan were expecting that their initial "get it lighting up" porting step, tested with day-one drivers, would become the foundation of the whole world's perception fo Vulkan.

I agree, very well put. I was at GDC and visited all the Vulkan presentations and discussions, and something that surprised me was the whold sense of uncertainty about "will this take off?". Especially the second day panel discussion with Epic, Google, Imagination and CroTeam. I recommend watching it if it has been released, Niklas from Epic and Dean from CroTeam had very interesting things to say about their experiences. They both did presentations later in the week that were even better, focusing on what the work had been like.

[norsetto]

well, i mostly know IR from .Net and other languages. and not one does it ever implement optimization on IR level. it just doesn't make sense since beside basic, there is not even a remote guarantee same optimization would perform well everywhere. this is always left to last stage.

whole generic IR optimizations are more or less same pipe dream.

I was reading this just yesterday (http://www.aosabook.org/en/llvm.html) and I understood that a first optimization in llvm is done at the IR level. Still, I would expect some form of optimization to take place in the last compilation step as in principle during the IR processing phase one would know nothing about the target hardware.
I must admit this whole Vulkan rigmarole is quite above my head right now, I dream of the day I may have drivers available on my machine so that I can start tinkering around...

[justmy2cents]

One of the "wouldn't it be nice if..." goals that resurfaces every few years (and with every new stack) is the idea of producing highly optimized IR that can be easily turned into optimized ISA without requiring a full-blown shader compiler. I don't think it's ever worked out particularly well but that seems to be what the first discussion link seems to want.

The problem is that the original poster seems to be telling people that "optimized SPIR-V" is the only way to improve shader performance on the current Vulkan implementations, which I think is just plain wrong but my compiler-fu is pretty weak. What I don't like is the way the overall perception seems to be going:

- Anandtech benchmarks day-one Vulkan implementations with Talos, finds what one developer interpreted as shader performance problems

- other people then started saying "we need optimized SPIR-V, are you doing X ?" (where X doesn't really make sense), LunarG says "no" to generating SPIR-V as the output from LunarGLASS because it doesn't really make sense (LunarGLASS is about producing optimized ISA via a HW-architecture-optimized lower level IR).

- game developers see this discussion and think "gee maybe I should use DX12 and only run on Windows 10"

- nobody seems to be noticing that even a week or two after NDA lift the drivers are improving significantly

What bothers me is that all the discussions seem to be incredibly fact-free, and are all based on first-day drivers and a partially ported game. I doubt the guys who ported Talos to Vulkan were expecting that their initial "get it lighting up" porting step, tested with day-one drivers, would become the foundation of the whole world's perception fo Vulkan.

well, i mostly know IR from .Net and other languages. and not one does it ever implement optimization on IR level. it just doesn't make sense since beside basic, there is not even a remote guarantee same optimization would perform well everywhere. this is always left to last stage.

whole generic IR optimizations are more or less same pipe dream.

what bothers you... bothers more or less everyone who even a little thought about the problems and as i already said in one of my posts, the original poster lacks facts and cites all the wrong things

[bridgman]

wouldn't it be just wrong the other way? some basic things like removing dead code could maybe belong in SPIR-V. but, the rest vendors know best. then again, what is the worth of implementing just few? to throw marketing smoke grenade?

One of the "wouldn't it be nice if..." goals that resurfaces every few years (and with every new stack) is the idea of producing highly optimized IR that can be easily turned into optimized ISA without requiring a full-blown shader compiler. I don't think it's ever worked out particularly well but that seems to be what the first discussion link seems to want.

The problem is that the original poster seems to be telling people that "optimized SPIR-V" is the only way to improve shader performance on the current Vulkan implementations, which I think is just plain wrong but my compiler-fu is pretty weak. What I don't like is the way the overall perception seems to be going:

- Anandtech benchmarks day-one Vulkan implementations with Talos, finds what one developer interpreted as shader performance problems

- other people then started saying "we need optimized SPIR-V, are you doing X ?" (where X doesn't really make sense), LunarG says "no" to generating SPIR-V as the output from LunarGLASS because it doesn't really make sense (LunarGLASS is about producing optimized ISA via a HW-architecture-optimized lower level IR).

- game developers see this discussion and think "gee maybe I should use DX12 and only run on Windows 10"

- nobody seems to be noticing that even a week or two after NDA lift the drivers are improving significantly

What bothers me is that all the discussions seem to be incredibly fact-free, and are all based on first-day drivers and a partially ported game. I doubt the guys who ported Talos to Vulkan were expecting that their initial "get it lighting up" porting step, tested with day-one drivers, would become the foundation of the whole world's perception fo Vulkan.

[justmy2cents]

Thanks all. Yeah, the discussion there seemed a bit off. My understanding was that SPIR-V was supposed to be a "communication" IR that would be fed into implementation-specific optimizing shader compilers, not something that should be optimized at SPIR-V level.

Also isn't LunarGLASS supposed to be handling the IR-to-ISA part of the compiler chain, not the GLSL/HLSL-to-SPIR-V part ?

wouldn't it be just wrong the other way? some basic things like removing dead code could maybe belong in SPIR-V. but, the rest vendors know best. then again, what is the worth of implementing just few? to throw marketing smoke grenade?

[justmy2cents]

I hear the Shader performance with Vulkan is %30-40 slower then DX12 and not easy to program for. I do hope they address those issues at some point.

you probably mean this https://forums.inovaestudios.com/t/t...-question/3174

this only tackles specific performance claims in beta drivers. if you look at DX12 previews you'll see way worse things. and to make it even dumber, he cites anandtech as reference by completely ignoring original source where CroTeam says they are working with IHVs to find the problem

not easy to program with is another bs

- it is just as easy as DX12 since they share more or less all concepts. but, as any low level API you need to know what you're doing

- if is much harder than basic OpenGL. only problem is that all those easy paths are long since deprecated and called slow paths. once you start dealing with VBO,IBO... OpenGL becomes much more complex and less understandable and as far as AZDO and later additions go, this explains it really well https://youtu.be/xXyZ4YaktyU?t=9164 . In modern GL drawing triangle is not few lines of code anymore as it was with glBegin/glVertex3f/glVertex3f/glVertex3f/glEnd

- DX11 is more or less just as complex as OpenGL, but what DX has it going for is no driver clusterfuck. in OpenGL drivers perform randomly across vendors

update: also,

- original comment from where all this started

http://steamcommunity.com/app/257510...48158145024457

anyways, just look how benchmarks keep improving from that post. also, if you notice at that time developers comment on benchmarking high resolutions was "just don't" in that original post. now check what phoronix benchmark was running

[bridgman]

Thanks all. Yeah, the discussion there seemed a bit off. My understanding was that SPIR-V was supposed to be a "communication" IR that would be fed into implementation-specific optimizing shader compilers, not something that should be optimized at SPIR-V level.

Also isn't LunarGLASS supposed to be handling the IR-to-ISA part of the compiler chain, not the GLSL/HLSL-to-SPIR-V part ?

[smitty3268]

Where are you hearing this ?

Not disagreeing necessarily, but "Vulkan's" shader performance isn't likely to be slower (ie something about the spec that inherently makes compiled shader code run that much more slowly), just "a specific Vulkan implementation's" performance.

I'm pretty sure he was referring to this: https://forums.inovaestudios.com/t/t...-question/3174

The dev there seems to be making some assumptions that I'm not sure are necessarily correct - namely, pointing to the Talos Principle benchmarks and claiming that the reason it's 30% slower than DX12 is clearly because of the shader compiler not being good enough. And then later points to this bug and says that they don't have a way to generate optimized spir-v shaders, which is a problem: https://github.com/LunarG/LunarGLASS/issues/5

He seems to think that Epic, Valve, etc. will be coming up with something to optimize their own shaders but that his company isn't big enough to do so and needs something standard provided to him, and that it's missing from Vulkan.

I'm not sure how to really evaluate that - is the llvm thing in that bug what he should be using? Is he just supposed to rely entirely on the drivers to optimize it all? Is the shader issue even a problem on Talos rather than other porting issues not being done yet?

[theriddick]

Could be some of them, think I found some comments on steam also about the issues with shader performance and coding in Vulkan. They were talking about how DX12 is allot easier to work with in that regard but perhaps they were wrong somehow.


PS. Having issues loading the forum now and again..

[log0]

I believe 'Vulkans Shader system is a mess" is the exact about words from one developer. I will try and dig it up but this was quite some time ago and will likely take me a couple days of digging to find it because like I said, not many are making Vulkan support yet.

Could this be the source? https://forums.inovaestudios.com/t/t...-question/3174

Reddit: https://www.reddit.com/r/vulkan/comm...r_ecosystem_a/

Seems like the guy is using talos performance numbers to argue against vulkan (totally ignoring talos devs comments), which makes him look rather silly.