Raster Pipeline & Operations

[Furkan Can TURAN]

Raster pipeline & operations are complex across different graphics APIs, so they're documented here.

Vulkan:

Designed for mobile GPUs, not relevant to any current desktop GPUs. Raster pipelines store so much information about execution, but none of the desktop applications are developed that way and desktop GPUs don't use such execution-time information to optimize. Mobile applications have so much less states and variations and mobile GPUs can optimize using execution-time information. Desktop: Generic info, Mobile: Generic + Execution Info. Common ground here is generic info & with the dynamic rendering vulkan device extension , we don't need execution info beforehand.

VK_KHR_dynamic_rendering support
The vkExtension isn't supported by mobile platforms, Kepler GPUs and drivers prior to 2022. Mobile platforms need execution time info anyway, so don't need this extension. Driver update is enough for all GPUs on Windows/Linux except Kepler GPUs. Kepler GPUs supports DX12, so dynamic rendering is supported architecturally. The problem is Nvidia doesn't give driver updates to them which means the vkExtension isn't supported (2022 extension, last driver 2021). So users that wants to support Kepler GPUs should use DirectX12 backend.

Mobile & Execution-time Info:
Mobile GPU hardwares are Tile-Based Renderers (TBR). There a lot of good example of Vulkan's best practices with TBRs. Key points are:

1. Use as less persistent resources as possible to avoid actual memory load & stores at render pass begin/end. Also don't exceed tile cache's limit with render targets as it will reduce tile size, so will performance.
2. Can't use compute & transfer in renderpass because they need actual memory accesses (which is exact opposite of renderpasses). So don't use compute & transfer as much as possible (raster techniques > compute techniques).
3. Pipelines & secondary command buffers should be created/recorded with such informations to optimize as much as possible.

DirectX12:

Designed for desktop GPUs, so doesn't support renderpasses by default. RenderTarget formats are specified at raster pipeline compilation-time & actual render target is bound in command buffers. With RenderPass extension (recent Windows & driver versions), it's in the same page with Vulkan's VK_KHR_dynamic_rendering extension. Compute & transfer command operations aren't allowed in a Renderpass.

Implementation:

Raster Pipeline in TGFX targets 2 types of users: Users that supports TBRs as less as possible (only possible on desktop) & users that wants their application be extremely optimized & specifically designed to get best performance from TBRs (only possible on mobile). This design is bad for users that wants first path on mobile, but they're targeting a very bad platform so they need to know the platforms limits.

RenderPasses on both APIs are called TGFX_RasterPass but TGFX_RasterPass isn't an object. User can start a RasterPass with renderer->beginRasterpass(colorAttachments, depthAttachment). You can't call compute & transfer command bundle operations. Vulkan subpasses are only supported in TGFX_Subpass extension and each vulkan subpass has unique TGFX_SubRasterpass object.

Users have to use TGFX_Subpass extension on mobile platforms because VK_KHR_dynamic_rendering isn't supported. TGFX_Subpass should be designed as helpful as possible and simple applications can use single subpass in a raster pass. An example is implemented in 1e2a2b9 commit.