Vulkan 1.0.9 Specification Released

[gamerk2]

As of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?

Besides Time, Effort, and Money? :/

[norsetto]

As of today, the only spir-v compiler available is glslang, which, in their own words, is still experimental and not optimized. Then again, nothing prevents anyone to invent their own shading language and write up a spir-v compiler for it (I know at least one developer who might do just that ...). And of corse why not writing them in spir-5 itself?

[justmy2cents]

Thanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.

i doubt there will be much success. when someone screams "doomsday" on the first days of first beta drivers and first ever barely started port by citing 3rd party site that has no involvement with drivers or that port, he has probably already decided in his head and just wanted to get some public confirmation for his decision. guessing further, it was more like publicity stunt since nothing gets louder and more repeated than being controversial about currently hot topic

[theriddick]

Thanks for talking about this a bit, I forwarded the info to the original developer who sparked it, perhaps he will rethink Vulkan support in the future. I was trying to get him to reconsider it so that perhaps we could get Linux support at the end of development with Vulkan API but I just know very little about the whole issue so couldn't help.

[justmy2cents]

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

well, i said it in my previous comment. there are some that can fit in first level. like dead code removal as example. but, what is the point of making SPIR-V more complicated with no real benefit. SPIR-V is nothing but IR specification. this would complicate it by a lot. not to mention, that only some optimizations are generic enough, while many are probably better left to IHV because they know the fastest path for their hw

note this example
if (1 == 0) { // a lot of lines of expensive code } }
with dead code removal, this will simply be dropped. but, main question here is? how do you define this in specification? will you create gazillion samples of such "invalid" code?

what would be more than possible is some sort of standalone SPIR-V post processor that does what you say. feed SPIR-V and get out step 1 optimized SPIR-V and note the main thing here. both are same SPIR-V, so i cannot really figure out how optimization would fall into its scope. and since SPIR-V specification is completely open, nothing prevents people to write such tool

update: this is just my opinion, but you really want to have at least one result that does exactly what you told it to. as soon as first possible result is optimized you're prone to find errors in that and if you have no exact reference, it makes job of assigning blame to find the root of the problem much harder

[bridgman]

One thing I forgot to mention - there were some comments about the initial Vulkan drivers not being able to run fullscreen (on Windows I think), but running "borderless" instead. Not sure how much that would affect performance but seems like it might be a factor. If there was an additional full-screen copy required every frame that could have some of the same "gap widens with resolution" effect as a slow shader compiler.

[tessio]

- 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

https://youtu.be/EX1RKhlOYmY?t=2h11m41s

Same video, much better resolution.

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

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

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