• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • 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.
    • By mark_braga
      I have a pretty good experience with multi gpu programming in D3D12. Now looking at Vulkan, although there are a few similarities, I cannot wrap my head around a few things due to the extremely sparse documentation (typical Khronos...)
      In D3D12 -> You create a resource on GPU0 that is visible to GPU1 by setting the VisibleNodeMask to (00000011 where last two bits set means its visible to GPU0 and GPU1)
      In Vulkan - I can see there is the VkBindImageMemoryDeviceGroupInfoKHR struct which you add to the pNext chain of VkBindImageMemoryInfoKHR and then call vkBindImageMemory2KHR. You also set the device indices which I assume is the same as the VisibleNodeMask except instead of a mask it is an array of indices. Till now it's fine.
      Let's look at a typical SFR scenario:  Render left eye using GPU0 and right eye using GPU1
      You have two textures. pTextureLeft is exclusive to GPU0 and pTextureRight is created on GPU1 but is visible to GPU0 so it can be sampled from GPU0 when we want to draw it to the swapchain. This is in the D3D12 world. How do I map this in Vulkan? Do I just set the device indices for pTextureRight as { 0, 1 }
      Now comes the command buffer submission part that is even more confusing.
      There is the struct VkDeviceGroupCommandBufferBeginInfoKHR. It accepts a device mask which I understand is similar to creating a command list with a certain NodeMask in D3D12.
      So for GPU1 -> Since I am only rendering to the pTextureRight, I need to set the device mask as 2? (00000010)
      For GPU0 -> Since I only render to pTextureLeft and finally sample pTextureLeft and pTextureRight to render to the swap chain, I need to set the device mask as 1? (00000001)
      The same applies to VkDeviceGroupSubmitInfoKHR?
      Now the fun part is it does not work  . Both command buffers render to the textures correctly. I verified this by reading back the textures and storing as png. The left texture is sampled correctly in the final composite pass. But I get a black in the area where the right texture should appear. Is there something that I am missing in this? Here is a code snippet too
      void Init() { RenderTargetInfo info = {}; info.pDeviceIndices = { 0, 0 }; CreateRenderTarget(&info, &pTextureLeft); // Need to share this on both GPUs info.pDeviceIndices = { 0, 1 }; CreateRenderTarget(&info, &pTextureRight); } void DrawEye(CommandBuffer* pCmd, uint32_t eye) { // Do the draw // Begin with device mask depending on eye pCmd->Open((1 << eye)); // If eye is 0, we need to do some extra work to composite pTextureRight and pTextureLeft if (eye == 0) { DrawTexture(0, 0, width * 0.5, height, pTextureLeft); DrawTexture(width * 0.5, 0, width * 0.5, height, pTextureRight); } // Submit to the correct GPU pQueue->Submit(pCmd, (1 << eye)); } void Draw() { DrawEye(pRightCmd, 1); DrawEye(pLeftCmd, 0); }  
    • By turanszkij
      Hi,
      I finally managed to get the DX11 emulating Vulkan device working but everything is flipped vertically now because Vulkan has a different clipping space. What are the best practices out there to keep these implementation consistent? I tried using a vertically flipped viewport, and while it works on Nvidia 1050, the Vulkan debug layer is throwing error messages that this is not supported in the spec so it might not work on others. There is also the possibility to flip the clip scpace position Y coordinate before writing out with vertex shader, but that requires changing and recompiling every shader. I could also bake it into the camera projection matrices, though I want to avoid that because then I need to track down for the whole engine where I upload matrices... Any chance of an easy extension or something? If not, I will probably go with changing the vertex shaders.
    • By Alexa Savchenko
      I publishing for manufacturing our ray tracing engines and products on graphics API (C++, Vulkan API, GLSL460, SPIR-V): https://github.com/world8th/satellite-oem
      For end users I have no more products or test products. Also, have one simple gltf viewer example (only source code).
      In 2016 year had idea for replacement of screen space reflections, but in 2018 we resolved to finally re-profile project as "basis of render engine". In Q3 of 2017 year finally merged to Vulkan API. 
       
       
  • Advertisement
  • Advertisement
Sign in to follow this  

Vulkan Is Dynamic Draw Call Batching Still Relevant?

Recommended Posts

Hey, So I wanted to ask a simple question pertaining to dynamic batching , as in dynamically building vertex and index buffers to reduce draw calls. I wanted to know that in the age of Vulkan/DirectX12 , dynamic instancing, and compute shader based culling, is dynamic batching still relevant? I know that Engines such as Unreal Engine does not support dynamic instancing / dynamic batching , and Unity supports both. I'm currently building a somewhat open world game, so efficiency is of the greatest importance. Thanks.

Share this post


Link to post
Share on other sites
Advertisement

Dynamically Batching is still very relevant , it's just that it conflicts with instancing so using both is very difficult.

When working with a lot of unique objects batching holds the advantage, that is why it was popular with linear games. The only rule for batching is that it should share the same material/ shader.

Instancing has the advantage when you need a lot of one object, like grass, that repeat. So it's the one you want to focus on when making openworld games.

 

The best would be to use both, batching for unique locations and instancing for large openworld zones. However making a dynamic batch manager that doesn't conflict with instancing is very difficult and makes a engine difficult to use; Lumberyard is a good example.

Most engines like Unreal 4 instead opt for selective batching, by allowing developers to merge objects by hand.

Share this post


Link to post
Share on other sites

Thank you both for your responses. What I tend to dislike about Unity's approach is that , in my opinion, they can only dynamically batch really small meshes, it also seems that now that they support dynamic instancing, a mesh will use instancing before dynamic batching. Do you have any opinion on mesh merging / vertex pulling in comparison to the older batching techniques?

Share this post


Link to post
Share on other sites
I think ti's interesting if your use-cases have a bottleneck or performance issue which could be solved using this technique

Share this post


Link to post
Share on other sites

Thank you both for your responses. What I tend to dislike about Unity's approach is that , in my opinion, they can only dynamically batch really small meshes,

That is how it works you have 65 000 vertices per mesh, you can either have 65 000 single vertex meshes or one 65 000 vertices mesh. Unreal has the same limit except it's called the 64k polygon limit.

What it means is that when you load in a mesh more than 64k-65k vertices it will create a new batch. How many batches a game can use depends on the graphics card not the engine.

 

The reason Unity can only batch small meshes is because of UV maps and Smooth groups. A UV seam splits the vertices where it is assigned, in games this matters a lot because a single UV map can add as much as 30%-50% to the vertex count. Smooth groups often add 10%-20% vertices to the count.

So a simple 1000 vertices mesh with a UV map and only one smooth group is more like a 1500- 1800 vertices. And you end up getting a lot less meshes per batch than expected.

 

Do you have any opinion on mesh merging / vertex pulling in comparison to the older batching techniques?

My opinion on vertex pulling and mesh merging is that both are just different ways of batching. The performance gain and downsides is the same as batching.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement