Added initial implementation of Vulkan Render Passes.

gpu/vulkan/vulkan_render_pass.h

+// Copyright (c) 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef GPU_VULKAN_VULKAN_RENDER_PASS_H_
+#define GPU_VULKAN_VULKAN_RENDER_PASS_H_
+
+#include <vulkan/vulkan.h>
+#include <vector>
+
+#include "base/macros.h"
+#include "gpu/vulkan/vulkan_export.h"
+
+namespace gpu {
+
+class CommandBufferRecorderBase;
+class VulkanImageView;
+class VulkanSwapChain;
+
+class VULKAN_EXPORT VulkanRenderPass {
+ public:
+  enum class AttachmentType {
+    // Use image view of the swap chain image.
+    ATTACHMENT_TYPE_SWAP_IMAGE,
+
+    // Use image view of the attachment data.
+    ATTACHMENT_TYPE_ATTACHMENT_VIEW,
+  };
+
+  enum class ImageLayoutType {
+    // Undefined image layout.
+    IMAGE_LAYOUT_UNDEFINED,
+
+    // Image layout whiches matches the image view.
+    IMAGE_LAYOUT_TYPE_IMAGE_VIEW,
+
+    // Image layout for presenting.
+    IMAGE_LAYOUT_TYPE_PRESENT,
+  };
+
+  struct AttachmentData {
+    AttachmentType attachment_type;
+    VkSampleCountFlagBits sample_count;
+    VkAttachmentLoadOp load_op;
+    VkAttachmentStoreOp store_op;
+    // The stencil ops are only sued for IMAGE_TYPE_STENCIL and

[piman, 2016/03/25 02:01:26]

nit: sued->used

[David Yen, 2016/03/25 17:36:14]

Done.

+    // IMAGE_TYPE_DEPTH_STENCIL image views.
+    VkAttachmentLoadOp stencil_load_op;
+    VkAttachmentStoreOp stencil_store_op;
+    ImageLayoutType start_layout;
+    ImageLayoutType end_layout;
+    uint32_t num_image_views;  // If more than 1, must match swap chain count.

[piman, 2016/03/25 02:01:26]

I'm not exactly sure why you need this, or what it means really. You can only
have 1 image view per attachment on a given framebuffer.

[David Yen, 2016/03/25 17:36:14]

So this attachment data is meant to used to create all the framebuffers
internally. A framebuffer gets created for every image in the swap chain. If
someone wants to have a single image view for every frame buffer then they would
use a single one, if someone wants to have an image view for every corresponding
swap chain image then they would have multiple (the same amount as the swap
chain image count).

[piman, 2016/03/25 21:13:22]

I think I understand. It's hard to imagine a use case for that - presumably we
never use different swap chain images concurrently in the same frame, so any
temporary render target can just be reused across frames. We certainly don't
have anything like that in the compositor today.

[David Yen, 2016/03/26 00:33:30]

Ok, removed.

+    VulkanImageView* image_views;  // used for ATTACHMENT_TYPE_ATTACHMENT_VIEW.

[piman, 2016/03/25 02:01:26]

Why plural?

+    VkClearValue clear_value;      // used for VK_ATTACHMENT_LOAD_OP_CLEAR.
+
+    bool ValidateData(const VulkanSwapChain* swap_chain) const;
+  };
+
+  struct SubpassAttachment {
+    uint32_t attachment_index;
+    ImageLayoutType subpass_layout;
+  };
+
+  struct SubpassData {
+    SubpassData();
+    ~SubpassData();
+
+    std::vector<SubpassAttachment> subpass_attachments;
+
+    bool ValidateData(uint32_t num_attachments) const;
+  };
+
+  struct RenderPassData {
+    RenderPassData();
+    ~RenderPassData();
+
+    std::vector<AttachmentData> attachments;
+    std::vector<SubpassData> subpass_datas;
+
+    bool ValidateData(const VulkanSwapChain* swap_chain) const;
+  };
+
+  VulkanRenderPass();
+  ~VulkanRenderPass();
+
+  bool Initialize(const VulkanSwapChain* swap_chain,

[piman, 2016/03/25 02:01:26]

Do you have to pass a SwapChain here?
What if I want to make a render pass for offscreen buffers?

[David Yen, 2016/03/25 17:36:14]

We will probably have to create another Initialize function for that and error
if ATTACHMENT_TYPE_SWAP_IMAGE is used. Some other things will have to be thought
about too. Here I am automatically creating a frame buffer for every swap chain
image, would we only want 1 framebuffer for offscreen buffers? or have them be
able to specify the number of frame buffers?

[piman, 2016/03/25 21:13:22]

I don't see a use case to do more than one.

Well, we may want to decouple the framebuffer from the render pass. The render
pass affects pipeline compilation, and we definitely want to keep the same
pipelines for all compositor passes to avoid a combinatorial explosion. But
that's orthogonal. We can do that as a follow up (similar to RP Instance).

[David Yen, 2016/03/26 00:33:30]

Acknowledged.

+                  const RenderPassData& render_pass_data);
+  void Destroy();
+
+  // Begins render pass to command_buffer. The variable exec_inline signifies
+  // whether or not the subpass commands will be executed inline (within a
+  // primary command buffer) or whether it will be executed through a secondary
+  // command buffer.
+  void BeginRenderPass(const CommandBufferRecorderBase& recorder,
+                       bool exec_inline);

[piman, 2016/03/25 02:01:26]

This is ok as a first step, but I think eventually we'll want to separate the
RenderPass from the RenderPass instance. After the RenderPass is created, it's
immutable, and that's a useful property because it's trivial to share across
threads. If it can be mutable (current_sub_pass_/executing_/execution_type_)
then you need locking and you lose the benefits of threading.
One example could be to have BeginRenderPass return a RenderPassInstance that
contains that state, and either NextSubPass/EndRenderPass are methods on it, or
they stay here but take the RenderPassInstance as a parameter.

[David Yen, 2016/03/25 17:36:14]

Hmm that is interesting. Acknowledged.

+
+  // Begins the next subpass after BeginRenderPass has been called.
+  void NextSubPass(const CommandBufferRecorderBase& recorder);
+
+  // Ends the render passes.
+  void EndRenderPass(const CommandBufferRecorderBase& recorder);
+
+  void SetClearValue(uint32_t attachment_index, VkClearValue clear_value);
+
+ private:
+  const VulkanSwapChain* swap_chain_ = nullptr;
+  uint32_t num_sub_passes_ = 0;
+  uint32_t current_sub_pass_ = 0;
+  bool executing_ = false;
+  VkSubpassContents execution_type_ = VK_SUBPASS_CONTENTS_INLINE;
+  VkRenderPass render_pass_ = VK_NULL_HANDLE;
+
+  // There is 1 clear color for every attachment which needs a clear.
+  std::vector<VkClearValue> attachment_clear_values_;
+
+  // There is 1 clear index for every attachment which needs a clear. This is
+  // kept in a separate array since it is only used setting clear values.
+  std::vector<uint32_t> attachment_clear_indexes_;
+
+  // There is 1 frame buffer for every swap chain image.
+  std::vector<VkFramebuffer> frame_buffers_;
+
+  DISALLOW_COPY_AND_ASSIGN(VulkanRenderPass);
+};
+
+}  // namespace gpu
+
+#endif  // GPU_VULKAN_VULKAN_RENDER_PASS_H_