Name: XDC 2026 - X.Org Developer's Conference
Start: 2026-09-28T08:00:00-04:00
End: 2026-09-30T18:45:00-04:00
Location: No location set

Monday, 28 September
- 08:00 → 09:00
  
  Breakfast and Registration 1h
- 09:00 → 16:50
  Main Track
  - 09:00
    
    Monday Opening Session 10m
  - 09:15
    
    Is it time for Vulkan Gallium? 45m
    
    When Vulkan 1.0 first came out a decade ago, writing Vulkan drivers was fun. You just mapped API bits to HW bits and off you go! In 2026, with Vulkan 1.4 and hundreds of extensions, it's not so simple. There is legacy cruft we all have to carry. There are 3 versions of some enums which have to be remapped by someone. There are duplicate entrypoints and queries everywhere.
    
    In the OpenGL world, we have an answer for this: Gallium. Is it time for a Gallium for Vulkan? In this presentation, Faith will talk about why she thinks it's time, what that layer would look like, and what it would mean for the Vulkan drivers that exist in the tree today.
    
    Speaker: Dr Faith Ekstrand (Collabora)
    
    2026-09-28 - XDC 2026 - Shiva.pdf
  - 10:05
    Handling XR Displays in the Linux Graphics Stack 20m
    
    In the Linux DRM subsystem, an XR device display is currently exposed as a single, aggregated display. However, treating an XR device like a traditional flat monitor completely breaks the human experience.
    
    Physically, an XR device consists of two distinct displays (one for each eye). Simply pushing standard 2D desktop frames to this aggregated screen results in an unviewable, disorienting output. To produce an image that a human eye can actually process through the headset's optics, the output requires heavy GL/Vulkan-based transformations. These transformations must account for stereoscopic rendering, lens distortion correction (barrel distortion, chromatic aberration), and the physical focal planes of the hardware.
    
    This short talk will outline the disconnect between how DRM sees an XR display and what the human eye physically needs. The primary goal is to trigger an open discussion on the architectural path forward:
    
    Should we add special properties to such display so traditional DRM clients (fb emulation, compositor, ...) avoids considering them as an output ?
    
    How should we properly expose the physical lens and plane characteristics of XR hardware through DRM?
    
    Should the compositor bear the full weight of these rendering transformations, or is there a better abstraction?
    
    How do we standardize the handling of XR displays across the Linux graphics stack to make native XR a reality?
    
    Speakers: Neil Armstrong (Linaro) , Mr Nie Jun (Linaro)
    
    XDC 2026 - Handling XR Displays in the Linux Graphics Stack.pdf
  - 10:30
    
    Next Generation Display Walls on Linux 20m
    
    Display walls, arrays of displays assembled to look like one large screen, have historically been driven by an X server and are typically supported via display technology provided by a vendor's X driver. As the ecosystem migrates to Wayland this architecture is no longer available and a new design must take shape. For this reason, NVIDIA now recommends an explicit Vulkan VK_KHR_display design where applications directly drive displays for more fine-grained control.
    
    This talk will cover how display walls are used, why the X-based design was originally chosen, and why Vulkan Direct 2 Display can provide a better approach. We will discuss Display Config Server, a new open source solution to display wall configuration and persistence, along with future work to help support the next generation of display walls on Linux.
    
    Speaker: Austin Shafer (NVIDIA)
    
    Next Generation Display Walls on Linux.pdf
    
    Next Generation Display Walls on Linux.pptx
  - 10:50
    
    Break 30m
  - 11:20
    
    LLM inference on the Raspberry Pi 5 via Vulkan 45m
    
    The Raspberry Pi 5's Broadcom V3D 7.1 GPU was designed for graphics
    workloads, but the wave of on-device LLM frameworks now directs pure
    compute workloads at the V3DV Vulkan driver. This talk reports what
    we learned extending V3DV for these workloads since early 2026.
    
    ML inference stresses the driver in ways graphics never does: thousands
    of tiny buffer fills and copies per token, heavy buffer-object allocation
    against V3D's 4 GB memory ceiling, shaders with high register pressure,
    and a dependence on fast fp16 support.
    
    We walk through the driver changes this new workload required — enough that
    it is now possible to run open-weight models with inference frameworks
    such as Ollama/llama.cpp and LiteRT-LM.
    
    Finally, the talk discusses future work and the challenges that remain
    to run inference on V3DV.
    
    Speaker: José María Casanova Crespo (Igalia)
    
    xdc2026-llm-inference-rpi5-vulkan.pdf
  - 12:10
    
    nocl: OpenCL on CUDA 20m
    
    Nocl is a gallium driver for use in rusticl to have an Open-Source OpenCL implementation on top of CUDA.
    
    People keep asking about this little side project of mine, so I want to talk about what's the status of the project, what are the difficulties working on it.
    
    I'll go into the overall structure of the project, features there are more interesting to implement, what's still missing before I'm happy enough about it.
    
    Speaker: Karol Herbst (Red Hat, Nouveau)
    
    nocl.html
  - 12:30
    
    Lunch 1h 30m
  - 14:00
    
    SSA-based Register Allocation for Intel GPUs 45m
    
    Intel’s GPUs feature an unusual explicit SIMD instruction set presenting challenges for just-in-time shader compilers. Naïvely modelling Intel’s SIMD architecture artificially increases register pressure and requires expensive register allocation algorithms based on graph colouring. To improve code quality while decreasing compile time, our compiler “Jay” eschews the hardware’s native SIMD in favour of contemporary GPUs’ simpler SIMT model. Our nonlinear remapping of logical SIMT registers onto the physical SIMD register file facilitates near-linear time register allocation with an SSA-based tree scan allocator and a decoupled spiller. Compared to Intel’s existing non-SSA Linux shader compiler, our compiler reduces spilling on a collection of game shaders by 98%. Jay demonstrates the feasibility and profitability of SSA register allocation even for irregular GPU architectures and provides the foundation for Intel’s future Linux shader compilers
    
    Speaker: Alyssa Rosenzweig (Mesa)
    
    slides.pdf
  - 14:50
    
    Optimizing the Panfrost Gallium driver 20m
    
    The performance of the Panfrost driver for Arm's Mali GPUs has improved significantly over the past year, driven by increasing industry adoption. This talk will first cover the evolution of tracing tools in Mesa (Perfetto) and their integration into Panfrost and then present the resulting optimizations (blits, draw calls, Transparent Huge Pages, Transaction Elimination, etc).
    
    Speaker: Loïc Molinari (Collabora Ltd)
    
    optimizing_panfrost.odp
  - 15:15
    
    Demo: Gamma, a ray tracing debugger for Mesa drivers 10m
    
    Almost 6 years after the release VK_KHR_acceleration_structure, ray tracing is still an area in graphics with really bad tooling. Gamma tries to solve this by providing a framework for writing driver specific visualizers. Konstantin will showcase the capabilities using RADV as an example, and how support for other drivers can be added.
    
    Speaker: Konstantin Seurer
    
    presentation.pdf
  - 15:25
    
    Break 30m
  - 16:00
    
    Firefox + Steam Deck: Seamless experience across two compositors 20m
    
    Supporting a major web browser on the Steam Deck brings an exciting challenge because of the unique dual-compositor architecture: Gamescope for game mode and KWin for desktop mode.
    
    This talk covers our ongoing efforts to transition Firefox to use Wayland natively under Gamescope with wl_subcompositor, aiming to surpass the limitations of the current X11 implementation. We will share our progress on achieving touch and input parity, improving container integrations like async D-Bus handling, and integrating system-wide HDR video support.
    
    Speaker: Eri Pazos Pérez (Igalia)
    
    slides.pdf
  - 16:25
    
    Addressing Mesa CI pain points (2nd edition): what we've done, and where we are going 20m
    
    Mesa CI has one of the most complex CI pipelines. While this is great for test coverage, this also brings challenges in infrastructure, usability, and sustainability. In this second edition of the talk, we will present what we think works, what we've done over the past year, what still needs improvement, and what is currently on our roadmap.
    
    We've submitted a workshop proposal to discuss these issues further and agree on the roadmap for the next 12 months. Come watch the talk and join the workshop to let us know if we've missed any pain point and influence these plans!
    
    Speakers: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor) , Eric Engestrom (Mesa)
    
    slides.pdf
