Jump to content
  • Advertisement
Sign in to follow this  

Vulkan render huge amount of objects

This topic is 644 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

Hellow!!!

In modern GPU, modern graphic api dx12,vulkan, how many objects   can be drawn at most in 60fps  ? and with  one light?

My scene with 100 boxes and a direction light  runs 15 fps. I 'm not sure is it normal?

I have a look at horde3d engine, it seems  he draws 100 crowded animated models without using instancing , but still runs smoothly, I guess it may be faster

than 60fps , how can he do it?

Need tutorial/links abount rendering big big scene.

Edited by poigwym

Share this post


Link to post
Share on other sites
Advertisement
Sounds like something is wrong as that is a very low framerate for such a simple scene.

Have you run it though a profiler yet?

Do that first and let us know your results :)

Share this post


Link to post
Share on other sites

What are you using to render (API/libraries etc)? Are you using any form of instancing? Posting your render code might allow people to spot some simple mistakes.

Share this post


Link to post
Share on other sites
Same here, show some details and we'll take a peak. Assuming the boxes are made up of 8 vertices and 12 triangles, I agree that it's not OK.

It also helps to no on which hardware/ GPU you're running it (just to be sure)

Share this post


Link to post
Share on other sites

What cozzie said. Not all 66ms of work are born equal. 66ms of work on a GTX 980 isnt the same as 66ms of work on an Intel HD 2000.

Share this post


Link to post
Share on other sites

I have a profile in my engine, and found that the time spent in matrix multiplication and cbuffer commit are most among all instructions.

 

After I shut down all light, The process is simple,  for every object, update transform cbuffer  and commit cbuffer, and draw.

 

In my engine .all shader share 10 cbuffer(5 for vs, 5 for ps).

one cbuffer look like these:
struct CBTransform /*: register(b0)*/
{
  Matrix4f world_matrix;
  Matrix4f world_invTrans_matrix;
  Matrix4f world_view_proj_matrix;
  Matrix4f light_view_proj_matrix;
};
 
 
setTransform(Renderable node)
{
// update transform cb
 CBTransform *p = reinterpret_cast<CBTransform*>(renderbase->MapResource(_cbtrans, 0, D3D11_MAP_WRITE_DISCARD, 0));
  
  Matrix4f world;
  if (node->_hasBone)
      world.initIdentity();
  else
      world = node->getTransform();
   p->world_matrix = world;
   p->world_invTrans_matrix = world;
   Camera *camera = Engine::sceneManager().getMainCamera();
   Matrix4f view = camera->getView();
   Matrix4f proj = camera->getProjection();
   Matrix4f mwvp = world *view *proj;
    p->world_view_proj_matrix = mwvp;
 
   if (_curlight) {
     Matrix4f lightTrans = world * _curlight->getLightTransform(); // world* viewproj
     p->light_view_proj_matrix = lightTrans;
   }
 
 
   renderbase->unMapResource(_cbtrans, 0);
}
 
// since all shaders share 10 cbuffer, I pass 10 to gpu at every draw call. I'm not sure if the method is right??
_context->VSSetConstantBuffers(0, (int)CBufType::MAX_CBUF_GROUP, _cBufs[(int)ShaderType::VERTEX_SHADER]);
_context->PSSetConstantBuffers(0, (int)CBufType::MAX_CBUF_GROUP, _cBufs[(int)ShaderType::PIXEL_SHADER]);
 

Share this post


Link to post
Share on other sites

hehe, I  forget to say those  100   boxex that I draw have the same look, and use same vertex buffer, but don't use instancing technique.

I need to  update 100 times cbuffer and commit 100 times cbuffer per frame.


Is it possible to draw 100 dynamic boxes that has different vertex buffer and texture and not using instancing technique within 60fps  in modern gpu? My cpu and gpu is a little old.  

Edited by poigwym

Share this post


Link to post
Share on other sites

Put some timing code into the hot-spots that you've found (setTransform, etc) and find out exactly how many microseconds per frame you spend on that logic.

Share this post


Link to post
Share on other sites

If you are on a desktop you can see and old flash demo I did here to test what your gpu can handle.

this is in flash by the way so native you should be able to beat what you see here (it is not massively optimised either)

 

