--- title: How to share code between Vulkan and Gallium | daily.dev description: Faith Ekstrand outlines architectural principles for sharing code between Vulkan and Gallium drivers in Mesa, drawing from experience building NVK (NVIDIA's... canonical: https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How to share code between Vulkan and Gallium | daily.dev og:description: Faith Ekstrand outlines architectural principles for sharing code between Vulkan and Gallium drivers in Mesa, drawing from experience building NVK (NVIDIA's... og:url: https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu og:image: https://api.daily.dev/og/posts/ZyPGz03zU.png og:image:alt: How to share code between Vulkan and Gallium og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How to share code between Vulkan and Gallium **[Collabora Blog](https://daily.dev/sources/collabora)** · 15 min read · 0 upvotes · 0 comments ## Summary Faith Ekstrand outlines architectural principles for sharing code between Vulkan and Gallium drivers in Mesa, drawing from experience building NVK (NVIDIA's Vulkan driver). Three main areas are covered: (1) a hardware-focused device info struct (like nv_device_info) that is stateless and immutable, distinct from pipe_screen; (2) a separate image layout library (like NIL or ISL) that describes hardware surfaces independently of memory and API-level concerns; and (3) compiler structuring advice — making the back-end consume hardware-native ops, minimizing sideband data, and using a three-stage pipeline (pre-processing, driver lowering, back-end) to cleanly separate API-specific logic from shared compiler code. Examples from NVIDIA (NVK/NIL) and Intel (Iris/ISL) illustrate each principle. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between a device info struct and pipe_screen in Mesa driver development? A device info struct (like nv_device_info) is a stateless, immutable description of hardware attributes — chipset, shader core counts, class versions — with no kernel or software state. pipe_screen, by contrast, is a stateful object containing buffer and shader caches, designed to tell Gallium about the driver. A better Gallium-to-Vulkan mapping is pipe_screen → VkDevice and pipe_context → VkQueue. _GPU driver developers navigating the Gallium-to-Vulkan transition track design decisions like these on daily.dev._ ### How should I structure a shared image layout library for both Vulkan and Gallium drivers in Mesa? The image layout library should describe hardware surfaces independently of memory and API-level concerns. It should not know about GPU memory until descriptor fill time, when the driver passes a 64-bit GPU address. This separation enables re-description tricks — like returning a single LOD of a 3D image as a 2D array — and makes emulation (YCbCr, shadow surfaces) cleaner by keeping hardware capabilities separate from software workarounds. _Engineers building Mesa drivers share approaches like this on daily.dev._ ### How should I structure the compiler pipeline to share a back-end between OpenGL and Vulkan drivers? Use roughly three stages: API-specific pre-processing (SPIR-V parsing, early optimization), driver-level NIR lowering passes that translate API bindings to hardware-native ops, and a back-end compiler that consumes hardware-native intrinsics (e.g., load/store_global instead of load/store_ssbo). Minimize sideband data returned from the back-end. The boundary after pre-processing is also a natural shader cache point, since it is independent of descriptor set layouts. _Developers working on Mesa compiler architecture find related deep-dives on daily.dev._ ## Similar posts on daily.dev - [Imagination Talks Up Their Open-Source Vulkan Driver, Volcanic Architecture Plans](https://daily.dev/posts/imagination-talks-up-their-open-source-vulkan-driver-volcanic-architecture-plans-4jp2nhfyg) · Phoronix · 0 upvotes · 0 comments - [Igniting the GPU: From Kernel Plumbing to 3D Rendering on RISC-V](https://daily.dev/posts/igniting-the-gpu-from-kernel-plumbing-to-3d-rendering-on-risc-v-n3d4nu797) · Hacker News · 1 upvotes · 0 comments --- Tags: [#vulkan](https://daily.dev/tags/vulkan), [#mesa](https://daily.dev/tags/mesa) [View this post on daily.dev](https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How to share code between Vulkan and Gallium","url":"https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu"},"datePublished":"2026-08-11T08:55:00.575Z","dateModified":"2026-08-11T09:01:46.802Z","description":"Faith Ekstrand outlines architectural principles for sharing code between Vulkan and Gallium drivers in Mesa, drawing from experience building NVK (NVIDIA's...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8676ff78fb3bad843e9ac0ce4d8ed9d1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/8676ff78fb3bad843e9ac0ce4d8ed9d1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collabora Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collabora Blog","logo":"https://media.daily.dev/image/upload/s--ZGZ0FjqS--/f_auto,q_auto/v1786438306/logos/collabora?_a=BAMAMicg0","url":"https://daily.dev/sources/collabora"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"vulkan,mesa","timeRequired":"PT15M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collabora Blog","item":"https://daily.dev/sources/collabora"},{"@type":"ListItem","position":3,"name":"How to share code between Vulkan and Gallium"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-to-share-code-between-vulkan-and-gallium-zypgz03zu#faq","mainEntity":[{"@type":"Question","name":"What is the difference between a device info struct and pipe_screen in Mesa driver development?","acceptedAnswer":{"@type":"Answer","text":"A device info struct (like nv_device_info) is a stateless, immutable description of hardware attributes — chipset, shader core counts, class versions — with no kernel or software state. pipe_screen, by contrast, is a stateful object containing buffer and shader caches, designed to tell Gallium about the driver. A better Gallium-to-Vulkan mapping is pipe_screen → VkDevice and pipe_context → VkQueue. GPU driver developers navigating the Gallium-to-Vulkan transition track design decisions like these on daily.dev."}},{"@type":"Question","name":"How should I structure a shared image layout library for both Vulkan and Gallium drivers in Mesa?","acceptedAnswer":{"@type":"Answer","text":"The image layout library should describe hardware surfaces independently of memory and API-level concerns. It should not know about GPU memory until descriptor fill time, when the driver passes a 64-bit GPU address. This separation enables re-description tricks — like returning a single LOD of a 3D image as a 2D array — and makes emulation (YCbCr, shadow surfaces) cleaner by keeping hardware capabilities separate from software workarounds. Engineers building Mesa drivers share approaches like this on daily.dev."}},{"@type":"Question","name":"How should I structure the compiler pipeline to share a back-end between OpenGL and Vulkan drivers?","acceptedAnswer":{"@type":"Answer","text":"Use roughly three stages: API-specific pre-processing (SPIR-V parsing, early optimization), driver-level NIR lowering passes that translate API bindings to hardware-native ops, and a back-end compiler that consumes hardware-native intrinsics (e.g., load/store_global instead of load/store_ssbo). Minimize sideband data returned from the back-end. The boundary after pre-processing is also a natural shader cache point, since it is independent of descriptor set layouts. Developers working on Mesa compiler architecture find related deep-dives on daily.dev."}}]} ```