- 10:05 → 11:35
  Workshop, Meeting or Hacking session
  - 10:05
    
    Workshop: Vulkan "Gallium" 1h 30m
    
    Following up on Faith's talk, this is an opportunity to brainstorm and hear thoughts from other Vulkan driver maintainers.
    
    Speaker: Dr Faith Ekstrand (Collabora)
- 16:50 → 17:15
  Lightning Talks
  - 16:50
    
    Vulkan CTS uses too much system memory? No problem 5m
    
    Vulkan CTS memory requirements had been steadily increasing over many years until reaching a breaking point when it started creating issues for some Mesa CI runners. We studied the problem, understood the root cause and decreased peak memory needs from 900 MBs to 300 MBs in our test builds. This talk is a quick postmortem that also helps set expectations for CTS users.
    
    Speaker: Ricardo Garcia (Igalia, S.L.)
    
    cts-memory.odp
  - 16:55
    
    Finally getting rid of TGSI? 5m
    
    It's been well over a decade since NIR landed upstream in Mesa. Since then, a lot of people have worked hard to get rid of TGSI. While there's still a few road blocks left, we're getting close to the home-stretch.
    
    This talk will try to answer the question: How can we finally get rid of TGSI in Mesa?
    
    Speaker: Erik Faye-Lund (Arm)
    
    death-to-tgsi.odp
    
    death-to-tgsi.pdf
  - 17:00
    
    rusticl status update 5m
    
    Short status update about new OpenCL features supported, features work in progress, changes in driver status and what the priorities are going forward.
    
    Speaker: Karol Herbst (Red Hat, Nouveau)
    
    rusticl.html
  - 17:05
    
    Turning Driver Bugs into Vulkan CTS Tests 5m
    
    Fixing a Vulkan driver bug is important, but making sure it never returns is just as important. This lightning talk will briefly describe the process of turning a real driver bug into a Vulkan CTS test. I will share a few examples of challenges encountered while reproducing bugs in a small, reliable conformance test, and explain why a straightforward test often isn't enough to expose the original issue. The talk will conclude with a few practical lessons learned from contributing bug-fix regression tests to Vulkan CTS.
    
    Speaker: Madeeha Javed (Igalia)
    
    Igalia_Madeeha_Turning_driver_bugs_into_Vulkan_CTS_tests.pdf
  - 17:10
    
    CI-Tron for kernel development 5m
    
    When several new boards could not fit my traditional setup, I had to revert to use of the CI-Tron for automation of those boards. This lightining talk shows the use of CI-Tron for the kernel developent and maintainer duties, emphasising its usage out of the traditional CI area.
    
    Speaker: Dmitry Baryshkov (Qualcomm)
    
    CI-Tron for kernel development.pdf
