BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CERN//INDICO//EN
BEGIN:VEVENT
SUMMARY:Kraid: A new compiler for Panfrost
DTSTART;VALUE=DATE-TIME:20260929T152000Z
DTEND;VALUE=DATE-TIME:20260929T160500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-526@indico.freedesktop.org
DESCRIPTION:Speakers: Lorenzo Rossi ()\, Faith Ekstrand (Collabora)\nThe c
 ompiler the panfrost drivers currently use for Bifrost and later hardware 
 is starting to show its age. It was originally developed as a Bifrost comp
 iler 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 f
 or Valhall and later hardware.  In this presentation\, we'll talk about th
 e new compiler\, the rational for rewriting instead of fixing the old one\
 , and our plans for the Panfrost compiler stack going forwards.\n\nhttps:/
 /indico.freedesktop.org/event/12/contributions/526/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/526/
END:VEVENT
BEGIN:VEVENT
SUMMARY:nocl: OpenCL on CUDA
DTSTART;VALUE=DATE-TIME:20260928T161000Z
DTEND;VALUE=DATE-TIME:20260928T163000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-542@indico.freedesktop.org
DESCRIPTION:Speakers: Karol Herbst (Red Hat\, Nouveau)\nNocl is a gallium 
 driver for use in rusticl to have an Open-Source OpenCL implementation on 
 top of CUDA.\n\nPeople 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.\n\nI'll go into the overall structure of the p
 roject\, features there are more interesting to implement\, what's still m
 issing before I'm happy enough about it.\n\nhttps://indico.freedesktop.org
 /event/12/contributions/542/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/542/
END:VEVENT
BEGIN:VEVENT
SUMMARY:SSA-based Register Allocation for Intel GPUs
DTSTART;VALUE=DATE-TIME:20260928T180000Z
DTEND;VALUE=DATE-TIME:20260928T184500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-527@indico.freedesktop.org
DESCRIPTION:Speakers: Alyssa Rosenzweig (Intel)\nIntel’s GPUs feature an
  unusual explicit SIMD instruction set presenting challenges for just-in-t
 ime shader compilers. Naïvely modelling Intel’s SIMD architecture artif
 icially increases register pressure and requires expensive register alloca
 tion algorithms based on graph colouring. To improve code quality while de
 creasing compile time\, our compiler “Jay” eschews the hardware’s na
 tive SIMD in favour of contemporary GPUs’ simpler SIMT model. Our nonlin
 ear remapping of logical SIMT registers onto the physical SIMD register fi
 le facilitates near-linear time register allocation with an SSA-based tree
  scan allocator and a decoupled spiller. Compared to Intel’s existing no
 n-SSA Linux shader compiler\, our compiler reduces spilling on a collectio
 n of game shaders by 98%. Jay demonstrates the feasibility and profitabili
 ty of SSA register allocation even for irregular GPU architectures and pro
 vides the foundation for Intel’s future Linux shader compilers\n\nhttps:
 //indico.freedesktop.org/event/12/contributions/527/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/527/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Next Generation Display Walls on Linux
DTSTART;VALUE=DATE-TIME:20260928T143000Z
DTEND;VALUE=DATE-TIME:20260928T145000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-565@indico.freedesktop.org
DESCRIPTION:Speakers: Austin Shafer (NVIDIA)\nDisplay walls\, arrays of di
 splays assembled to look like one large screen\, have historically been dr
 iven by an X server and are typically supported via display technology pro
 vided by a vendor's X driver. As the ecosystem migrates to Wayland this ar
 chitecture is no longer available and a new design must take shape. For th
 is reason\, NVIDIA now recommends an explicit Vulkan VK_KHR_display design
  where applications directly drive displays for more fine-grained control.
 \n\nThis talk will cover how display walls are used\, why the X-based desi
 gn was originally chosen\, and why Vulkan Direct 2 Display can provide a b
 etter 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.\n\nht
 tps://indico.freedesktop.org/event/12/contributions/565/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/565/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Optimizing the Panfrost Gallium driver
