Hi,
After some investigation within the specs, it seems to me that the paradigm of pipeline already existing in Mantle & D3D12 APIs (which describe in a single object all the shader stages, the output(s) format, the inputs -resources & vertex fetching- & the render state), is somewhat basically split into several objects: Pipeline + RenderPass (&subpasses) + frameBuffer.
I understand this could allow a better re-use when an existing or new engine can do it, but when it’s no, would having a very basic 1-1 association be a very bad idea ?
I mean always having one renderPass and one frameBuffer object created for every created pipeline -so something more similar to other APIs-.
What could be the negative impact of this ? only more RAM consumption ? less performances on the driver due to lack of ‘hint’ ?
Thanks.
Vulkan’s render pass architecture exists to serve needs that Direct3D 12 and Mantle never encountered: mobile hardware.
The render pass system exists to handle tile-based renderers. It allows TBRs to do various cool stuff that they could not do otherwise. Consider a deferred rendering system. You render to your G-buffers, then read from your G-buffers and write to your color buffer, maybe do some blending to the color buffer, then read from the color buffer to do light scaling and write to the final output. Each of these would be a subpass.
With a TBR, you could in theory do all of this without ever touching main memory, except for at the very end when you write the tile data to memory. If all of your g-buffers fit into the available tile memory, then the deferred subpass just writes to tile memory. The second pass reads from tile memory and writes color data to tile memory. The third subpass blends to tile memory. And the fourth reads from tile memory and writes to tile memory.
Those g-buffers never get written to (or read from) main memory. In theory (there are things that could prevent the hardware from being able to optimize like this, such as shoving too much geometry at it).
Even for non-TBRs, the notion of subpasses and input attachments has merit. The constructs allow them to know when they need to clear framebuffer caches, and it makes it clear in the API itself when you’re doing a read/modify/write to the framebuffer from the fragment shader. The API doesn’t allow you to try to read an input attachment from any location other than the current FS invocation’s sample.
So your question is backwards: what is the positive impact of removing the renderpass construct? Just to be “more similar to other APIs”? It would only be “more similar” to Mantle and D3D12; Metal has its own render pass construct, though one that’s simpler than Vulkans.