- 17:20 → 17:25
  
  Monday Closing Session 5m
- 19:00 → 23:00
  
  Social Event: Welcome Reception, sponsored by Arm & Collabora Café ZUZU
  
  Café ZUZU
  
  555 Dundas Street East Toronto, ON https://maps.app.goo.gl/NE5DtuNqVP5vvSwR6
Tuesday, 29 September
- 08:00 → 09:00
  
  Breakfast and Registration 1h
- 09:00 → 16:50
  Main Track
  - 09:00
    
    Tuesday Opening Session 10m
  - 09:15
    
    Apple M3 GPU reverse engineering progress. 45m
    
    A small group of people has been at work reversing the GPU in the M3 SoC and in this talk we will talk about the progress we've made so far.
    We will talk about how the HW differs from previous generations and what is required to port the driver.
    Finally, we will discuss the status of the porting work for the userspace and kernel drivers.
    
    Speakers: Anna Maniscalco (Valve) , Alyssa Milburn, Evan Tang (Codeweavers)
    
    slides.html
  - 10:05
    
    Error Handling on Atomic Commit Failure 20m
    
    Problem Statement
    Today, when an atomic commit fails, userspace typically receives only a generic error such as -EINVAL, with no indication of the underlying cause. As a result, compositors cannot determine why the commit failed or apply appropriate corrective actions. A common example is a bandwidth-related failure, where the requested bpc exceeds the available link bandwidth. Since the failure reason is not propagated to userspace, the compositor must rely on kernel logs to diagnose the issue and infer that the bpc should be reduced before retrying the atomic commit.
    
    Solution
    The goal is to provide compositors with sufficient information to understand why an atomic commit failed and enable targeted fallback mechanisms. In the bandwidth example above, the kernel reports the reason for the failure, allowing the compositor to identify the bandwidth limitation, reduce the bpc accordingly, and retry the atomic commit with a more suitable configuration.
    
    The proposed DRM/KMS UAPI for atomic commit failure reporting repurposes the reserved u64 field in struct drm_mode_atomic, passed as part of the atomic_commit ioctl, to return detailed failure information to userspace. As part of the compositor implementation, this information is decoded to identify the specific reason for an atomic commit failure. Based on the reported failure, the compositor will implement targeted fallback logic and intelligently retry the atomic commit with a more suitable configuration wherever possible.
    
    Atomic Commit Failure Codes Reported by Kernel
    The current implementation defines the following common atomic commit failure codes, with the flexibility to extend the list as new failure scenarios are identified.
    • DRM_MODE_ATOMIC_UNSPECIFIED_ERROR – Generic error when no specific failure reason is available.
    • DRM_MODE_ATOMIC_INVALID_API_USAGE – The atomic commit failed due to invalid use of the DRM atomic API (e.g., missing atomic capability, invalid flags, or incompatible options).
    • DRM_MODE_ATOMIC_NEED_FULL_MODESET – The requested update requires a full modeset.
    • DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED – A property was modified during an asynchronous page flip.
    • DRM_MODE_ATOMIC_SCANOUT_BW – The requested display configuration exceeds the available scanout bandwidth (e.g., resolution, refresh rate, or color depth).
    • DRM_MODE_ATOMIC_CONNECTOR_BW – The requested configuration exceeds the available bandwidth of the display connector or link.
    • DRM_MODE_ATOMIC_PIPE_BW – The display pipeline cannot support the requested configuration due to pipe or scaler limitations.
    • DRM_MODE_ATOMIC_MEMORY_DOMAIN – The requested configuration exceeds memory or bandwidth constraints not covered by the other bandwidth-related errors.
    • DRM_MODE_ATOMIC_SPEC_VIOLATION – The requested configuration violates a hardware-specific capability or specification limitation.
    
    References
    2025 Display Next Hackfest https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
    Kernel https://patchwork.freedesktop.org/series/152275/
    Mutter https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5022
    IGT https://patchwork.freedesktop.org/series/153330/
    Libdrm https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
    KWIN https://invent.kde.org/plasma/kwin/-/merge_requests/8991
    
    Speaker: Ramya Krishna Yella (Intel)
    
    AtomicErrorHandling.pptx
  - 10:30
    
    Panthor status update 20m
    
    Annual report on the status of Panthor and what has been accomplished over the year. We also want to update the community on plans for the next year and the list of features we are going to work on.
    
    Speakers: Boris Brezillon (Collabora) , Liviu Dudau (Arm Ltd) , Karunika Choo (Arm Ltd)
    
    panthor-status-update.pdf
  - 10:50
    
    Break 30m
  - 11:20
    
    Kraid: A new compiler for Panfrost 45m
    
    The compiler the panfrost drivers currently use for Bifrost and later hardware is starting to show its age. It was originally developed as a Bifrost compiler and Valhall support was bolted on as an afterthought. This summer, a few of us at Arm and Collabora have been building a brand new compiler for Valhall and later hardware. In this presentation, we'll talk about the new compiler, the rational for rewriting instead of fixing the old one, and our plans for the Panfrost compiler stack going forwards.
    
    Speakers: Lorenzo Rossi, Dr Faith Ekstrand (Collabora) , Christoph Pillmayer (Arm Ltd)
    
    2026-09-28 - XDC 2026 - Kraid.pdf
  - 12:10
    
    Better render passes in PanVK for moar FPS 20m
    
    Earlier this year, we substantially reworked the render pass abstraction used by the PanVK driver. Previously, it was based on what Alyssa had written for the OpenGL driver which was designed around an immediate-mode API. With Vulkan, we have more information and can do better. In this talk, Faith will talk about the over-all design and philosphy of the new abstraction and how it's helped us get massive speed-ups in certain MSAA benchmarks.
    
    Speaker: Dr Faith Ekstrand (Collabora)
    
    2026-09-29 - XDC 2026 - Renderpass.pdf
  - 12:30
    
    Lunch 1h 30m
  - 14:00
    
    Foveated rendering on Turnip 45m
    
    Eye-tracked foveated rendering is a technique for accelerating rendering of virtual reality content by tracking where the user's eyes are looking and rendering the parts of the screen near the user's gaze at a higher resolution than everything else. As part of efforts for the Steam Frame, we reimplemented existing techniques for foveated rendering on Qualcomm Adreno GPUs in the Turnip open-source Vulkan driver and further pushed the envelope by designing and implementing new Vulkan extensions to bring foveated rendering to more content. This talk will go over how foveated rendering works in Turnip through VK_EXT_fragment_density_map and related extensions, various extensions and driver optimizations to further improve performance and visual quality, and future directions for improvement.
    
    Speaker: Connor Abbott (Valve)
    
    Foveated Rendering in Turnip.pdf
  - 14:50
    
    MSM graphics status report and roadmap 20m
    
    Since the last XDC, we have enabled adreno gen8 (a830, a840, x2-90, etc) in mesa (gl/cl/vk) and upstream kernel, in addition to continuing to backfill support for a6xx and a7xx devices.. with more to come. And we continue to shift-left in terms of enabling new hw prior toshipping, starting with x2-90.
    
    In addition, new features have been added (PERFCNTR_CONFIG, rusticl enabled by default, etc).. again with more to come. Not to mention, enabling new platforms in CI.
    
    On the display side, we've enabled quad-pipe support (enabling higher resolutions), virtual planes, gamma correction, and re-worked UBWC configuration to have a single source of truth across all drivers.
    
    This presentation will give a recap of progress since XDC2025, and an overview of what's to come.
    
    Speakers: Rob Clark (Qualcomm) , Dmitry Baryshkov (Qualcomm)
    
    XDC2026 Qualcomm Update.pdf
  - 15:15
    
    Demo: Turnip without Root 10m
    
    Turnip is one of Mesa's few drivers that has support for multiple kernel drivers, including the upstream MSM kernel driver and downstream KGSL kernel driver. This gives it the interesting ability to be able to run on devices that run Linux as well as unmodified android phones, which are typically pretty locked down.
    
    This talk will be a quick crash course for anyone interested in getting involved in Turnip's development, showing what tools are available to begin development with a completely unmodified stock android device.
    
    Speaker: Lucas Fryzek (Igalia S.L.)
    
    Turnip Without Root.pdf
  - 15:25
    
    Break 30m
  - 16:00
    
    Last Year of Turnip 20m
    
    The devs behind Turnip have been hard at work improving the driver. You may have heard that Turnip is being used for some pretty serious™️ gaming now. To support that we've been working on adding extensions, improving performance, and adding support for new devices.
    
    In this presentation we are going to give you an update on the current state of Turnip, and give a little more details on some of the cool new features in Turnip like the auto-tuner, support for new Adreno gen 8 devices, and what's required in Turnip to run real games.
    
    Speakers: Lucas Fryzek (Igalia S.L.) , Karmjit Mahil (Igalia S.L.)
    
    Year of Turnip.pdf
  - 16:25
    
    KosmicKrisp production ready! 20m
    
    KosmicKrisp status update on features, performance and developer tips and tricks.
    
    Speaker: Aitor Camacho Larrondo (LunarG)
    
    KosmicKrisp_Production_Ready.pdf