DTSTART;VALUE=DATE-TIME:20260928T185000Z
DTEND;VALUE=DATE-TIME:20260928T191000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-566@indico.freedesktop.org
DESCRIPTION:Speakers: Loïc Molinari (Collabora Ltd)\nThe performance of t
 he 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 integrat
 ion into Panfrost and then present the resulting optimizations (blits\, dr
 aw calls\, Transparent Huge Pages\, Transaction Elimination\, etc).\n\nhtt
 ps://indico.freedesktop.org/event/12/contributions/566/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/566/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Demo: Gamma\, a ray tracing debugger for Mesa drivers
DTSTART;VALUE=DATE-TIME:20260928T191500Z
DTEND;VALUE=DATE-TIME:20260928T192500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-563@indico.freedesktop.org
DESCRIPTION:Speakers: Konstantin Seurer ()\nAlmost 6 years after the relea
 se `VK_KHR_acceleration_structure`\, ray tracing is still an area in graph
 ics with really bad tooling. Gamma tries to solve this by providing a fram
 ework for writing driver specific visualizers. Konstantin will showcase th
 e capabilities using RADV as an example\, and how support for other driver
 s can be added.\n\nhttps://indico.freedesktop.org/event/12/contributions/5
 63/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/563/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Demo: Interactive HDCP Diagnostic Tool for Linux DRM/KMS stack.
DTSTART;VALUE=DATE-TIME:20260930T192000Z
DTEND;VALUE=DATE-TIME:20260930T193000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-564@indico.freedesktop.org
DESCRIPTION:Speakers: santhosh reddy SANTHOSH GUDDATI ()\nHDCP (High Bandw
 idth Digital Content Protection) failures during real-world playback are d
 ifficult 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 fa
 ult lies in the kernel driver or in user space or in the display link itse
 lf. Such failures are often intermittent\, they surface only after a sessi
 on has been active for some time\, and they depend on the monitor\, cable\
 , and content-type combination and display configuration in use which make
 s them easy to miss with a conventional pass/fail test  (eg: kms_content_p
 rotection IGT) that runs once and exits.\n\nHDCP Tool is an IGT (IGT GPU T
 ools) command line tool designed to identify the early issues that might o
 ccur on a Linux users’ machine. Its primary purpose is to confirm that c
 ontent protection stays enabled for the full duration of an active playbac
 k session. By continuously polling the link it makes integrity failures ea
 sy to identify the moment they occur clearly showing whether the protected
  link stayed up and\, if it dropped\, exactly when. It also supports compl
 iance validation while sessions are active\, letting HDCP behavior be exer
 cised and confirmed under realistic conditions.\n\nCurrent User Flow:\nThe
  tool runs as an interactive\, menu-driven application rather than a one-s
 hot pass/fail test. Once started\, it displays a menu on the connected scr
 een and waits for operator input. Using single-key commands\, the user can
  request a specific protection mode\, query the status\, or end the sessio
 n. Each command takes effect immediately\, so content protection can be en
 abled\, changed\, or disabled while the display session remains active.\n\
 n1.	Get HDCP Information\nRetrieves and displays a detailed per-connector 
 summary\, including the encoder\, connection status\, connector type\, sin
 k device HDCP capabilities\, current protection status\, and active conten
 t type.\n2.	Enable HDCP 1.4\nInitiates HDCP 1.4 protection by setting the 
 Content Protection property to DESIRED and configuring the Content Type to
  0.\n3.	Enable HDCP 2.2 (Type 0)\nRequests HDCP 2.2 protection for Type 0 
 content by setting Content Protection = DESIRED and Content Type = 0.\n4.	
 Enable HDCP 2.2 (Type 1)\nRequests HDCP 2.2 protection for Type 1 content 
 by setting Content Protection = DESIRED and Content Type = 1.\n5.	Disable 
 HDCP\nDisables content protection by setting the Content Protection proper
 ty to UNDESIRED\, thereby removing HDCP enforcement.\n         Q.   Termin
 ates the application session and releases all allocated display resources.
 \n\nThe overlay is also helpful to color vision deficiency operators: beca
 use every mode and status is shown as on-screen text (mode name plus an En
 abled/Desired/Disabled string)\, no critical information depends on distin
 guishing the background colors.\n\nFuture Plans of Tool Enhancement:\n1. I
 mprovements are planned for DP-MST setups to better handle multiple displa
 ys.\n2. Support for display hot-plug events (hpds) will allow testing when
  monitors are connected or disconnected during playback.\n3. Enhanced diag
 nostics\, including detailed HDCP state-transition logging and failure rep
 orting.\n\nhttps://indico.freedesktop.org/event/12/contributions/564/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/564/
