GPUOpen On Reducing Vulkan Overhead With Volk, Possible 1~5% Savings

[computerquip]

There's advantages to using the dispatch method. I'd imagine layering is one of them though perhaps they have a solution to that. 1 ~ 5% savings isn't worth the loss unless they can somehow address the issues with it.

EDIT: Also, how are they getting that number?

[emblemparade]

This library really does very, very little. It just automates the loading of dynamic function dispatch. Many Vulkan users have been doing dynamic function dispatch forever, and in fact it's what's recommended in the Vulkan documentation. So you don't need to use Volk, you just need to do dynamic dispatch.

That said, this little library is very useful! It includes a Python script that takes the latest Vulkan API definitions (available as XML from Kronos) and makes sure you hook all of them. Awesome!

It's a nice complement to glLoadGen, a library I've been using for a long time that does pretty much the same thing for OpenGL, and uses Lua instead of Python.

[VikingGe]

There's advantages to using the dispatch method.

No, there really isn't any advantage. If you use layers, vkGetInstanceProcAddr and vkGetDeviceProcAddr will return function pointers for the first layer in the chain, so you don't need to use an inefficient dispatch method.

You have to load function pointers for extension-related stuff anyway because the Vulkan loader doesn't export any symbols provided by extensions.

[discordian]

I wonder if the got their 1-5% Number from 32bit x86 code (the assembly on the site would imply this) and what it represents. 32bit x86 code is horrible because you need to pass pretty much every argument on the stack, and dispatcher might need to copy the arguments (stack protection, PIE).
Further the ISA needs thunks to do position independent code.

A simple call wrapper should have neglible impact if those calls actually cause some work (even on 32bit x86). *If* the 1-5% are just measured overhead *for the calls*, and vulkan calls account for say 5% of your apps time, then you wont see any difference outside of synthetic tests trashing the API.

[coder]

To my understanding, it means the savings can be as little as 1% or as high as 5%. An average of 3% isn't that impressive, but saying "a 5% savings" could be misleading.
But... I do think saying "up to a 5% savings" would've sufficed.

Ah, but then you wouldn't know that some apps/games could only benefit by 1%.

IMO, it's fine as originally worded. It could have gone on to say the impact depended on a particular program's API usage, but Michael was quoting someone and shouldn't try to cleanup their wording. The best he could've done was to ask, at the time, why the range. But I think it's pretty obvious.

[pal666]

WiLK = wolf in Polish 🐺

volk is transliterated wolf in russian

[pal666]

BTW, not sure what 1-5% savings mean? Is that mostly 1% or mostly 5% or should we think of average 3%

i guess it means that in some games it is 1% while in others it is 5%, i.e. it depends on workload

[pal666]

And what main problem now? I mean you use maximum optimizations but looks like this not enough.

they don't rewrite games' renderers

[pal666]

*If* the 1-5% are just measured overhead *for the calls*, and vulkan calls account for say 5% of your apps time, then you

are doing it wrong. move your app time to different cores

[ernstp]

We already do what this library does.

Neat, I assumed you did!