So it turns out I was doing something dumb in that Vulkan bechmark post I shared yesterday (not considering that I may have been hitting a perf bottleneck that was skewing results...)

I've since updated the tests, re ran everything, and posted an updated article on my site:
kylehalladay.com/blog/tutorial

Hoooorraaaayy for extremely public mistakes!

@khalladay Nice! It's interesting that push constants are the slowest for the bistro scene. Maybe it scales badly with the number of draw calls/push constant calls?

I see you're resetting the existing command buffer, so it should keep enough allocated space to hold all the push constant data.

What's the reason for choosing HOST_CACHED memory btw? Wouldn't HOST_VISIBLE be better for CPU->GPU data? That's what I am using at least, but I could be doing things wrong.

@khalladay One thing that may affect performance in a bad way is that you're binding a separate vertex and index buffer for every draw call. If you have many draw calls, this can become expensive.

You could allocate one (or 2) huge buffer for all vertex and index data, and then pass offsets into that buffer in vkCmdDrawIndexed (firstIndex and vertexOffset arguments).

πŸ‡¨πŸ‡¦ Kyle Halladay
Follow

@Gohla Totally agreed, my vertex buffer handling could be improved. For this test it didn't feel super important, because I wasn't going for raw performance, but rather, trying to see perf differences across different vertex shaders, so as long as the scene stayed constant, I was ok with the reduced performance.

Ideally I'd like to organize my data to avoid as many bind calls as possible.

@khalladay Right, I don't think it affects the experiment with different binding strategies.

Sign in to participate in the conversation
Gamedev Mastodon

Game development! Discussions about game development and related fields, and/or by game developers and related professions.