- 09:15 → 10:50
  Workshop, Meeting or Hacking session
  - 09:15
    
    Workshop: Mesa CI - What still needs to be done, and how to get there? 1h 35m
    
    The Mesa CI pipeline is complex and has many issues that are being addressed (see presentation "Addressing Mesa CI pain points (2nd edition): what we've done, and where we are going").
    
    This workshop will be dedicated to discussing outstanding pain points from the presentation, so that we (the CI developers) can make sure you (the CI users = Mesa developers) agree on what these pain points are, and what our plan to address them should be.
    
    The currently known pain points are:
    - Reliability of the Marge workflow (unavailable runners, flaky jobs, ...)
    - Long waiting times to get your MR tested and landed
    - Requirement to use an external script (GitLab web UI missing some buttons to run just the jobs we want)
    - Reproducing CI jobs locally
    - Updating job expectations (collating results from multiple runs, reducing the size of the flakes lists, failure rate of different tests, ...)
    - GPU hangs: how to prevent merging code that sometimes hang the GPU, and how to minimize impact of flaky hangs once the regression is merged
    - Game traces: increasing coverage, and access to the game traces & artifacts
    - And probably more, so come tell us what is your pain point!
    
    Speakers: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor) , Eric Engestrom (Mesa)
- 16:50 → 17:20
  Lightning Talks
  - 16:50
    
    etnaviv: good things take time 5m
    
    Some things are worth the wait. After a long, patient climb, the etnaviv project
    reached two milestones this year that once felt a long way off.
    
    This lightning talk looks at where the driver finally caught up on conformance, and
    at a new capability that opens the door to a whole class of workloads etnaviv could
    not run before.
    
    Years in the making, and worth every step
    
    Speaker: Christian Gmeiner (Igalia)
    
    xdc2026_etnaviv_good-things-take-time.pdf
  - 16:55
    
    v3d/v3dv: status update from last XDC 5m
    
    The V3D (OpenGL) and V3DV (Vulkan) drivers power the Broadcom GPU found in the Raspberry Pi 4 and 5.
    
    In this lightning talk we will go through a high-level tour of the latest updates to these drivers that we deliveredwhat things have been done on them: new extensions and features, performance improvements in different paths, refactors, CI, and so on.
    
    After this talk you will have a better understanding on what happened in the RPi GPU driver development in the last year.
    
    Speaker: Mr Juan A. Suarez (Igalia, S.L.)
    
    Slides (online)
    
    v3d_v3dv_ status update from last XDC.pdf
  - 17:00
    
    Supporting workgroups where there aren't any 5m
    
    Workgroups are a concept which allow multiple SIMD waves of shaders to run together and share some memory. API features such as compute and mesh shaders expect the driver to support workgroups. Modern hardware typically supports it, but... What if you want to run workgroups on hardware that doesn't really support it, for example you want to run mesh shaders on NVidia? Or maybe you want to support larger workgroups on older hardware that has an upper limit on the workgroup size?
    
    The new compiler pass nir_lower_workgroup_size was invented exactly for this purpose. Your driver can now support workgroups where there aren't any, or support larger workgroups when the HW can't.
    
    In this lightning talk I'll present what the challenge is with "emulating" workgroups; how we solved it, and how we've used it to implement NVK mesh shaders, to support larger compute workgroups on old GPUs on RADV, and even to find ray tracing issues.
    
    Speaker: Timur Kristóf (Valve)
    
    xdc2026_nlwgs.pdf
  - 17:05
    
    Resolving game bugs using retry faults 5m
    
    Modern games and game engines are getting more and more complicated, and show a lot of creativity in inventing new ways to implement memory management issues. Use after free, use before alloc, you name it. You may have seen GPU hangs thanks to page faults during gameplay.
    
    In this lightning talk, I'd like to present a proposal to deal with this type of problems on modern AMD GPUs on Linux, called retry faults. This hardware feature allows the kernel to resolve page faults and let the game continue. We can also use this to implement some features of the VK_KHR_device_fault extension.
    
    Speaker: Timur Kristóf (Valve)
    
    xdc2026_retry_faults.pdf
  - 17:10
    
    DRM Fabric: do we want a common topology API, or three more sysfs layouts? 5m
    
    Scale-up accelerator fabrics are already here: amdgpu has exposed xGMI topology through its own sysfs for years, AMD recently posted patches of UALink pod infrastructure, and Intel's XeLink/IAF support was posted and never became shared infrastructure. Every one of these describes the same thing: which accelerators are directly connected, through which ports, in what state. And everyone describes it differently.
    
    The drm/fabric RFC proposes one vendor-neutral model for that: fabric → endpoint → port → peer, over Generic Netlink, with the core recording direct adjacency only and leaving routing, transport and hardware programming to the drivers. It ships with a synthetic provider and no real hardware backend on purpose, so the model can be argued about before it's tied to anyone's silicon.
    
    I'll spend five minutes on the model and then ask the room the question the RFC actually needs answered: is this the right minimum common representation, and will vendors implement it, or do we accept per-driver topology forever?
    
    Speaker: Rodrigo Vivi
    
    XDC - drm-fabric 5min talk.pdf