END:VEVENT
BEGIN:VEVENT
SUMMARY:LLM inference on the Raspberry Pi 5 via Vulkan
DTSTART;VALUE=DATE-TIME:20260928T152000Z
DTEND;VALUE=DATE-TIME:20260928T160500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-529@indico.freedesktop.org
DESCRIPTION:Speakers: José María Casanova Crespo (Igalia)\nThe Raspberry
  Pi 5's Broadcom V3D 7.1 GPU was designed for graphics\nworkloads\, but th
 e wave of on-device LLM frameworks now directs pure\ncompute workloads at 
 the V3DV Vulkan driver. This talk reports what\nwe learned extending V3DV 
 for these workloads since early 2026.\n\nML inference stresses the driver 
 in ways graphics never does: thousands\nof tiny buffer fills and copies pe
 r token\, heavy buffer-object allocation\nagainst V3D's 4 GB memory ceilin
 g\, shaders with high register pressure\,\nand a dependence on fast fp16 s
 upport.\n\nWe walk through the driver changes this new workload required 
 — enough that\nit is now possible to run open-weight models with inferen
 ce frameworks\nsuch as Ollama/llama.cpp and LiteRT-LM.\n\nFinally\, the ta
 lk discusses future work and the challenges that remain\nto run inference 
 on V3DV.\n\nhttps://indico.freedesktop.org/event/12/contributions/529/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/529/
END:VEVENT
BEGIN:VEVENT
SUMMARY:PowerVR: A Year of Progress
DTSTART;VALUE=DATE-TIME:20260930T131500Z
DTEND;VALUE=DATE-TIME:20260930T140000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-528@indico.freedesktop.org
DESCRIPTION:Speakers: Simon Perretta (Imagination Technologies)\, Frank Bi
 nns (Imagination Technologies)\nOver the past year the PowerVR driver has 
 made significant progress\, from passing Vulkan 1.2 conformance to enablin
 g OpenGL (ES) support via Zink\, Wayland support\, Mesa CI integration\, i
 mproved developer tooling and adding support for additional platforms.\n\n
 This talk will cover the advances that have been made since last XDC\, dis
 cuss the current state of the PowerVR driver and outline the roadmap for f
 uture development. In addition\, it will also cover the ongoing work on th
 e compiler backend (PCO)\, including some of the challenges and design dec
 isions involved in working with the Rogue ISA.\n\nhttps://indico.freedeskt
 op.org/event/12/contributions/528/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/528/
END:VEVENT
BEGIN:VEVENT
SUMMARY:NVK in 2026
DTSTART;VALUE=DATE-TIME:20260930T152000Z
DTEND;VALUE=DATE-TIME:20260930T160500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-531@indico.freedesktop.org
DESCRIPTION:Speakers: Mel Henning ()\nWhat's new with everyone's favorite 
 open source Vulkan driver for Nvidia GPUs? A bunch of stuff! Learn more ab
 out the latest in nvk technology -- compression\, memory copies\, mesh sha
 ders\, and more!\n\nhttps://indico.freedesktop.org/event/12/contributions/
 531/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/531/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Apple M3 GPU reverse engineering progress.
DTSTART;VALUE=DATE-TIME:20260929T131500Z
DTEND;VALUE=DATE-TIME:20260929T140000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-532@indico.freedesktop.org
DESCRIPTION:Speakers: Anna Maniscalco (Valve)\, Alyssa Milburn ()\, Evan T
 ang (Codeweavers)\nA 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 m
 ade so far.\nWe will talk about how the HW differs from previous generatio
 ns and what is required to port the driver.\nFinally\, we will discuss the
  status of the porting work for the userspace and kernel drivers.\n\nhttps
 ://indico.freedesktop.org/event/12/contributions/532/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/532/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Last Year of Turnip
