<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx" -->

---
title: Bridging the synchronization gap on Linux | daily.dev
description: Linux Vulkan drivers have long struggled with a fundamental mismatch: Vulkan uses explicit synchronization for maximum GPU/CPU parallelism, but Linux window...
canonical: https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Bridging the synchronization gap on Linux | daily.dev
og:description: Linux Vulkan drivers have long struggled with a fundamental mismatch: Vulkan uses explicit synchronization for maximum GPU/CPU parallelism, but Linux window...
og:url: https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx
og:image: https://api.daily.dev/og/posts/zpBPTC0DX.png
og:image:alt: Bridging the synchronization gap on Linux
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.

# Bridging the synchronization gap on Linux

**[Collabora Blog](https://daily.dev/sources/collabora)** · 20 min read · 0 upvotes · 0 comments

## Summary

Linux Vulkan drivers have long struggled with a fundamental mismatch: Vulkan uses explicit synchronization for maximum GPU/CPU parallelism, but Linux window systems (X11, Wayland) rely on implicit synchronization via kernel dma-buf reservation objects. Every driver (RADV, ANV/Intel) has had its own hacky workaround, all causing over-synchronization somewhere. The solution is two new ioctls on dma-buf file descriptors (targeting Linux 5.19/5.20) that let userspace export and import sync files directly from reservation objects. This allows Mesa Vulkan WSI code to bridge the gap cleanly: exporting implicit fences as sync files for vkAcquireNextImageKHR and importing explicit semaphores back as implicit fences for vkQueuePresentKHR. The approach is backward-compatible, works with existing OpenGL compositors, and also enables writing Wayland compositors entirely in Vulkan. The kernel-level fix was preferred over a Wayland-protocol-only approach because Linux's heterogeneous component versioning makes atomic rollouts impossible, and the ioctl can be detected at driver init time before any window system connection is established.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://www.collabora.com/news-and-blog/blog/2022/06/09/bridging-the-synchronization-gap-on-linux>

## Questions this post answers

### Why can't Vulkan drivers on Linux just use implicit synchronization like OpenGL does?

Using implicit synchronization in Vulkan would completely serialize all GPU work. Vulkan sub-allocates images from larger memory objects, so kernel implicit sync (which operates at memory-object granularity) would synchronize every job touching the same allocation even if they access independent images. Bindless and buffer device address make it impossible to know which memory objects a command buffer uses, so everything would synchronize on everything else, killing multi-queue parallelism entirely.

_Developers working on Vulkan drivers or GPU backends track kernel-level changes like these on daily.dev._

### What are the two new dma-buf ioctls added in Linux 5.19/5.20 for synchronization?

Two new ioctls on dma-buf file descriptors let userspace extract and insert fences directly. The first exports all fences from a dma-buf's reservation object as a single sync file, with a flags parameter to specify read, write, or read-write access. The second imports a sync file into the reservation object, also with read/write flags. Together they allow Vulkan drivers to bridge explicit and implicit synchronization without over-synchronization.

_Linux graphics developers keeping up with kernel API changes like these rely on daily.dev for timely coverage._

### Why was a kernel ioctl approach chosen over adding explicit sync support directly to the Wayland protocol?

Linux's heterogeneous nature makes atomic rollouts impossible — distros ship different package versions, LTS releases update selectively, and components must be upgradeable independently. A Wayland-protocol approach would require updating every compositor, adding sync file support to KMS, and some configurations would be permanently stuck on legacy hacks. The ioctl can be detected at Vulkan driver initialization before any window system connection exists, and it lets Vulkan work transparently with existing OpenGL compositors.

_Keeping up with Linux graphics architecture decisions like this is easier when daily.dev surfaces the right posts for your stack._

## Similar posts on daily.dev

- [Mesa 26.2 Merges Vulkan Present Timing Support For X11/XWayland](https://daily.dev/posts/mesa-26-2-merges-vulkan-present-timing-support-for-x11-xwayland-ualbxha4v) · Phoronix · 0 upvotes · 0 comments
- [Linux gaming is getting faster because Windows APIs are becoming Linux kernel features](https://daily.dev/posts/linux-gaming-is-getting-faster-because-windows-apis-are-becoming-linux-kernel-features-hwutw21m3) · XDA Developers · 1 upvotes · 0 comments
- [Cracking Windows Open: Porting RADV to WIN32](https://daily.dev/posts/cracking-windows-open-porting-radv-to-win32-f2n59xdec) · Hacker News · 0 upvotes · 0 comments
- [Investigating Linux graphics](https://daily.dev/posts/investigating-linux-graphics-pt8vvc5hu) · Lobsters · 0 upvotes · 0 comments

---

Tags: [#linux](https://daily.dev/tags/linux), [#vulkan](https://daily.dev/tags/vulkan)

[View this post on daily.dev](https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx)

```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":"Bridging the synchronization gap on Linux","url":"https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx"},"datePublished":"2026-08-11T08:54:10.439Z","dateModified":"2026-08-11T09:18:57.045Z","description":"Linux Vulkan drivers have long struggled with a fundamental mismatch: Vulkan uses explicit synchronization for maximum GPU/CPU parallelism, but Linux window...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/75fb617c0b46d0e8ee83e2b4c34c0ba9?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/75fb617c0b46d0e8ee83e2b4c34c0ba9?_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/bridging-the-synchronization-gap-on-linux-zpbptc0dx","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,vulkan","timeRequired":"PT20M"}
{"@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":"Bridging the synchronization gap on Linux"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/bridging-the-synchronization-gap-on-linux-zpbptc0dx#faq","mainEntity":[{"@type":"Question","name":"Why can't Vulkan drivers on Linux just use implicit synchronization like OpenGL does?","acceptedAnswer":{"@type":"Answer","text":"Using implicit synchronization in Vulkan would completely serialize all GPU work. Vulkan sub-allocates images from larger memory objects, so kernel implicit sync (which operates at memory-object granularity) would synchronize every job touching the same allocation even if they access independent images. Bindless and buffer device address make it impossible to know which memory objects a command buffer uses, so everything would synchronize on everything else, killing multi-queue parallelism entirely. Developers working on Vulkan drivers or GPU backends track kernel-level changes like these on daily.dev."}},{"@type":"Question","name":"What are the two new dma-buf ioctls added in Linux 5.19/5.20 for synchronization?","acceptedAnswer":{"@type":"Answer","text":"Two new ioctls on dma-buf file descriptors let userspace extract and insert fences directly. The first exports all fences from a dma-buf's reservation object as a single sync file, with a flags parameter to specify read, write, or read-write access. The second imports a sync file into the reservation object, also with read/write flags. Together they allow Vulkan drivers to bridge explicit and implicit synchronization without over-synchronization. Linux graphics developers keeping up with kernel API changes like these rely on daily.dev for timely coverage."}},{"@type":"Question","name":"Why was a kernel ioctl approach chosen over adding explicit sync support directly to the Wayland protocol?","acceptedAnswer":{"@type":"Answer","text":"Linux's heterogeneous nature makes atomic rollouts impossible — distros ship different package versions, LTS releases update selectively, and components must be upgradeable independently. A Wayland-protocol approach would require updating every compositor, adding sync file support to KMS, and some configurations would be permanently stuck on legacy hacks. The ioctl can be detected at Vulkan driver initialization before any window system connection exists, and it lets Vulkan work transparently with existing OpenGL compositors. Keeping up with Linux graphics architecture decisions like this is easier when daily.dev surfaces the right posts for your stack."}}]}
```

