Vulkan 1.0.9 Specification Released

[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 ?

[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

[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?

[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]

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

[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...

[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.

[Azpegath]

Oh, forgetting to mention: I agree that judging Vulkan based on beta drivers and first ports is incredibly premature, BUT there are definitely actors in the business that has a keen interest in people doing that. Khronos, LunarGLASS and we really need this thing to take off, and we need it to be judged on the right (and fair) terms. I think it is amazing and that it will replace OpenGL as soon as possible, based on the presentations. Even though all of them actually stated the opposite, that they will co-evolve together. I believe they will do that to some extent for some time, but Vulkan needs to be a hit and be adopted to (hopefully) a larger extent than OpenGL. Let's hope Apple comes to their senses when it starts getting traction, and adopt it fully. Until then there is a MoltenVK that translates Vulkan to Metal, allowing developers to do Vulkan on the iPhone.

[haagch]

The spec gets updated and updated again and meanwhile many people have vulkan capable GPUs (I have 2) and no driver to use it.

Intel has created an introduction to Vulkan: https://software.intel.com/en-us/api...-vulkan-part-1

Not that I'm immediately going to learn Vulkan yet, but when my experience on my intel ivy bridge GPU with the very first example is

$ [FONT=monospace][COLOR=#000000]gdb -q ./01-The_Beginning [/COLOR]
Reading symbols from ./01-The_Beginning...done.
(gdb) r
Starting program: /home/chris/IntroductionToVulkan/Project/01-The_Beginning
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000555555761148 in vkCreateInstance ()
(gdb) bt
#0  0x0000555555761148 in vkCreateInstance ()
#1  0x000055555555a8d8 in Tutorial::Tutorial01::CreateInstance (this=0x7fffffffd670) at /home/chris/IntroductionToVulkan/Project/Tutorial01/Tutorial01.cpp:124
#2  0x000055555555a600 in Tutorial::Tutorial01::PrepareVulkan (this=0x7fffffffd670) at /home/chris/IntroductionToVulkan/Project/Tutorial01/Tutorial01.cpp:40
#3  0x000055555555a474 in main (argc=1, argv=0x7fffffffd7a8) at /home/chris/IntroductionToVulkan/Project/Tutorial01/main.cpp:23[/FONT]

I'm *surely* not doing it.

By the way: Does anyone know how to improve debugging here? I compiled the vulkan loader and anvil with debug symbols, but gdb still wouldn't know anything about vkCreateInstance().
I guess that it has to do with how they do this in the intel driver:

VkResult vkCreateInstance(const VkInstanceCreateInfo* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkInstance* pInstance)
   __attribute__ ((ifunc ("resolve_CreateInstance"), visibility ("default")));

and then goes through this

void * __attribute__ ((noinline))
anv_resolve_entrypoint(uint32_t index)
{
....
   switch (dispatch_devinfo->gen) {
...
   case 7:
....
      if (gen7_layer.entrypoints[index])
         return gen7_layer.entrypoints[index];
...
   }
}

Am I just doing something wrong or can gdb not trace this by default?

[artivision]

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.

We still need a powerful IR with many optimizations on that level to use it against you, like on a x86 to OpenRisc recompiler.