DTSTART;VALUE=DATE-TIME:20260929T200000Z
DTEND;VALUE=DATE-TIME:20260929T202000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-543@indico.freedesktop.org
DESCRIPTION:Speakers: Lucas Fryzek (Igalia S.L.)\, Karmjit Mahil (Igalia S
 .L.)\nThe 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\, imp
 roving performance\, and adding support for new devices.\n\nIn this presen
 tation 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 r
 equired in Turnip to run real games.\n\nhttps://indico.freedesktop.org/eve
 nt/12/contributions/543/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/543/
END:VEVENT
BEGIN:VEVENT
SUMMARY:State of the X.Org Foundation
DTSTART;VALUE=DATE-TIME:20260930T200500Z
DTEND;VALUE=DATE-TIME:20260930T202500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-547@indico.freedesktop.org
DESCRIPTION:Speakers: Lyude Paul (Red Hat)\nState of the X.Org Foundation\
 n\nhttps://indico.freedesktop.org/event/12/contributions/547/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/547/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Error Handling on Atomic Commit Failure
DTSTART;VALUE=DATE-TIME:20260929T140500Z
DTEND;VALUE=DATE-TIME:20260929T142500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-541@indico.freedesktop.org
DESCRIPTION:Speakers: Ramya Krishna Yella (Intel)\n**Problem Statement**\n
 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 appl
 y appropriate corrective actions. A common example is a bandwidth-related 
 failure\, where the requested bpc exceeds the available link bandwidth. Si
 nce the failure reason is not propagated to userspace\, the compositor mus
 t rely on kernel logs to diagnose the issue and infer that the bpc should 
 be reduced before retrying the atomic commit.\n\n**Solution**\nThe goal is
  to provide compositors with sufficient information to understand why an a
 tomic commit failed and enable targeted fallback mechanisms. In the bandwi
 dth example above\, the kernel reports the reason for the failure\, allowi
 ng the compositor to identify the bandwidth limitation\, reduce the bpc ac
 cordingly\, and retry the atomic commit with a more suitable configuration
 .\n\nThe proposed DRM/KMS UAPI for atomic commit failure reporting repurpo
 ses the **reserved** u64 field in **struct drm_mode_atomic**\, passed as p
 art of the **atomic_commit ioctl**\, to return detailed failure informatio
 n to userspace. As part of the compositor implementation\, this informatio
 n is decoded to identify the specific reason for an atomic commit failure.
  Based on the reported failure\, the compositor will implement targeted fa
 llback logic and intelligently retry the atomic commit with a more suitabl
 e configuration wherever possible.\n\n**Atomic Commit Failure Codes Report
 ed by Kernel**\nThe current implementation defines the following common at
 omic commit failure codes\, with the flexibility to extend the list as new
  failure scenarios are identified.\n•	**DRM_MODE_ATOMIC_UNSPECIFIED_ERRO
 R** – Generic error when no specific failure reason is available. \n•	
 **DRM_MODE_ATOMIC_INVALID_API_USAGE** – The atomic commit failed due to 
 invalid use of the DRM atomic API (e.g.\, missing atomic capability\, inva
 lid flags\, or incompatible options). \n•	**DRM_MODE_ATOMIC_NEED_FULL_MO
 DESET** – The requested update requires a full modeset. \n•	**DRM_MODE
 _ATOMIC_ASYNC_PROP_CHANGED** – A property was modified during an asynchr
 onous page flip. \n•	**DRM_MODE_ATOMIC_SCANOUT_BW** – The requested di
 splay configuration exceeds the available scanout bandwidth (e.g.\, resolu
 tion\, refresh rate\, or color depth). \n•	**DRM_MODE_ATOMIC_CONNECTOR_B
 W** – The requested configuration exceeds the available bandwidth of the
  display connector or link. \n•	**DRM_MODE_ATOMIC_PIPE_BW** – The disp
 lay pipeline cannot support the requested configuration due to pipe or sca
 ler limitations. \n•	**DRM_MODE_ATOMIC_MEMORY_DOMAIN** – The requested
  configuration exceeds memory or bandwidth constraints not covered by the 
 other bandwidth-related errors. \n•	**DRM_MODE_ATOMIC_SPEC_VIOLATION** 
 – The requested configuration violates a hardware-specific capability or
  specification limitation.\n\n**References**\n2025 Display Next Hackfest	[
 https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback][1]\nKern
 el	[https://patchwork.freedesktop.org/series/152275/][2]\nMutter	[https://
 gitlab.gnome.org/GNOME/mutter/-/merge_requests/5022][3]\nIGT	[https://patc
 hwork.freedesktop.org/series/153330/][4]\nLibdrm	[https://gitlab.freedeskt
 op.org/mesa/libdrm/-/merge_requests/450][5]\nKWIN	[https://invent.kde.org/
 plasma/kwin/-/merge_requests/8991][6]\n\n\n  [1]: https://hackmd.io/f3bDn3
 kyRUalLn4LbMfCVQ#Commit-Failure-Feedback\n  [2]: https://patchwork.freedes
 ktop.org/series/152275/\n  [3]: https://gitlab.gnome.org/GNOME/mutter/-/me
 rge_requests/5022\n  [4]: https://patchwork.freedesktop.org/series/153330/
 \n  [5]: https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450\n
   [6]: https://invent.kde.org/plasma/kwin/-/merge_requests/8991\n\nhttps:/
 /indico.freedesktop.org/event/12/contributions/541/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/541/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Addressing Mesa CI pain points (2nd edition): what we've done\, an
 d where we are going
