gabbell / cydonia Goto Github PK

• Shader modules

Requires more synchronization inside the command buffer itself. i.e. knowing when it was previously submitted so it can wait until the previous submission is done to submit again or maybe submit on a separate queue. Lots TBD.

Make sure isCompleted is accurate even if the command buffer is submitted twice. i.e. reset the fence?

Need a way to chain/sync/schedule command lists between systems through a common structure.

http://themaister.net/blog/2017/08/15/render-graphs-and-vulkan-a-deep-dive/

https://github.com/acdemiralp/fg

https://ourmachinery.com/post/high-level-rendering-using-render-graphs/

https://jorenjoestar.github.io/post/data_driven_rendering_pipeline/

https://bitsquid.blogspot.com/2017/03/stingray-renderer-walkthrough-7-data.html

I love descriptor sets 🙃

Implement an ECS
Pillars of ECS:

• Components have no functionality
• Systems have no state
• Entities are handles

Some Questions

• Who owns what?
• How do I keep components in contiguous memory?
• What does the user code look like?
• How do you tick? How can the systems fetch the components that need to be updated?

Implementation

• Basic working draft of framework (EntityManager, Components, Entities, Systems)
• Pooling components/archetypes

Cool links:
https://github.com/alecthomas/entityx

https://www.youtube.com/watch?v=W3aieHjyNvw

Since we are using inheritance when dealing with renderable types and the component pools only check for the component type (renderable), we are not getting one pool per renderable type.

Introduce shared components (singleton components) that only ever have one instance.

This includes work on creating a task graph with read/write dependencies between systems in order to parallelize CPU work as much as possible (command buffer recording, pipeline creation)

Use a number of command buffer pools dependent on the number of threads and buffered frames. Use vkResetCommandPool everytime a pool is done being used for that frame. Will need to implement a command buffer manager that manages one command buffer pool per thread id.

Inside one level of graph dependency (where all tasks in that level can run in parallel), we should minimize pipeline changes and group draw calls together as much as possible.

This may lead to having one command buffer per system which could lead to a large amount of command buffers each with a small amount of work. We should be able to put multiple "jobs" or "tasks" inside the same command buffer while not breaking any dependency/scheduling rule.

https://developer.nvidia.com/blog/vulkan-dos-donts/

• The swapchain needs access to the device manager and the surface to check for support.
• Swapchains could be per device or at the application level. To be determined.
• Could have a main device (most performant) used for presentation. The device manager would be aware of which device is the "main" one and so we could create the "main" swapchain based on the physical properties of that main device.

• Create empty components that are used as "tags" to help systems differentiate between entities that have otherwise the same archetype

Creating many entities that could reuse the same descriptor set should not blow up the descriptor pool. Need to verify whether we can reuse descriptor sets across command buffers so we can reuse them across frames and just update them when needed. Since it's always the same resources, there should be no need to keep allocating new descriptor sets.

Make it so that we can render renderable components with different pipelines easily.

Some pipelines don't require the model matrix push constant or the scene UBOs. Make it so that these are optional depending on the current pipeline being drawn. This could lead to descriptors being re-updated or re-bound for no reason so minimize this.

In order to give more flexibility.
Create the following creation infos:

• Swapchain
• Pipeline
• Rendering State

Create a log utility tool with different severity levels and formatting options.

• Add a log when failing to create the main swapchain since it is not a fatal failure but the user should be alerted that it failed.

Have an interface that is able to be initialized/unitialized with different APIs (VK, D3D12, GL) dynamically during runtime. Ideally, we should be able to switch APIs while running the application.

Figure out a way to abstract away staging from the client's perspective. This means we need a way to keep these buffers alive until the command list that is attached to them is done. When it is done, we need to flag those buffers as unused so that the next cleanup recycles them.

The amount of rendering pipeline descriptions are about to blow up because of all the possible combinations. Research and implement a way to keep code bloating to a minimum but make it easy to create new pipelines.

Blobs yay

Since we wait on the transfer command lists to finish before actually starting the application, it feels very unresponsive and it can be very long before we even see anything.

Could only draw the renderable entities whose resources have all been loaded.

Note: I implemented this to make the number of lights dynamic through a constant declared during pipeline creation but turns out:

"Arrays inside a block may be sized with a specialization constant, the block will have a static layout. Changing the specialized size will not re-layout the block. In the absence of explicit offsets, the will be based on the default size of the array."

From: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt

• Handle Implementation
• Handle Manager implementation

Some cool links:
http://gamesfromwithin.com/managing-data-relationships

https://blog.molecular-matters.com/2013/05/02/adventures-in-data-oriented-design-part-3a-ownership/

• Decouple RenderPass from Pipeline

• They should be two different things. The render system should be the one managing the render passes, not the RenderableComponent
• BeginRenderPass should be able to be called before BindPipeline

• Expose the concepts of render passes and subpasses to the GRIS
• Make barriers work somehow
• Decide whether I want systems to be per render pass and manage their own render pass (attachments, subpasses)
• Redo the resource binding (description set) to fit in a traditional render loop.