Jump to content
  • Advertisement
Sign in to follow this  
Silverlan

Vulkan Vulkan render-call performance drain

This topic is 796 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

My Vulkan program is running extremely slow, and I'm trying to figure out why. I've noticed that even a few draw-calls already drain the performance far more than they should.

For instance, here's an extract(Pseudocode) for rendering a few meshes:

int32_t numCalls = 0;
int32_t numIndices = 0;
for(auto &mesh : meshes)
{
	auto vertexBuffer = mesh.GetVertexBuffer();
	auto indexBuffer = mesh.GetIndexBuffer();

	vk::DeviceSize offset = 0;
	drawCmd.bindVertexBuffers(0,1,&vertexBuffer,&offset); // drawCmd = CommandBuffer for all drawing commands (single thread)
	drawCmd.bindIndexBuffer(indexBuffer,offset,vk::IndexType::eUint16);

	drawCmd.drawIndexed(mesh.GetIndexCount(),1,0,0,0);

	numIndices += mesh.GetIndexCount();
	++numCalls;
}

There are 238 meshes being rendered, with a total vertex index count of 52050. The GPU is definitely not overburdened (The shaders are extremely cheap).

If I run my program with the code above, the frame is being rendered in approximately 46ms. Without it it's a mere 9ms.

I'm using fifo present mode with 2 swapchain images. Only a primary command buffer at this time (No secondary command buffers/pre-recorded buffers), same buffer for all frames.

 

My problem is, I don't really know what to look for. These few rendering calls should barely make a dent, so the source of the problem must be somewhere else.

Can anyone give me any hints how I should tackle this? Are the any profilers around for Vulkan already?

I just need a nudge in the right direction.

 

// EDIT:

So, it looks like vkDeviceWaitIdle takes about 32ms to execute, if all 238 meshes are rendered. (If none are rendered, it's < 1ms).

Most of the stalling stems from there, but I still don't know what to do about it.

Edited by Silverlan

Share this post


Link to post
Share on other sites
Advertisement
If you wait for the device every frame you're basically synchronizing the CPU with the GPU, not allowing the CPU to work ahead on more commands. Like calling glFlush/glFinish every frame.

 

That's fine, except for the fact that the GPU isn't done with its work for 32 ms, so either way the GPU work is taking forever.

Share this post


Link to post
Share on other sites

What GPU do you have?  Also since drivers are immature have you updated to the latest version?

I don't know vulkan but I noticed you're using a seperate vertex and index buffer per mesh and rebinding for each mesh in your mesh list.  This might cause a performance problem... try putting your meshes into the minimum number of vertex and index buffers and see what happens.

 

edit - also how many command buffers is your 238 meshes divided among? (one if I read correctly)

         also are you sorting your meshes front to back? or by texture?

 

edit - how many triangles per mesh?  Also the code you provided is an example or your actual code?

Edited by Infinisearch

Share this post


Link to post
Share on other sites

..as above. Vulkan still is not going to save you from unecessary/redundant state changes.

Share this post


Link to post
Share on other sites

Are you using different Queues for present and render or the same Queue?

Have you tried using fences on the present operation instead of vkDeviceWaitIdle? The documentation suggests that vkDeviceWaitIdle should be used to wait in a shutdown situation, so it might be rather pessimistic in some implementations.

Vulkan's timeout functions are typically bound to the OS' timing granularity, which is usually 16ms on Windows (IIRC). Another way to make sure the driver really waits 32ms is to set the timing granularity to 1ms. Chrome does this by default, for example.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!