DTSTART;VALUE=DATE-TIME:20260930T183000Z
DTEND;VALUE=DATE-TIME:20260930T185000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-536@indico.freedesktop.org
DESCRIPTION:Speakers: Martin Roukala (né Peres) (MuPuF TMI / Valve contra
 ctor)\, Eric Engestrom (Mesa)\nMesa CI has one of the most complex CI pipe
 lines. While this is great for test coverage\, this also brings challenges
  in infrastructure\, usability\, and sustainability. In this second editio
 n 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 o
 ur roadmap.\n\nWe've submitted a workshop proposal to discuss these issues
  further and agree on the roadmap for the next 12 months. Come watch the t
 alk and join the workshop to let us know if we've missed any pain point an
 d influence these plans!\n\nhttps://indico.freedesktop.org/event/12/contri
 butions/536/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/536/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Panthor status update
DTSTART;VALUE=DATE-TIME:20260929T143000Z
DTEND;VALUE=DATE-TIME:20260929T145000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-539@indico.freedesktop.org
DESCRIPTION:Speakers: Boris Brezillon (Collabora)\, Liviu Dudau (Arm Ltd)\
 , Karunika Choo (Arm Ltd)\nAnnual 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.\n\nhttps://indico.freedesktop.org/event/12/contributions/539/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/539/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Firefox + Steam Deck: Seamless experience across two compositors
DTSTART;VALUE=DATE-TIME:20260928T200000Z
DTEND;VALUE=DATE-TIME:20260928T202000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-544@indico.freedesktop.org
DESCRIPTION:Speakers: Eri Pazos Pérez (Igalia)\nSupporting a major web br
 owser on the Steam Deck brings an exciting challenge because of the unique
  dual-compositor architecture: Gamescope for game mode and KWin for deskto
 p mode.\n\nThis talk covers our ongoing efforts to transition Firefox to u
 se Wayland natively under Gamescope with wl_subcompositor\, aiming to surp
 ass the limitations of the current X11 implementation. We will share our p
 rogress on achieving touch and input parity\, improving container integrat
 ions like async D-Bus handling\, and integrating system-wide HDR video sup
 port.\n\nhttps://indico.freedesktop.org/event/12/contributions/544/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/544/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Better render passes in PanVK for moar FPS
DTSTART;VALUE=DATE-TIME:20260929T161000Z
DTEND;VALUE=DATE-TIME:20260929T163000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-524@indico.freedesktop.org
DESCRIPTION:Speakers: Faith Ekstrand (Collabora)\nEarlier this year\, we s
 ubstantially reworked the render pass abstraction used by the PanVK driver
 . Previously\, it was based on what Alyssa had written for the OpenGL driv
 er 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 help
 ed us get massive speed-ups in certain MSAA benchmarks.\n\nhttps://indico.
 freedesktop.org/event/12/contributions/524/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/524/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Display Next Hackfest 2026: What we hacked on in Nice
