TODO List

[LukasBanana]

This is an overview of some major bullet points for improvements or unimplemented features in LLGL:

OpenGL Renderer:

• Multi-threading: Deferred command buffer is implemented. The JIT compiler is only experimental and should be disabled for client code.

Vulkan Renderer:

• Resource state transitioning: This is very fragile and needs improvement.
• Memory allocator: I'm still uncertain whether to implement a better memory allocator myself as builtin part of LLGL, or simply switch over to AMD's publicly available VulkanMemoryAllocator. I want to keep the number of external dependencies as low as possible, but regarding Vulkan features it's probably better to use those libraries.
• SPIR-V reflection: I started with a custom SPIR-V parser whose only external dependency is SPIRV-Headers. This either needs to be extended or also switched to another library. SPIRV-Reflect from Google seems promising.
• Multi-sampling support: There is currently no multi-sampling support for the Vulkan backend.
• Conditional rendering: Vulkan needs the VK_EXT_conditional_rendering extension for conditional rendering, but it hasn't been implemented in LLGL yet.
• Stream outputs: Not implemented yet (see SetStreamOutputBuffer etc.). Requires VK_EXT_transform_feedback Vulkan extension.
• Push constants: The new interface of the SetUniform/ SetUniforms functions in CommandBuffer interface is the way to go for Vulkan's "push constants".
• Multi-threading: Implemented for primary command buffers.

D3D11 Renderer:

• Multi-threading: Implemented via deferred context.

D3D12 Renderer:

• Dynamic buffer updates: This must be implemented first. There is currently no proper support to update buffers during command encoding, i.e. CommandBuffer::UpdateBuffer simply does not work correct for the D3D12 backend. A Ring-Buffer implementation may be useful for this purpose.
• MIP-map generator: I started with a D3D12MipGenerator class to generate MIP-maps with a compute shader, like the DX12 example illustrates. Before that, GenerateMips function must be moved from RenderSystem to CommandBuffer interface, or RenderSystem may keep it as a secondary function to be used outside of command encoding.
• Resource state transitioning: This is very fragile and needs improvement.
• Stream outputs: Implemented (see SetStreamOutputBuffer etc.).
• Multi-threading: Implemented for primary command buffers.

Metal Renderer:

• Tessellation example: While tessellation is generally supported, the "Tessellation" example does not work with the Metal backend, because it works fundamentally different in Metal. There are effectively only three shader units: vertex, fragment, and compute. The TessControl shader must be merged into the 'vertex function', and the TessEvaluation shader must be implemented as a 'kernel function'.
• Fences: Fences are currently not implemented in the Metal backend.
• Multi-threading: Implemented for primary command buffers.
• Multi-submit: Implemented and tested.

MacOS Platform:

• Window event handling and resize: The envent handling in the MacOS implementation of the Window interface could be improved. Especially resiying the window does not work properly.

C# Wrapper:

• The C# wrapper is now partially auto-generated and uses P/Invoke instead of C++/CLI.

Further unimplemented/incomplete functions:

• LinuxDisplay::SetDisplayMode
• LinuxDisplay::ResetDisplayMode
• LinuxDisplay::ShowCursor
• LinuxDisplay::IsCursorShown
• LinuxWindow::SetDesc
• LinuxWindow::GetDesc
• D3D12CommandBuffer::ClearAttachments
• D3D12CommandBuffer::CopyBuffer (resource transition/barrieres)
• D3D12CommandBuffer::CopyTexture (resource transition/barrieres)

Future plans:

• Replace CommandBuffer::ResetResourceSlots: This function is only used to circumvent an issue with resource binding with older APIs that do not support descriptor heaps/sets natively. Binding a resource for writing (e.g. a render target) requires the same resource to not be bound at any other binding point for reading. It's not trivial to keep track of each resource where it is bound (potentially at multiple points) in an efficient manner. The ResetResourceSlots function is used so the client programmer can manually unbind resources before binding it for writing (or as UAV in D3D terms). With LLGL having the concept of ResourceHeap, this manual unbinding should not be a requirement. Finding an efficient way to detect resources that need to be unbound is crucial ... and not easy :) (fixed with f492217)
• Better object management in RenderSystem: The Release functions should not delete the objects immediately. Instead, RenderSystem should keep track which objects are still used. For instance, a released Texture object that is still in use in another ResourceHeap should only be deleted when the last ResourceHeap or Texture-view that refers to it is deleted (via reference counter).