• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • 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.
    • 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.
  • Advertisement
  • Advertisement
Sign in to follow this  

Vulkan Vulkan command pools and buffer questions

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

Been reading through the Vulkan 1.0 spec and I have a few small questions about command pools, buffers, and render targets.

 

Command Pools:

- When vkResetCommandPool() is called are the command buffers just reset or are they destroyed and have to be recreated?

- On page 49, it states:

– VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT controls whether command buffers allocated
from the pool can be individually reset. If this flag is set, individual command buffers allocated from the pool can be
reset either explicitly, by calling vkResetCommandBuffer, or implicitly, by calling
vkBeginCommandBuffer on an executable command buffer. If this flag is not set, then
vkResetCommandBuffer and vkBeginCommandBuffer (on an executable command buffer) must not be
called on the command buffers allocated from the pool, and they can only be reset in bulk by calling
vkResetCommandPool.

 

If I can't call vkBeginCommandBuffer(), how would a command buffer ever be used?  Isn't it a requirement to call vkBeginCommandBuffer() prior to recording any commands in the buffer?  Is it that command buffers from a pool without the bit set are already implicitly in a 'recording' state and vkBeginCommandBuffer() isn't required or is vkBeginCommandBuffer() only callable once and can't be used a second time to reset the command buffer (it seems to imply the latter in 5.3 but doesn't really out right state it)?

 

Command Buffers:

- I am a bit uncertain about the VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT.  I take it without setting this bit, a command buffer can only be used once at any given time?  Later on, on page 59, it seems to suggest not using this bit can lead to increased performance, but in order to re-use a command buffer it seems almost a necessity to have this bit set.  When re-using a command buffer: are they expecting us to record multiple identical command buffers and rotate them for optimal performance, or does the bit not really matter performance-wise and set it and forget, or am I reading the whole thing wrong and a command buffer can be used when/where-ever as long as its not reset and/or destroyed during its use?  It just seems strange to me that a seemingly read-only structure (ie. the command buffer) would need a special bit set to indicate that it can be read from multiple locations.

 

Render Targets:

- The documentation seems to imply these are required.  Knowing access dependencies seems important so I can see why it would be a necessity.  But in the documentation of many of the functions it seems to imply that they aren't required.  For example, on page 66 the repeated use of the phrase "if vkCmdExecuteCommands is being called within a render pass ...", seems to imply that a render pass is optional.  Are they required at all times?  Required for graphical commands but ignored for compute/other commands?  Are they optional but good to have for performance benefit?

Share this post


Link to post
Share on other sites
Advertisement


If I can't call vkBeginCommandBuffer(), how would a command buffer ever be used? Isn't it a requirement to call vkBeginCommandBuffer() prior to recording any commands in the buffer? Is it that command buffers from a pool without the bit set are already implicitly in a 'recording' state and vkBeginCommandBuffer() isn't required or is vkBeginCommandBuffer() only callable once and can't be used a second time to reset the command buffer (it seems to imply the latter in 5.3 but doesn't really out right state it)?

 

You can call it once, while the command buffer is still in the "initial state", and it only becomes executable after some commands have been recorded into it for the first time; see the first few paragraphs of "Chapter 5. Command Buffers".

 


- When vkResetCommandPool() is called are the command buffers just reset or are they destroyed and have to be recreated?

 

I'm not sure but I think it only resets it, but it may release internally-used host memory depending on the flags passed (that memory would presumably be allocated back when recording a new batch of commands in that command buffer).

 

Also experimenting with Vulkan so take my comments with a grain of salt smile.png

Share this post


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

  • Advertisement