cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

dutta
Adept II

vkCreateGraphicsPipelines performance in 16.9.1

Hello!

When I upgraded my drivers from 16.8.1 to 16.9.1, the Vulkan implementation I am writing plummeted from a ~4-6 ms frame time to 76 ms. It seems that sometimes, vkCreateGraphicsPipelines takes up to 25 ms to complete, and the performance is the same with a pipeline cache as without, meaning that the speedup gained from using a pipeline cache seems to be lost.

0 Likes
5 Replies
dwitczak
Staff

Thank you for your report. Can you post the set of shaders you use to create the graphics pipeline(s)?

0 Likes

I have a rather big shader library, but I can send you an example shader which takes a long time to create a pipeline from. I submitted them to the original post. Be wary, they are quite big and messy, because they are a part of a bigger shader library, and have some parts generated to GLSL. I also submitted the pipeline cache generated from an application which uses that shader.

In the meantime, I just want to ask if calling vkCreateGraphicsPipelines is a good idea to do every time a new pipeline is needed. Is the pipeline cache magic reliable, or is it better to keep track of the pipeline components yourself?

0 Likes

Awesome, many thanks. I'm going to forward these to a relevant team, so they can have a closer look. Will get back to you as soon as I hear back.

0 Likes

One more thing though: can I ask you to also post SPIR-V blobs created for an example graphics pipeline you're seeing an increased baking time for? Thanks in advance!

0 Likes

Sure thing, attached them to the original post. The ones denoted _bin at the end are the binary representation of the ones denoted as just _debug.

Edit: just realized the binary output is not proper, I'm attaching the new binaries to this post. File denoted _0_ is the vertex shader, and _4_ is the fragment shader. The first 4 bytes is the size of the binary, so the actual binary begins 4 bytes in.

0 Likes