- 17:20 → 17:25
  
  Tuesday Closing Session 5m
- 17:45 → 18:45
  
  Workshop, Meeting or Hacking session: X.Org BoD meeting
Wednesday, 30 September
- 08:00 → 09:00
  
  Breakfast and Registration 1h
- 09:00 → 16:30
  Main Track
  - 09:00
    
    Wednesday Opening Session 10m
  - 09:15
    
    PowerVR: A Year of Progress 45m
    
    Over the past year the PowerVR driver has made significant progress, from passing Vulkan 1.2 conformance to enabling OpenGL (ES) support via Zink, Wayland support, Mesa CI integration, improved developer tooling and adding support for additional platforms.
    
    This talk will cover the advances that have been made since last XDC, discuss the current state of the PowerVR driver and outline the roadmap for future development. In addition, it will also cover the ongoing work on the compiler backend (PCO), including some of the challenges and design decisions involved in working with the Rogue ISA.
    
    Speakers: Simon Perretta (Imagination Technologies) , Frank Binns (Imagination Technologies)
    
    XDC 2026 PowerVR A Year of Progress.pdf
  - 10:05
    
    From KFD to DRM SVM: Toward a Unified Memory Model in DRM 20m
    
    Shared Virtual Memory (SVM) enables a unified virtual address space for heterogeneous computing, but existing implementations remain outside the upstream DRM framework and face scalability challenges. In particular, KFD SVM relies on mmap read/write locks for synchronization, which tightly couples driver-level behavior with the system memory management and increases overall design complexity.
    At XDC 2025, an initial DRM SVM framework was introduced based on Intel Xe. In this talk, we build that foundation by evolving SVM into a unified DRM-based abstraction and demonstrating it on AMDGPU.
    We highlight several key architectural improvements. First, DRM SVM adopts a significantly simplified synchronization model, avoiding heavy mmap locking. Second, it is designed with native large page support, improving efficiency without invasive changes. Third, it introduces a cleaner abstraction by separating memory attributes from the physical layer, combined with a range-based model (up to 2MB granularity).
    We also demonstrate both fault-driven (XNACK-on)[1] and non-fault-driven (XNACK-off) [2][3] execution models and discuss ongoing work to extend DRM SVM beyond its current single-device scope toward multi-device support[4].
    This work advances DRM SVM toward a scalable, vendor-neutral, and upstream-aligned memory model.
    
    [1] https://lore.kernel.org/dri-devel/20260612090928.29682-1-ray.huang@amd.com/
    [2] https://lore.kernel.org/amd-gfx/20260519092313.3115848-1-honglei1.huang@amd.com/
    [3] https://lore.kernel.org/amd-gfx/20260605075340.20199-1-Junhua.Shen@amd.com/
    [4] https://lore.kernel.org/dri-devel/20260603065620.2555316-1-honglei1.huang@amd.com/
    
    Speaker: Ray Huang (AMD)
    
    drm_svm_amdgpu_xdc2026.pdf
  - 10:30
    
    Bringing Linux DRM Display Panel support in the modern age 20m
    
    Since the introduction of the first Samsung DSI panel, the Linux DRM panel
    API has been a crucial piece of software for enabling displays across
    diverse architectures, but it has not evolved alongside modern graphics stacks.
    Currently, the API lacks atomic DRM API support and the ability to adapt
    power setups during mode changes.
    Furthermore, it fails to support advanced Display Driver IC (DDIC) features
    that modern hardware heavily relies on, including:
    - Standby and advanced power states
    - Advanced color management
    - Dynamic rate switching
    - Command mode self-refresh
    
    This lack of evolution has led to severe fragmentation between upstream
    and vendor downstream trees for advanced devices support, creating a heavy
    maintenance burden and making native hardware support incredibly difficult.
    
    The goal would be to outline these architectural limitations and trigger a
    hallway discussion on how to collaboratively modernize the panel API.
    
    Speaker: Neil Armstrong (Linaro)
    
    XDC 2026 - Bringing Linux DRM Display Panel support in the modern age.pdf
  - 10:50
    
    Break 30m
  - 11:20
    
    NVK in 2026 45m
    
    What's new with everyone's favorite open source Vulkan driver for Nvidia GPUs? A bunch of stuff! Learn more about the latest in nvk technology -- compression, memory copies, mesh shaders, and more!
    
    Speaker: Mel Henning
    
    errata.txt
    
    nvk_in_2026.pdf
  - 12:10
    
    Upstreaming Tyr: a DRM GPU kernel driver in Rust 20m
    
    The Tyr project aims to port the existing DRM GPU kernel driver, Panthor, to Rust. Upstream Tyr is still very much a work-in-progress: it will probe as a platform device driver and can read and report on its GPU registers, but the rest of Tyr remains in a state of flux. Moving Tyr upstream has required us to test, adapt to, and contribute to the larger Rust ecosystem that is developing around it in the kernel.
    
    In this talk, I will walk through the initial stage of booting the microcontroller (MCU) in a Mali-G610 GPU to demonstrate how Tyr is using some of the newest Rust kernel abstractions for graphics. In particular, I will discuss how Tyr uses DRM GEM shared-memory buffer objects in conjunction with the GPU virtual memory manager to load the MCU firmware and start up the command-stream frontend for the GPU.
    
    Speaker: Deborah Brouwer (Collabora)
    
    tyr.pdf
  - 12:30
    
    Lunch 1h 30m
  - 14:05
    
    Reducing locking contention in drm gpu drivers to reduce stutters 20m
    
    When under memory pressure Linux might resort to swapping, this includes GPU resources for unified memory systems. Swap-in must happen before work is submitted to the HW and currently it has to happen while holding some locks. Since this is an expensive operation this can lead other processes to effectively wait needlessly if they contend on that lock. In this talk I will discuss how we solved this problem downstream on the msm driver for the Steam Frame and hopefully get a discussion started to solve it more widely upstream.
    
    Speaker: Anna Maniscalco (Valve)
    
    out.html
  - 14:30
    
    Learning kernel development through fixing old AMD GPUs on Linux 20m
    
    At XDC 2025 I promised that old AMD GPUs would work great on Linux, starting from GCN 1 up to GCN 4. In this talk, I'd like to present the progress on that work and what I learned from it.
    
    In the current economic situation of our world, people may have to use GPUs for longer, and replace them less often. And when an old GPU is replaced, it doesn’t disappear, it goes to somebody who upgrades an even older GPU. Eventually it will reach somebody that can’t afford a better one. My goal with this work is to make Linux gaming a good experience also for those who use old AMD GPUs, and learn Linux kernel development in the process.
    
    What did this work entail?
    
    I'll talk about implementing various display features, VCE support, DRM format modifiers, Vulkan, improved GPU hang recovery, sparse bindings, fixing memory management issues, power management bugs and making some GPUs boot that previously never worked on Linux.
    
    With that, GCN GPUs can now run a modern Linux graphics stack using the amdgpu kernel driver and the RADV Vulkan driver.
    
    Speaker: Timur Kristóf (Valve)
    
    xdc2026_kernel_dev_old_amd_gpus.pdf
  - 14:55
    
    Display Next Hackfest 2026: What we hacked on in Nice 20m
    
    A recap of this year's Display Next Hackfest, held in Nice right after Embedded Recipes. Topics ranged from finally getting backlight control working through KMS, to AMD FreeSync Premium Pro (aka Source-Based Tone Mapping) landing support on DP and HDMI, to DisplayID gradually taking over from EDID. We also dug into the perennial pain of frame timing on high-refresh-rate displays, merged a new Wayland protocol for multi-device dmabuf feedback, made progress on hot-pluggable DRM bridges, and squashed some gnarly slow-atomic-commit bugs on AMD that were blocking overlay planes by default. This talk walks through what got discussed, what got decided, and what's actually shipping.
    
    Speaker: Daniel Stone (Collabora)
    
    2026-09-30 - Display Next Hackfest Recap.pdf
  - 15:20
    Demo: Interactive HDCP Diagnostic Tool for Linux DRM/KMS stack. 10m
    
    HDCP (High Bandwidth Digital Content Protection) failures during real-world playback are difficult to reproduce and harder to triage. When protected content breaks on a user’s machine, there is rarely a quick way to tell whether the fault lies in the kernel driver or in user space or in the display link itself. Such failures are often intermittent, they surface only after a session has been active for some time, and they depend on the monitor, cable, and content-type combination and display configuration in use which makes them easy to miss with a conventional pass/fail test (eg: kms_content_protection IGT) that runs once and exits.
    
    HDCP Tool is an IGT (IGT GPU Tools) command line tool designed to identify the early issues that might occur on a Linux users’ machine. Its primary purpose is to confirm that content protection stays enabled for the full duration of an active playback session. By continuously polling the link it makes integrity failures easy to identify the moment they occur clearly showing whether the protected link stayed up and, if it dropped, exactly when. It also supports compliance validation while sessions are active, letting HDCP behavior be exercised and confirmed under realistic conditions.
    
    Current User Flow:
    The tool runs as an interactive, menu-driven application rather than a one-shot pass/fail test. Once started, it displays a menu on the connected screen and waits for operator input. Using single-key commands, the user can request a specific protection mode, query the status, or end the session. Each command takes effect immediately, so content protection can be enabled, changed, or disabled while the display session remains active.
    
    Get HDCP Information
    Retrieves and displays a detailed per-connector summary, including the encoder, connection status, connector type, sink device HDCP capabilities, current protection status, and active content type.
    
    Enable HDCP 1.4
    Initiates HDCP 1.4 protection by setting the Content Protection property to DESIRED and configuring the Content Type to 0.
    
    Enable HDCP 2.2 (Type 0)
    Requests HDCP 2.2 protection for Type 0 content by setting Content Protection = DESIRED and Content Type = 0.
    
    Enable HDCP 2.2 (Type 1)
    Requests HDCP 2.2 protection for Type 1 content by setting Content Protection = DESIRED and Content Type = 1.
    
    Disable HDCP
    Disables content protection by setting the Content Protection property to UNDESIRED, thereby removing HDCP enforcement.
    Q. Terminates the application session and releases all allocated display resources.
    
    The overlay is also helpful to color vision deficiency operators: because every mode and status is shown as on-screen text (mode name plus an Enabled/Desired/Disabled string), no critical information depends on distinguishing the background colors.
    
    Future Plans of Tool Enhancement:
    1. Improvements are planned for DP-MST setups to better handle multiple displays.
    2. Support for display hot-plug events (hpds) will allow testing when monitors are connected or disconnected during playback.
    3. Enhanced diagnostics, including detailed HDCP state-transition logging and failure reporting.
    
    Speakers: Mr Ankit Nautiyal (Intel) , Suraj Kandpal (Intel)
    
    HDCP Tool Demo.pptx
  - 15:30
    
    Break 30m
  - 16:05
    
    State of the X.Org Foundation 20m
    
    State of the X.Org Foundation
    
    Speaker: Lyude Paul (Red Hat)
    
    State of the X.org - XDC2026.pdf
