Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Oct 2011
Offline Last Active May 26 2016 02:45 PM

#5285533 Safe resource deallocation in Vulkan

Posted by Boreal on 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.

#5281704 Vulkan is Next-Gen OpenGL

Posted by Boreal on 17 March 2016 - 11:16 AM

I'm probably not doing myself any favours here by using MinGW-w64...


That being said, it's kind of irritating to require us to build your project using CMake (and download Python), but only support Visual Studio anyways.  Downloading and installing that beast is a huge investment just to compile a single library.


EDIT: Oh man, am I glad I found out you can get the VC++ build tools without downloading the whole kit and caboodle.


EDIT 2: This is ridiculously frustrating.  If I enable the debug layers, I get a segfault from vkResetFences, which I have not called explicitly.

#5280976 LOD on a (cubical) voxel engine

Posted by Boreal on 12 March 2016 - 10:44 PM

One option that is an alternative to dealing with mesh LOD is to hybridize and use a combination of polygonal rendering for near terrain and actual voxel rendering for distant terrain.



Since your terrain is already made of cubes, it will be harder to notice a difference on the boundary.

#5276963 Vulkan is Next-Gen OpenGL

Posted by Boreal on 19 February 2016 - 10:00 AM

Not to mention that you could expose the "low-hanging fruit" of Vulkan optimizations (command buffers, threading) without having the API client delve into memory management or manual buffering.

#5276803 Vulkan Resources

Posted by Boreal on 19 February 2016 - 12:57 AM

Is it just me or are most of the samples doing a ton of unnecessary waiting? 


With the exception maybe doing something quick and dirty, special blocking loads, or maybe something fancy I can't think of at the moment, I kind of assume one wouldn't want to call vkDeviceWaitIdle or vkQueueWaitIdle very frequently. Right? But they seem littered everywhere.


It's a hell of a lot easier than setting up the infrastructure for double (or more) buffering, where you need to ensure that you don't change/delete things that are being used for the previous frame.  You still need to issue a wait every 2 frames for double buffering (3 for triple buffering, and so on), but in practice, it's just there as a safeguard for pathological scenarios and should typically be a no-op.

#5267319 Unity vs Unreal 4 approach to entity-component pattern

Posted by Boreal on 21 December 2015 - 08:45 AM

I think Unity's is a step in the right direction, but it's very difficult to make components interact when they are entirely encapsulated.  I find that it's better to have components be pure data, with systems operating over them, potentially multiple components at once, e.g. an IntegrationSystem that integrates velocity into position, but only if both components are present.

#5264977 Vulkan is Next-Gen OpenGL

Posted by Boreal on 05 December 2015 - 12:12 AM

The Mantle documentation has been out for a long time now.  I hate to toot my own horn, but you can even use the library I've developed (link in my signature) to use Mantle provisionally, as long as you have an AMD card.

#5235976 Vulkan is Next-Gen OpenGL

Posted by Boreal on 20 June 2015 - 11:38 PM

There's this, but otherwise there's only the API documentation.



#5235598 Vulkan is Next-Gen OpenGL

Posted by Boreal on 18 June 2015 - 07:25 PM

Well, it's supposed to work on anything that can support OpenGL ES 3.1.  According to Wikipedia this includes Fermi onward (although this fact is not cited).


I assume that on the AMD side, Vulkan will be supported by a great deal of cards that currently support Mantle (probably not all of them, as I bet some optional features will be promoted to mandatory).


I'm pretty happy with playing around with Mantle at this point, although getting shaders up and running is a big hassle since the AMD IL documentation is horrible and there are no public headers for it (to my knowledge).  Plus, Mantle only supports a restricted subset of the full IL spec, and the only way to compile from HLSL is to use an old version of CodeXL since they dropped support for IL output in the newest version.  You also have to preprocess the output file to extract the shader binary (which is given in comments off to the side in hex) since the textual output is completely wrong.

#5235529 Vulkan is Next-Gen OpenGL

Posted by Boreal on 18 June 2015 - 11:13 AM

I've actually created a GLEW-like library for Mantle, which implements the full API as described in the reference.



#5224224 What are your opinions on DX12/Vulkan/Mantle?

Posted by Boreal on 18 April 2015 - 03:34 PM

This brilliant programmer reverse-engineered the Mantle API and wrote a "Hello Triangle" tutorial.  Definitely worth checking out.



#5214623 Vulkan is Next-Gen OpenGL

Posted by Boreal on 04 March 2015 - 08:51 PM

I'd be excited to see the possibilities of using an HSA chip (APU) for compute and leaving the dedicated GPU for graphics.  Hopefully with AMD having a big stake in Vulkan and OpenCL 2.1 this will be possible.

#5214176 Vulkan is Next-Gen OpenGL

Posted by Boreal on 03 March 2015 - 05:37 AM

Well, never mind.  That's great!

#5213266 Having trouble harnessing the power of Inheritance. (best practices advice re...

Posted by Boreal on 27 February 2015 - 01:08 AM

The way I think of it is this: it has the properties of a baddie so therefore it's implied that it is a baddie and can be treated as one.


It's basically a form of duck typing, which is an alternate to using interfaces.  Both are forms of polymorphism, but since we want our objects to be easily changed (essentially making them dynamically typed) we use duck typing instead of interfaces and inheritance.  This of course goes along with avoiding problems related to the deadly diamond and virtual function calls.

#5200326 Multi-threading for performance gains

Posted by Boreal on 27 December 2014 - 04:16 PM

The way I would structure it is to have one thread for logic scheduling and one thread for graphics/audio/input scheduling, and then saturate the rest of the cores with worker threads.  However, I would only suggest separating the logic and "not logic" threads if you have them decoupled through some sort of buffer, as you would if you were implementing a fixed-update variable-render game loop.  In my mind this type of threading only works if you have that kind of architecture.  Ideally this is also utilizing a sort of MVC where the logic system is completely agnostic to the "not logic" system and its implementation, which is a big deal if you plan to do anything cross platform.