Merge pull request #159 from o3de/RPI_Subpasses

Added first version of the document as a means
to create the first valid shareable link.

rfcs/SubpassesSupportInRPI/RFC_SubpassesSupportInRPI.md

@@ -0,0 +1,49 @@
+Background History:
+Vulkan requires a valid VkRenderPass when creating a Pipeline State Object for any given shader.
+PSO creation usually occurs way earlier than when the RHI creates a VkRenderPass for RHI::Scopes.
+Vulkan "only" requires that both VkRenderPasses to be compatible, but they don't have to be same.
+
+Pseudo runtime example with Two INDEPENDENT VkRenderPasses:
+At time 1, during RPI::RasterPass Initialization:
+    Create dummy "VkRenderPass_A" for a shader named "PSO_A".
+    Create "PSO_A" using "VkRenderPass_A".
+At time 2, during another RPI::RasterPass Initialization:
+    Create dummy "VkRenderPass_B" for a shader named "PSO_B".
+    Create "PSO_B" using "VkRenderPass_B".
+At time 3, in the future, when the RHI builds the Frame Graph:
+    Create Scope_A with "VkRenderPass_C"
+    Create Scope_B with "VkRenderPass_D"
+At time 4, when the RHI submits commands
+    VkCmdBeginRenderPass (VkRenderPass_C)
+        VkCmdBindPipeline(PSO_A that was created with VkRenderPass_A)  // VkRenderPass_A must bepatible" with VkRenderPass_C.
+        VkCmdDraw(...)
+    VkCmdEndRenderPass (VkRenderPass_C)
+    VkCmdBeginRenderPass (VkRenderPass_D)
+        VkCmdBindPipeline(PSO_B that was created with VkRenderPass_B) // VkRenderPass_D must bepatible" with VkRenderPass_B.
+        VkCmdDraw(...)
+    VkCmdEndRenderPass (VkRenderPass_D)
+In the example above, because it is NOT using subpasses, it is relatively easy to make compatiblenderPasses.
+Also, this abstract class did NOT exist and WAS NOT necessario in that scenario.
+Subpasses is the mechanism by which Vulkan provides programmable controls to get maximum performance ofd Based GPUs.
+So, assuming the pipeline mentioned above can be merged as subpasses the timeline would look like this.
+At time 1, during RPI::RasterPass Initialization:
+    Create dummy "VkRenderPass_A" for a shader named "PSO_A".
+    Create "PSO_A" using "VkRenderPass_A".
+At time 2, during another RPI::RasterPass Initialization:
+    Create dummy "VkRenderPass_B" for a shader named "PSO_B".
+    Create "PSO_B" using "VkRenderPass_B".
+At time 3, in the future, when the RHI builds the Frame Graph:
+    Create Scope_A and Scope_B as subpasses with "VkRenderPass_C"
+At time 4, when the RHI submits commands
+    VkCmdBeginRenderPass (VkRenderPass_C)
+        VkCmdBindPipeline(PSO_A that was created with VkRenderPass_A)  // VkRenderPass_A must bepatible" with VkRenderPass_C.
+        VkCmdDraw(...)
+    VkCmdNextSubpass(1)
+        VkCmdBindPipeline(PSO_B that was created with VkRenderPass_B) // VkRenderPass_B must bepatible" with VkRenderPass_C
+        VkCmdDraw(...)
+    VkCmdEndRenderPass (VkRenderPass_C)
+When declaring Subpass Dependencies (Which is required during VkRenderPass creation), it was found thatan is very strict
+when validating Compatibility. In the end it boiled down to make sure that all VkRenderPasses must haveTICAL Subpass Dependencies
+otherwise vulkan would trigger validation errors. And this is why this abstract class was introduced.use it helps to encapsulate
+all the details required for creating VkSubpassDependency (for Vulkan) and share the exact same information creating all related
+VkRenderPasses.