DTSTART;VALUE=DATE-TIME:20260930T185500Z
DTEND;VALUE=DATE-TIME:20260930T191500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-546@indico.freedesktop.org
DESCRIPTION:Speakers: Daniel Stone (Collabora)\nA recap of this year's Dis
 play Next Hackfest\, held in Nice right after Embedded Recipes. Topics ran
 ged from finally getting backlight control working through KMS\, to AMD Fr
 eeSync Premium Pro (aka Source-Based Tone Mapping) landing support on DP a
 nd HDMI\, to DisplayID gradually taking over from EDID. We also dug into t
 he 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 bu
 gs on AMD that were blocking overlay planes by default. This talk walks th
 rough what got discussed\, what got decided\, and what's actually shipping
 .\n\nhttps://indico.freedesktop.org/event/12/contributions/546/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/546/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Handling XR Displays in the Linux Graphics Stack
DTSTART;VALUE=DATE-TIME:20260928T140500Z
DTEND;VALUE=DATE-TIME:20260928T142500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-534@indico.freedesktop.org
DESCRIPTION:Speakers: Neil Armstrong (Linaro)\, Nie Jun (Linaro)\nIn the L
 inux 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.\n\nPhysically\, an XR
  device consists of two distinct displays (one for each eye). Simply pushi
 ng standard 2D desktop frames to this aggregated screen results in an unvi
 ewable\, disorienting output. To produce an image that a human eye can act
 ually process through the headset's optics\, the output requires heavy GL/
 Vulkan-based transformations. These transformations must account for stere
 oscopic rendering\, lens distortion correction (barrel distortion\, chroma
 tic aberration)\, and the physical focal planes of the hardware.\n\nThis s
 hort talk will outline the disconnect between how DRM sees an XR display a
 nd what the human eye physically needs. The primary goal is to trigger an 
 open discussion on the architectural path forward:\n\n- Should we add spec
 ial properties to such display so traditional DRM clients (fb emulation\, 
 compositor\, ...) avoids considering them as an output ?\n- How should we 
 properly expose the physical lens and plane characteristics of XR hardware
  through DRM?\n- Should the compositor bear the full weight of these rende
 ring transformations\, or is there a better abstraction?\n- How do we stan
 dardize the handling of XR displays across the Linux graphics stack to mak
 e native XR a reality?\n\nhttps://indico.freedesktop.org/event/12/contribu
 tions/534/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/534/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Bringing Linux DRM Display Panel support in the modern age
DTSTART;VALUE=DATE-TIME:20260928T202500Z
DTEND;VALUE=DATE-TIME:20260928T204500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-535@indico.freedesktop.org
DESCRIPTION:Speakers: Neil Armstrong (Linaro)\nSince the introduction of t
 he first Samsung DSI panel\, the Linux DRM panel\nAPI has been a crucial p
 iece of software for enabling displays across\ndiverse architectures\, but
  it has not evolved alongside modern graphics stacks.\nCurrently\, the API
  lacks atomic DRM API support and the ability to adapt\npower setups durin
 g mode changes.\nFurthermore\, it fails to support advanced Display Driver
  IC (DDIC) features\nthat modern hardware heavily relies on\, including:\n
 - Standby and advanced power states\n- Advanced color management\n- Dynami
 c rate switching\n- Command mode self-refresh\n\nThis lack of evolution ha
 s led to severe fragmentation between upstream\nand vendor downstream tree
 s for advanced devices support\, creating a heavy\nmaintenance burden and 
 making native hardware support incredibly difficult.\n\nThe goal would be 
 to outline these architectural limitations and trigger a\nhallway discussi
 on on how to collaboratively modernize the panel API.\n\nhttps://indico.fr
 eedesktop.org/event/12/contributions/535/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/535/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Foveated rendering on Turnip
DTSTART;VALUE=DATE-TIME:20260929T180000Z
DTEND;VALUE=DATE-TIME:20260929T184500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-530@indico.freedesktop.org
DESCRIPTION:Speakers: Connor Abbott (Valve)\nEye-tracked foveated renderin
 g 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. A
 s part of efforts for the Steam Frame\, we reimplemented existing techniqu
 es for foveated rendering on Qualcomm Adreno GPUs in the Turnip open-sourc
 e Vulkan driver and further pushed the envelope by designing and implement
 ing new Vulkan extensions to bring foveated rendering to more content. Thi
 s talk will go over how foveated rendering works in Turnip through VK_EXT_
 fragment_density_map and related extensions\, various extensions and drive
 r optimizations to further improve performance and visual quality\, and fu
 ture directions for improvement.\n\nhttps://indico.freedesktop.org/event/1
 2/contributions/530/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/530/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Is it time for Vulkan Gallium?