- 09:15 → 10:50
  Workshop, Meeting or Hacking session
  - 09:15
    
    Workshop: Towards a governance model for Mesa 1h 35m
    
    Mesa has for the longest time functioned without a formal governance model. And while just relying on forming informal consensus functions well most of the time, there are times when we end up with compromises that nobody likes.
    
    So let's have a sit down and discuss options for putting in place a formal governance model.
    
    Speakers: Erik Faye-Lund (Arm) , Alyssa Rosenzweig (Mesa)
- 16:30 → 17:15
  Lightning Talks
  - 16:30
    
    Introducing the Wayland Content Frame Rate Protocol 5m
    
    Problem Statement
    Compositors are unaware of the media content frame rate and therefore present frames using the display's default refresh cadence. This mismatch leads to irregular frame timing, causing judder during low-frame-rate video playback (e.g., 24/30 fps) on both fixed-refresh and VRR displays. A familiar example is 3:2 pulldown, where 24 fps content is displayed on a 60 Hz panel with alternating 3- and 2-refresh frame durations, resulting in uneven motion. Figure 1 illustrates a similar issue, showing how 30 fps content is presented with irregular frame timing on a 40–60 Hz VRR display.
    
    Figure 1
    https://github.com/k2naveen/xdc-2026/blob/main/media-playback-frame-judder.png
    
    Solution
    To address this, we propose the wp-content-frame-rate-v1 [1] Wayland protocol, enabling media players to communicate the content frame rate to the compositor. The compositor [2] uses this information to apply Low Frame Rate Compensation (LFC) on VRR displays by selecting the lowest stable refresh-rate multiple of the content frame rate, or to switch to a matching supported display mode on fixed-refresh displays, delivering smooth, judder-free playback.
    
    [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/518
    [2] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5091
    
    Speaker: Mr Naveen Kumar (Intel Corporation)
    
    Introducing the Wayland Content Frame Rate Protocol
    
    Introducing_Wayland_Content_Frame_Rate_Protocol.pdf
  - 16:35
    
    Tunneling DP through USB4 5m
    
    Two 4K60 monitors on one Thunderbolt dock, each trained at HBR3 ×4: 64.8 Gbps over a 40 Gbps USB4 link, yet both light up. A DP main link never idles, and stuffing fills whatever the pixels don't use, so reserving by link rate books the stuffing too. This lightning talk shows how Bandwidth Allocation mode lets i915/xe reserve only what the mode needs from the USB4 Connection Manager, and how the DP IN and DP OUT adapters strip and rebuild the stuffing so only real data crosses the link.
    
    Speaker: Kunal Joshi (intel)
    
    Tunneling DP through USB4
  - 16:40
    
    Testing a browser on a real Wayland compositor (and why we all want this standardized) 5m
    
    Chromium runs thousands of interactive UI tests that need synthesized input. On Wayland
    there's no portable way to do that, and the reference compositor (weston) doesn't implement
    enough of the real protocol surface to be representative. So we forked mutter, taught it
    Chromium's ui-controls protocol, and wired it into our CI to run interactive tests on a
    real compositor for both pre- and post-submit. This lightning talk covers what that took,
    what broke, and why every app project shouldn't have to reinvent this, closing with a pitch
    to standardize cross-compositor application testing (cf. wayland-protocols #230).
    
    Speaker: Orko Garai (Igalia)
    
    xdc-2026-testing-browser-on-real-compositor.odp
    
    xdc-2026-testing-browser-on-real-compositor.pdf
  - 16:45
    
    Wayland vs X.org latency comparison 5m
    
    Wayland input latency is a topic discussed in the Linux graphics community and claims that “Wayland adds latency” have been repeated in the past. This talk explores end-to-end latency comparison in an automated A/B testing setup designed to produce more rigorous and reproducible measurements. The session focuses on comparative evaluation across multiple compositors or window managers, high-level display configurations, and measurement methods, with the goal of giving compositor and driver developers a fairer basis for discussing latency.
    
    Speaker: Kamil Łysik (NVIDIA)
    
    XDC Latency.pdf
  - 16:50
    
    Workshop recap: Vulkan "Gallium" 5m
    
    Speaker: Faith Ekstrand (Collabora)
    
    2026-09-30 - XDC 2026 - Shiva workshop.pdf
  - 16:55
    
    Workshop recap: Mesa CI 5m
    
    Speaker: Eric Engestrom (Mesa)
    
    slides.pdf
  - 17:00
    
    Workshop recap: Towards a governance model for Mesa 5m
    
    Speaker: Erik Faye-Lund (Arm)
    
    mesa-governance.odp
    
    mesa-governance.pdf
  - 17:05
    
    Pre-Silicon Testing at the Speed of Light 5m
    
    Waiting for hardware to be available before you start working on your driver isn’t great. Running pre-silicon gets you there earlier, but slower. But what if you could do pre-silicon testing at the speed of light?
    
    Speaker: Daniel Stone (Collabora)
    
    2026-09-30 - Pre-Silicon Testing at the Speed of Light.pdf
- 17:15 → 17:25
  
  XDC 2026 Closing Session 10m

XDC 2026 - X.Org Developer's Conference

Café ZUZU