• Similar Content

    • By AxeGuywithanAxe
      I wanted to get a gauge on how everyone is handling resource descriptors and bind slots in the new API. Under directx11 I would allow the compiler to generate its own bind slots, and look it up at runtime. I wanted to see if people using directx12/Villanova have switched to explicit slots for easier descriptor set management, or are still using the prior version, and burning through descriptors
    • By nickyc95
      I posted on here a while back about rendering architecture and came away with some great information.
      I am planning on implementing a render queue which collects the visible objects in the scene and sorts them based on different criteria to minimise state change etc..
      The thing I am currently undecided about is: what is the best way to submit my draw calls?
      (I am wanting to support both OpenGL and Vulkan)
      At the moment I have two ideas for how I can handle it.
      The renderable handles the rendering (i.e. It calls renderContext->BindVertexBuffer(...) etc) and setup the renderer state Pro- Each renderable is full in control of how it renders Con - Have to manually manage state The renderable pushes RenderCommands (DrawMesh, DrawMeshIndexed etc) into a CommandBuffer that gets executed by the RenderBacked at the end of the frame Pro - Stateless Con - Seems more difficult to extend with new features Pro/Con - The front end only has a subset of rendering capabilities  
      There are more pros / cons for each, but I have listed a couple to help show my thinking..
      Any one have any comments on either of these two approaches or any other approaches that are typically used?
    • By mark_braga
      I have been reading about async compute in the new apis and it all sounds pretty interesting.
      Here is my basic understanding of the implementation of async compute in a simple application like computing the Mandelbrot fractal:
      In this case, the compute queue generates a texture of the fractal and the graphics queue presents it.
      Program structure:
      // Create 3 UAV textures for triple buffering // Create 3 fences for compute queue beginCmd(computeCmd); cmdDispatch(computeCmd); endCmd(computeCmd); queueSubmit(computeQueue, fence[frameIdx]); if (!getFenceReady(fence[frameIdx - 1]) waitForFences(fence[frameIdx - 1]); beginCmd(graphicsCmd); cmdDraw(uavTexture[frameIdx - 1]); endCmd(graphicsCmd); queueSubmit(graphicsQueue); I am not sure about one thing in this structure
      All the examples I have seen use vkWaitForFences but I thought fences are used for waiting from the CPU for the GPU to complete. Should I use semaphores instead, so the graphics queue waits on the GPU for the compute queue to finish if it's running faster than the compute queue? Any advice on this will really help to make efficient use of async compute.
    • By mark_braga
      Hello, I am currently working on synchronization for frame submission in Vulkan.
      This is currently the logic of the draw function.
      void draw() { uint32_t listIndex = gFrameCount++ % gSwapChainImageCount; Cmd* pCmd = ppCmds[listIndex]; beginCmd(pCmd); // resets command buffer fillCommandList(pCmd); endCmd(pCmd); queueSubmit(pGraphicsQueue, pCmd); } gSwapChainImageCount is currently 3.
      So there are no validation errors for first three frames but after I try to reset the command list in the fourth frame (listIndex is back to 0), I get a validation error
      ERROR: [DS] : Attempt to reset command buffer (0x0000025AC56701B0) which is in use. The spec valid usage text states 'commandBuffer must not be in the pending state'
      Now from what I read, submit will automatically stall after the third frame if swapChain[0] is still used. I have tried using all the present modes (Immediate, Fifo, Mailbox,...) but it gives the same error.
      This leads me to believe that what I read was not correct. In that case, I would need to stall until that frame has been processed. So what would be the best way to determine if a commandBuffer is still in use in Vulkan?
    • By khawk
      The AMD GPU Open website has posted a brief tutorial providing an overview of objects in the Vulkan API. From the article:
      Read more at http://gpuopen.com/understanding-vulkan-objects/.

      View full story
  • Popular Now