GrVkGpu initialization cleanup.

include/gpu/vk/GrVkBackendContext.h

Index: include/gpu/vk/GrVkBackendContext.h
diff --git a/include/gpu/vk/GrVkBackendContext.h b/include/gpu/vk/GrVkBackendContext.h
new file mode 100644
index 0000000000000000000000000000000000000000..7bfa02aab09e69d3b6b9c7199ebee79aeb3fbe78
--- /dev/null
+++ b/include/gpu/vk/GrVkBackendContext.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2016 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef GrVkBackendContext_DEFINED
+#define GrVkBackendContext_DEFINED
+
+#include "SkRefCnt.h"
+
+#include "vulkan/vulkan.h"
+
+#ifdef SK_DEBUG
+#define ENABLE_VK_LAYERS
+#endif
+
+struct GrVkInterface;
+
+// The BackendContext contains all of the base Vulkan objects needed by the GrVkGpu. The assumption
+// is that the client will set these up and pass them to the GrVkGpu constructor. The VkDevice
+// created must support at least one graphics queue, which is passed in as well. The client may
+// create more than one queue (reserving one for swap chain presentation, for example).
+struct GrVkBackendContext : public SkRefCnt {

[egdaniel, 2016/03/23 14:51:57]

Does the comment about more than one queue add anything here besides confusion?
We will never accept more than one queue, and seems like that is purely a client
specific detail

[jvanverth1, 2016/03/23 15:44:13]

Done.

+    VkInstance                        fInstance;
+    VkPhysicalDevice                  fPhysicalDevice;
+    VkDevice                          fDevice;
+    VkQueue                           fQueue;
+    uint32_t                          fQueueFamilyIndex;

[egdaniel, 2016/03/23 14:51:57]

The fact that we pass in this queue family index has made me think of a slight
issue. When a client passes us in a wrapped texture/render target, we either
need to require they've put a barrier to switch it to the queue they are giving
us here (that's if they created it with sharing mode flag and happen to use a
different queue family when creating the object). Another option would be that
they we add to the GrVkBackendObject a flag for sharing mode and current queue.
Then we would be responsible for switching to our queue family (if different)
and making sure it goes back to their queue family when we are done. I do not
like this second approach.

Just to be clear different queues does not mean they are are in different
families. The typical use case will be that all graphics queues are in the same
family but this is driver implementation dependent.

[jvanverth1, 2016/03/23 15:44:13]

As discussed, the contract with the client will be that they will give us
backend objects in the same family as this index, whether they create them that
way or transition them to it. Noted in the comment above.

+    SkAutoTUnref<const GrVkInterface> fInterface;
+
+    // Helper function to create the default Vulkan objects needed by the GrVkGpu object
+    static const GrVkBackendContext* Create();
+
+    ~GrVkBackendContext() override;
+};
+
+#endif