Jump to content

  • Log In with Google      Sign In   
  • Create Account

Boreal

Member Since 24 Oct 2011
Offline Last Active Today, 09:08 AM

Posts I've Made

In Topic: Safe resource deallocation in Vulkan

06 April 2016 - 09:57 PM

First thing is to boil it down a bit.  Reference counting is out of the scope of this - it's dealing with what happens when you do decide to delete something that is the issue at hand.

 

Consider a simplistic rendering loop that renders, presents, and then waits for the device to be idle each frame.  After the device is idle, but before anything is rendered, you can be sure that destroying a resource will be safe, as long as you don't try to use it again.  So you can either defer all logic that would ever delete a resource until that time, or allow a deletion to be requested at any time but put it in a buffer to be "played back" in the safe window.

 

Fairly trivially, this can be extended to a pipeline that is multiple frames deep.  Let's go with 3, for the sake of example.  This means you might have rendering commands on the fly up to 2 frames "behind", and therefore you have to take that into account whenever you want to delete a resource.  The easiest thing to do in this case IMO would be to have a growable array for each frame (e.g. 3); they keep track of deletion requests, each corresponding to requests issued when the CPU is processing that frame.  Each frame would also have a fence associated with it.  Whenever a new frame is started, it waits on its fence, and then before rendering anything, it deletes the appropriate resources and clears the vector for new requests to be added.  When submitting the commands for that frame, you say that the fence should be signaled when the submission is complete.  The fence ensures that the CPU will never get too far ahead of the GPU and cause the renderer to trip over itself, ensuring that you won't ever try to delete a resource that's being used by the GPU.

 

This concept of shifting by the number of frames in your pipeline applies to destructive updates, such as rendering to a framebuffer, as well.  For N frames, you will need N copies of each attachment, and cycle through to determine which copy you are writing to.


In Topic: Vulkan render pass questions

26 March 2016 - 12:48 PM

It's not meant for post-processing in general.  It's meant for optimizations that tiled GPUs especially can make use of whenever they have guarantees like only reading an attachment at the exact position it's rendering the fragment.

 

I imagine merging everything into a single shader would have some downsides as opposed to doing it within the render pass framework, or we wouldn't have render passes in the first place.


In Topic: Vulkan is Next-Gen OpenGL

18 March 2016 - 02:56 PM

Aha!  I finally managed to solve the problem!

 

I was reading this page more closely, and it turns out that the loader needs to be able to find the layers using registry keys that indicate the VkLayer_xxx.json manifests.  I added them and it all works perfectly now, even through MinGW instead of VS2015!


In Topic: Vulkan is Next-Gen OpenGL

17 March 2016 - 10:02 PM

I did recompile all the loader and layer libraries from source using the VS 2015 compiler, actually, and am using the debug versions.  Though I guess since they're MSVC-generated a lot or all of the debugging information is only in the PDBs?  Maybe I should give up on trying to use MinGW for this...


In Topic: Vulkan is Next-Gen OpenGL

17 March 2016 - 07:54 PM

Yes, the exit would always have happened after a pipeline flush.  I think the issue ended up being that the image was still owned by the presentation engine rather than the application when I tried to destroy the swapchain, but it was hard to tell for sure because even completely unrelated things seemed to fix it, like creating an already-signaled fence at initialization and then waiting on it before termination, or just stepping through a debugger and putting more time between the last vkQueuePresentKHR and vkDestroySwapchainKHR.

 

If I've learned anything from my efforts today, it's that Vulkan development, especially if you're learning by mostly trial-and-error, is next to impossible if you can't use the validation layers.  And with no existing knowledge base, it's trial-and-error to get the layers working in the first place...I have no idea if it's because I'm on Windows 7, or because I have AMD hardware, or because I use MinGW and not MSVC, or what.


PARTNERS