Migrating from OpenGL to Vulkan
Download as PPTX, PDF17 likes5,617 views
1. The document discusses migrating from OpenGL to Vulkan, providing analogies comparing the APIs to fixed-function toys, programmable LEGO kits, and raw materials pine wood derby kits. 2. It outlines scenarios that are likely and unlikely to benefit from Vulkan, such as applications with parallelizable CPU-bound graphics work. 3. Key differences between OpenGL and Vulkan are explained, such as Vulkan requiring explicit management of graphics resources, synchronization, and command buffer queuing. The document emphasizes that transitioning to Vulkan truly rethinks the entire graphics rendering approach.
Migrating from OpenGL to Vulkan
- 1. Mark Kilgard, January 19, 2016 Migrating from OpenGL to Vulkan
- 2. 2 About the Speaker Mark Kilgard Principal Graphics Software Engineer in Austin, Texas Long-time OpenGL driver developer at NVIDIA Author and implementer of many OpenGL extensions Collaborated on the development of Cg First commercial GPU shading language Recently working on GPU-accelerated vector graphics (Yes, and wrote GLUT in ages past) Who is this guy?
- 3. 3 Motivation for Talk What kinds of apps benefit from Vulkan? How to prepare your OpenGL code base to transition to Vulkan How various common OpenGL usage scenarios are re-thought in Vulkan Re-thinking your application structure for Vulkan Coming from OpenGL, Preparing for Vulkan
- 5. 5 Analogy Fixed-function OpenGL Pre-assembled toy car fun out of the box, not much room for customization
- 6. 6 Analogy Modern AZDO OpenGL with Programmable Shaders LEGO Kit you build it yourself, comes with plenty of useful, pre-shaped pieces AZDO = Approaching Zero Driver Overhead
- 7. 7 Analogy Vulkan Pine Wood Derby Kit you build it yourself to race from raw materials power tools used to assemble, adult supervision highly recommended
- 8. 8 Analogy Different Valid Approaches Fixed-function OpenGL Modern AZDO OpenGL with Programmable Shaders Vulkan
- 9. 9 Beneficial Vulkan Scenarios Is your graphics work CPU bound? Can your graphics work creation be parallelized? start yes Vulkan friendly yes Has Parallelizable CPU-bound Graphics Work
- 10. 10 Beneficial Vulkan Scenarios Your graphics platform is fixed You’ll do whatever it takes to squeeze out max perf. start yes Vulkan friendly yes Maximizing a Graphics Platform Budget
- 11. 11 Beneficial Vulkan Scenarios You put a premium on avoiding hitches You can manage your graphics resource allocations start yes Vulkan friendly yes Managing Predictable Performance, Free of Hitching
- 12. 12 Unlikely to Benefit 1. Need for compatibility to pre-Vulkan platforms 2. Heavily GPU-bound application 3. Heavily CPU-bound application due to non-graphics work 4. Single-threaded application, unlikely to change 5. App can target middle-ware engine, avoiding direct 3D graphics API dependencies • Consider using an engine targeting Vulkan, instead of dealing with Vulkan yourself Scenarios to Reconsider Coding to Vulkan
- 13. 13 First Steps Migrating to Vulkan Eliminate fixed-function Source all geometry from vertex buffer objects (VBOs) with vertex arrays Use all programmable GLSL shaders with layout() qualifiers Consider using samplers Do all rendering into framebuffer objects (FBOs) Stay within the non-deprecated subset (e.g. no GL_QUADS, for now…) Think about better batching & classify all your render states Avoid depending on OpenGL context state All pretty sensible advice, even if you stick with OpenGL Modernize Your OpenGL
- 14. 14 Next Steps Migrating to Vulkan Think about how your application would handle losing the GPU Similar to ARB_robustness Profile your application, understand what portions are CPU and GPU bound Vulkan most benefits apps bottlenecked on graphics work creation and driver validation Is that your app? Adopt common features available in both OpenGL and Vulkan first in OpenGL Proving out tessellation or multi-draw-indirect probably easier first in your stable OpenGL code base Again all pretty sensible advice, even if you stick with OpenGL Modernize Your OpenGL
- 15. 15 Thinking about Vulkan vs. OpenGL OpenGL, largely understood in terms of Its API, functions for commands and queries And how that API interacts with the OpenGL state machine OpenGL has lots of implicit synchronization Errors handled largely by ignoring command OpenGL API manages various objects But allocation of underlying device resources largely handled by driver + OpenGL Has a Well-established Approach Originally client-server
- 16. 16 Thinking about Vulkan vs. OpenGL Vulkan constructs and submits work for a graphics device Idealized graphics + compute device Requires application to maintain valid Vulkan usage for proper operation Not expected to behave correctly in face of errors, justified for performance Instead of updating state machine, Vulkan is about establishing working relationships between objects Pre-validates operation of actions Vulkan Plays By Different Rules Explicit API Explicit memory management Explicit synchronization Explicit queuing of work Explicit management of buffer state with render passes Not client-server, explicitly depends on shared resources and memory
- 17. 17 Truly Transitioning to Vulkan Much more graphics resource responsibility for the application You need to allocate from large device memory chunk You become responsible for proper explicit synchronization Fences, Barriers, Semaphores Barriers are probably the hardest to appreciate Everything has to be structured as pipeline state objects (PSOs) Understand render passes Think how parallel command buffer generation would operate You become responsible for multi-threaded exclusion of your Vulkan objects Vulkan Done Right Rethinks Entire Graphics Rendering
- 18. 18 Common Graphics Tasks Loading a mipmapped texture Loading a vertex buffer object for rendering Choosing a shader representation and loading shaders Initiating compute work Managing a memory sub-allocator Thinking about render passes Managing Predictable Performance, Free of Hitching
- 19. 19 Loading a Texture Well traveled path via OpenGL 3.0 glBindTexture(GL_TEXTURE_2D, texture_name); glTexImage2D(GL_TEXTURE_2D, 0, GL_SRGB8, width, height, /*border*/0, GL_UNSIGNED_BYTE, GL_RGBA, pixels); glGenerateMipmap(GL_TEXTURE_2D); Does more than you think it does The OpenGL View
- 20. 20 Logical Operations to Load a Texture 1. Create host driver objects corresponding to texture/sampler/image/view/layout 2. Copy call’s image to staging memory accessible to host+device 3. (OpenGL might do a format conversion and pixel transfer) 4. Allocates device memory for texture image for texturing 5. Copy image from host+device memory to device memory for texturing 6. Allocate device resources for sampler 7. Generate mipmap levels
- 21. 21 Various Vulkan Objects “inside” a Texture No such thing as “VkTexture” Instead Texture state in Vulkan = VkDescriptorImageInfo Combines: VkSampler + VkImageView + VkImageLayout Sampling state + Image state + Current image layout Texture binding in Vulkan = part of VkDescriptorSetLayoutBinding Contained with VkDescriptorSetLayout Building Up the OpenGL Texture Object from Vulkan Concepts OpenGL textures are opaque, so lacks an exposed image layout
- 22. 22 Allocating Image Memory for Texture VkImage VkDevice vkGetImageMemoryRequirements VkMemoryRequirements vkBindImageMemory VkDeviceMemory vkAllocateMemory vkCreateImage With VulkanNaïve approach! vkAllocateMemory is expensive. Demos may do this, but real apps should sub-allocate from large VkDeviceMemory allocations See next slide…
- 23. 23 Sub-allocating Image Memory for Texture VkImage VkDevice vkGetImageMemoryRequirements VkMemoryRequirements vkBindImageMemory VkDeviceMemory vkAllocateMemory vkCreateImage One large device memory allocation, assigned to multiple images Proper approach! vkAllocateMemory makes a large allocation with and then sub-allocates enough memory for the image So who writes the sub-allocator? You do!
- 24. 24 Binding Descriptor Sets for a Texture VkDescriptorImageInfoVkSampler VkImageView VkImageLayout VkDescriptorSetLayout VkWriteDescriptorSet vkAllocateDescriptorSets VkPipelineLayout vkCmdBindDescriptorSets VkCommandBuffer vkCreateDescriptorSetLayout vkCreatePipelineLayout vkUpdateDescriptorSets So Pipeline Sees Texture
- 25. 25 Establishing Sampler Bindings for a Pipeline Object VkDescriptorSetLayoutBinding for a sampler binding vkCreateDescriptorSetLayout VkDescriptorSetLayout vkCreatePipelineLayout VkPipelineLayout vkCreateGraphicsPipelines VkPipeline vkCmdBindPipeline Vulkan Pipelines Need to Know How They Will Bind Samplers VkCommandBuffer
- 26. 26 Base Level Specification + Mipmap Generation VkCommandBuffer vkCmdBlitImage vkCmdPipelineBarrier vkCmdBlitImage for each upper mipmap level vkCmdPipelineBarrier Vulkan Command Buffer Orchestrates Blit + Downsamples staging image texture base image texture base image level 1 mipmap level i mipmap level i+1 mipmap
- 27. 27 Binding to a Vertex Array Object (VAO) and Rendering from Vertex Arrays Well traveled path via OpenGL 3.0 glBindVertexArray(vertex_array_object); glDrawElements(GL_TRIANGLES, count, GL_UNSIGNED_INT, indices); Again, does more than you think it does The OpenGL View
- 28. 28 Allocating Buffer Memory for VBO VkBuffer VkDevice vkGetBufferMemoryRequirements VkMemoryRequirements vkBindBufferMemory VkDeviceMemory vkAllocateMemory VkCreateBuffer With VulkanNaïve approach! vkAllocateMemory is expensive. Demos may do this, but real apps should sub-allocate from large VkDeviceMemory allocations
- 29. 29 Binding Vertex State To A Pipeline VkVertexInputBindingDescription VkVertexInputAttributeDescription VkPipelineVertexInputStateCreateInfo VkGraphicsPipelineCreateInfo VkGraphicsPipeline vkCreateGraphicsPipelines So Pipeline Sees Vertex Input State VkPipelineShaderStageCreateInfo VkPipelineInputAssemblyStateCreateInfo VkPipelineViewportStateCreateInfo VkPipelineRasterizationStateCreateInfo VkPipelineMultisampleStateCreateInfo VkPipelineDepthStencilStateCreateInfo VkPipelineColorBlendStateCreateInfo VkPipelineDynamicStateCreateInfo
- 30. 30 Binding Vertex Buffer For Drawing For the vertex input statevkCmdBindPipeline Buffer Binding Is Performed With The Command Queue vkCmdBindVertexBuffers For the vertex data vkCmdBeginRenderPass vkCmdBindDescriptorSets vkCmdDrawIndexed vkCmdEndRenderPass Begin Drawing Draw End Drawing
- 31. 31 Big Features, Ready for Vulkan Compute shaders Tessellation shaders Geometry shaders Sparse resources (textures and buffers) In OpenGL 4.5 today Vulkan has the same big features, just different API Mostly the same GLSL can be used in either case Prototype in OpenGL now, Enable in Vulkan next
- 32. 32 Thinking about render passes OpenGL just has commands to draw primitives No explicit notion of a render pass in OpenGL API Vulkan does have render passes, VkRenderPass Includes notion of sub-passes Designed to facilitate tiling architectures Bounds the lifetime of intermediate framebuffer results Allows iterating over subpasses (chunking) within a render pass on a per tile basis In most cases, you won’t need to deal with subpasses How do rendering operations affect the retained framebuffer?
- 33. 33 Render Pass Describes the list attachments the render pass involves Each attachment can specify How the attachment state is initialized (loaded, cleared, dont-care) How the attach state is stored (store, or dont-care) Don’t-care allows framebuffer intermediates to be discarded E.g. depth buffer not needed after the render pass How the layout of attachment could change Sub-pass dependencies indicate involvement of attachments within a subpass What does a Vulkan Render Pass Provide?
- 34. 34 Render Passes vkCmdBeginRenderPass vkCmdEndRenderPass vkCmdBeginRenderPass vkCmdNextSubpass vkCmdNextSubpass vkCmdEndRenderPass Monolithic or Could Have Sub-passes Each subpass has its own description and dependencies Simple render pass, no subpasses Complex render pass, with multiple subpasses
- 35. 35 Vulkan Application Structure Parallel Command Buffer Generation Traditional single-threaded OpenGL app structure update scene draw scene single thread Possible multi-threaded Vulkan app structure collect secondary command buffers distribute update scene work submit command buffer build secondary command buffer work thread build secondary command buffer work thread build secondary command buffer work thread build secondary command buffer work thread
- 36. 36 Conclusions Vulkan is a radical departure from OpenGL Modernizing your OpenGL code base is definitely good for moving to Vulkan But it will take more work than that! Vulkan’s explicitness makes simple operations like a texture bind quite involved Think about multi-threaded command buffer creation Get Ready for Vulkan