DTSTART;VALUE=DATE-TIME:20260928T131500Z
DTEND;VALUE=DATE-TIME:20260928T140000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-523@indico.freedesktop.org
DESCRIPTION:Speakers: Faith Ekstrand (Collabora)\nWhen Vulkan 1.0 first ca
 me 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 o
 f extensions\, it's not so simple.  There is legacy cruft we all have to c
 arry.  There are 3 versions of some enums which have to be remapped by som
 eone.  There are duplicate entrypoints and queries everywhere.\n\nIn the O
 penGL world\, we have an answer for this: Gallium.  Is it time for a Galli
 um for Vulkan?  In this presentation\, Faith will talk about why she think
 s it's time\, what that layer would look like\, and what it would mean for
  the Vulkan drivers that exist in the tree today.\n\nhttps://indico.freede
 sktop.org/event/12/contributions/523/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/523/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Monday Opening Session
DTSTART;VALUE=DATE-TIME:20260928T130000Z
DTEND;VALUE=DATE-TIME:20260928T131000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-571@indico.freedesktop.org
DESCRIPTION:https://indico.freedesktop.org/event/12/contributions/571/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/571/
END:VEVENT
BEGIN:VEVENT
SUMMARY:MSM graphics status report and roadmap
DTSTART;VALUE=DATE-TIME:20260929T185000Z
DTEND;VALUE=DATE-TIME:20260929T191000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-570@indico.freedesktop.org
DESCRIPTION:Speakers: Rob Clark (Qualcomm)\, Dmitry Baryshkov (Qualcomm)\n
 Since the last XDC\, we have enabled adreno gen8 (a830\, a840\, x2-90\, et
 c) in mesa (gl/cl/vk) and upstream kernel\, in addition to continuing to b
 ackfill support for a6xx and a7xx devices.. with more to come. And we cont
 inue to shift-left in terms of enabling new hw prior toshipping\, starting
  with x2-90.\n\nIn addition\, new features have been added (PERFCNTR_CONFI
 G\, rusticl enabled by default\, etc).. again with more to come. Not to me
 ntion\, enabling new platforms in CI.\n\nOn the display side\, we've enabl
 ed quad-pipe support (enabling higher resolutions)\, virtual planes\, gamm
 a correction\, and re-worked UBWC configuration to have a single source of
  truth across all drivers.\n\nThis presentation will give a recap of progr
 ess since XDC2025\, and an overview of what's to come.\n\nhttps://indico.f
 reedesktop.org/event/12/contributions/570/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/570/
END:VEVENT
BEGIN:VEVENT
SUMMARY:KosmicKrisp production ready!
DTSTART;VALUE=DATE-TIME:20260929T202500Z
DTEND;VALUE=DATE-TIME:20260929T204500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-538@indico.freedesktop.org
DESCRIPTION:Speakers: Aitor Camacho Larrondo (LunarG)\nKosmicKrisp status 
 update on features\, performance and developer tips and tricks.\n\nhttps:/
 /indico.freedesktop.org/event/12/contributions/538/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/538/
