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?
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.
// Create 3 UAV textures for triple buffering
// Create 3 fences for compute queue
if (!getFenceReady(fence[frameIdx - 1])
waitForFences(fence[frameIdx - 1]);
cmdDraw(uavTexture[frameIdx - 1]);
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.
Hello, I am currently working on synchronization for frame submission in Vulkan.
This is currently the logic of the draw function.
uint32_t listIndex = gFrameCount++ % gSwapChainImageCount;
Cmd* pCmd = ppCmds[listIndex];
beginCmd(pCmd); // resets command buffer
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 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?