There is no instancing and each object has a unique transform, the only thing constant between draws is the material.

 

Lower end gpus should be 500-1000 no problems, mid range 1500-3000, high end can hit 8,000+

 

http://blog.bwhiting.co.uk/?p=314 

Share this post


Link to post
Share on other sites

Not sure if I understood you correctly, but if you're using 10 CBuffers to render 10 boxes with some (forward) lighting, you could do with 2 constant buffers (not 10):

 

1. a CB per frame, containing possible viewProjection matrix and your light properties (for multiple lights)

2. a CB per object, which you update for each update, after the last one is drawn

 

Both having a corresponding C++ struct in your code.

If you're using 10 different CBuffers, that might explain a part of the unexpected performance.

Share this post


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

  • Advertisement
  • Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By turanszkij
      Hi, running Vulkan with the latest SDK, validation layers enabled I just got the following warning:
      That is really strange, because in DX11 we can have 15 constant buffers per shader stage. And my device (Nvidia GTX 1050 is DX11 compatible of course) Did anyone else run into the same issue? How is it usually handled? I would prefer not enforcing less amount of CBs for the Vulkan device and be as closely compliant to DX11 as possible. Any idea what could be the reason behind this limitation?
    • By DiligentDev
      Hello everyone!
      For my engine, I want to be able to automatically generate pipeline layouts based on shader resources. That works perfectly well in D3D12 as shader resources are not required to specify descriptor tables, so I use reflection system and map different shader registers to tables as I need. In Vulkan, however, looks like descriptor sets must be specified in both SPIRV bytecode and when creating pipeline layout (why is that?). So it looks like I will have to mess around with the bytecode to tweak bindings and descriptor sets. I looked at SPIRV-cross but it seems like it can't emit SPIRV (funny enough). I also use glslang to compile GLSL to SPIRV and for some reason, binding decoration is only present for these resources that I explicitly defined.
      Does anybody know if there is a tool to change bindings in SPIRV bytecode?
       
    • By turanszkij
      Hi, I am having problems with all of my compute shaders in Vulkan. They are not writing to resources, even though there are no problems in the debug layer, every descriptor seem correctly bound in the graphics debugger, and the shaders definitely take time to execute. I understand that this is probably a bug in my implementation which is a bit complex, trying to emulate a DX11 style rendering API, but maybe I'm missing something trivial in my logic here? Currently I am doing these:
      Set descriptors, such as VK_DESCRIPTOR_TYPE_STORAGE_BUFFER for a read-write structured buffer (which is non formatted buffer) Bind descriptor table / validate correctness by debug layer Dispatch on graphics/compute queue, the same one that is feeding graphics rendering commands.  Insert memory barrier with both stagemasks as VK_PIPELINE_STAGE_ALL_COMMANDS_BIT and srcAccessMask VK_ACCESS_SHADER_WRITE_BIT to dstAccessMask VK_ACCESS_SHADER_READ_BIT Also insert buffer memory barrier just for the storage buffer I wanted to write Both my application behaves like the buffers are empty, and Nsight debugger also shows empty buffers (ssems like everything initialized to 0). Also, I tried the most trivial shader, writing value of 1 to the first element of uint buffer. Am I missing something trivial here? What could be an other way to debug this further?
       
    • By khawk
      LunarG has released new Vulkan SDKs for Windows, Linux, and macOS based on the 1.1.73 header. The new SDK includes:
      New extensions: VK_ANDROID_external_memory_android_hardware_buffer VK_EXT_descriptor_indexing VK_AMD_shader_core_properties VK_NV_shader_subgroup_partitioned Many bug fixes, increased validation coverage and accuracy improvements, and feature additions Developers can download the SDK from LunarXchange at https://vulkan.lunarg.com/sdk/home.

      View full story
    • By khawk
      LunarG has released new Vulkan SDKs for Windows, Linux, and macOS based on the 1.1.73 header. The new SDK includes:
      New extensions: VK_ANDROID_external_memory_android_hardware_buffer VK_EXT_descriptor_indexing VK_AMD_shader_core_properties VK_NV_shader_subgroup_partitioned Many bug fixes, increased validation coverage and accuracy improvements, and feature additions Developers can download the SDK from LunarXchange at https://vulkan.lunarg.com/sdk/home.
  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!