END:VEVENT
BEGIN:VEVENT
SUMMARY:From KFD to DRM SVM: Toward a Unified Memory Model in DRM
DTSTART;VALUE=DATE-TIME:20260930T140500Z
DTEND;VALUE=DATE-TIME:20260930T142500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-537@indico.freedesktop.org
DESCRIPTION:Speakers: Ray Huang (AMD)\nShared Virtual Memory (SVM) enables
  a unified virtual address space for heterogeneous computing\, but existin
 g implementations remain outside the upstream DRM framework and face scala
 bility challenges. In particular\, KFD SVM relies on mmap read/write locks
  for synchronization\, which tightly couples driver-level behavior with th
 e system memory management and increases overall design complexity.\nAt XD
 C 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-b
 ased abstraction and demonstrating it on AMDGPU.\nWe highlight several key
  architectural improvements. First\, DRM SVM adopts a significantly simpli
 fied synchronization model\, avoiding heavy mmap locking. Second\, it is d
 esigned with native large page support\, improving efficiency without inva
 sive changes. Third\, it introduces a cleaner abstraction by separating me
 mory attributes from the physical layer\, combined with a range-based mode
 l (up to 2MB granularity).\nWe also demonstrate both fault-driven (XNACK-o
 n)[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 tow
 ard multi-device support[4].\nThis work advances DRM SVM toward a scalable
 \, vendor-neutral\, and upstream-aligned memory model.\n\n[1] https://lore
 .kernel.org/dri-devel/20260612090928.29682-1-ray.huang@amd.com/\n[2] https
 ://lore.kernel.org/amd-gfx/20260519092313.3115848-1-honglei1.huang@amd.com
 /\n[3] https://lore.kernel.org/amd-gfx/20260605075340.20199-1-Junhua.Shen@
 amd.com/\n[4] https://lore.kernel.org/dri-devel/20260603065620.2555316-1-h
 onglei1.huang@amd.com/\n\nhttps://indico.freedesktop.org/event/12/contribu
 tions/537/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/537/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Learning kernel development through fixing old AMD GPUs on Linux
DTSTART;VALUE=DATE-TIME:20260930T143000Z
DTEND;VALUE=DATE-TIME:20260930T145000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-545@indico.freedesktop.org
DESCRIPTION:Speakers: Timur Kristóf (Valve)\nAt 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 le
 arned from it.\n\nIn 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 up
 grades an even older GPU. Eventually it will reach somebody that can’t a
 fford 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 de
 velopment in the process.\n\nWhat did this work entail?\n\nI'll talk about
  implementing various display features\, VCE support\, DRM format modifier
 s\, Vulkan\, improved GPU hang recovery\, sparse bindings\, fixing memory 
 management issues\, power management bugs and making some GPUs boot that p
 reviously never worked on Linux.\n\nWith that\, GCN GPUs can now run a mod
 ern Linux graphics stack using the amdgpu kernel driver and the RADV Vulka
 n driver.\n\nhttps://indico.freedesktop.org/event/12/contributions/545/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/545/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Demo: Turnip without Root
DTSTART;VALUE=DATE-TIME:20260929T191500Z
DTEND;VALUE=DATE-TIME:20260929T192500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-569@indico.freedesktop.org
DESCRIPTION:Speakers: Lucas Fryzek (Igalia S.L.)\nTurnip is one of Mesa's 
 few drivers that has support for multiple kernel drivers\, including the u
 pstream 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 we
 ll as unmodified android phones\, which are typically pretty locked down.\
 n\nThis talk will be a quick crash course for anyone interested in getting
  involved in Turnip's development\, showing what tools are available to be
 gin development with a completely unmodified stock android device.\n\nhttp
 s://indico.freedesktop.org/event/12/contributions/569/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/569/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Wednesday Opening Session
DTSTART;VALUE=DATE-TIME:20260930T130000Z
DTEND;VALUE=DATE-TIME:20260930T131000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-574@indico.freedesktop.org
DESCRIPTION:https://indico.freedesktop.org/event/12/contributions/574/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/574/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Upstreaming Tyr: a DRM GPU kernel driver in Rust
DTSTART;VALUE=DATE-TIME:20260930T161000Z
DTEND;VALUE=DATE-TIME:20260930T163000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162856Z
UID:indico-contribution-67-540@indico.freedesktop.org
DESCRIPTION:Speakers: Deborah Brouwer (Collabora)\nThe 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.\n\nIn this talk\, I will walk through the initia
 l stage of booting the microcontroller (MCU) in a Mali-G610 GPU to demonst
 rate how Tyr is using some of the newest Rust kernel abstractions for grap
 hics. In particular\, I will discuss how Tyr uses DRM GEM shared-memory bu
 ffer objects in conjunction with the GPU virtual memory manager to load th
 e MCU firmware and start up the command-stream frontend for the GPU.\n\nht
 tps://indico.freedesktop.org/event/12/contributions/540/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/540/
END:VEVENT
END:VCALENDAR
