BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CERN//INDICO//EN
BEGIN:VEVENT
SUMMARY:Workshop recap: Mesa CI
DTSTART;VALUE=DATE-TIME:20260930T205500Z
DTEND;VALUE=DATE-TIME:20260930T210000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-576@indico.freedesktop.org
DESCRIPTION:Speakers: Martin Roukala (né Peres) (MuPuF TMI / Valve contra
 ctor)\nhttps://indico.freedesktop.org/event/12/contributions/576/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/576/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Workshop recap: Towards a governance model for Mesa
DTSTART;VALUE=DATE-TIME:20260930T210000Z
DTEND;VALUE=DATE-TIME:20260930T210500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-577@indico.freedesktop.org
DESCRIPTION:Speakers: Alyssa Rosenzweig (Intel)\, Erik Faye-Lund (Arm)\nht
 tps://indico.freedesktop.org/event/12/contributions/577/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/577/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Vulkan CTS uses too much system memory? No problem
DTSTART;VALUE=DATE-TIME:20260928T205000Z
DTEND;VALUE=DATE-TIME:20260928T205500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-548@indico.freedesktop.org
DESCRIPTION:Speakers: Ricardo Garcia (Igalia\, S.L.)\nVulkan CTS memory re
 quirements had been steadily increasing over many years until reaching a b
 reaking 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 po
 stmortem that also helps set expectations for CTS users.\n\nhttps://indico
 .freedesktop.org/event/12/contributions/548/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/548/
END:VEVENT
BEGIN:VEVENT
SUMMARY:etnaviv: good things take time
DTSTART;VALUE=DATE-TIME:20260929T205000Z
DTEND;VALUE=DATE-TIME:20260929T205500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-549@indico.freedesktop.org
DESCRIPTION:Speakers: Christian Gmeiner (Igalia)\nSome things are worth th
 e wait. After a long\, patient climb\, the etnaviv project\nreached two mi
 lestones this year that once felt a long way off.\n\nThis lightning talk l
 ooks at where the driver finally caught up on conformance\, and\nat a new 
 capability that opens the door to a whole class of workloads etnaviv could
 \nnot run before.\n\nYears in the making\, and worth every step\n\nhttps:/
 /indico.freedesktop.org/event/12/contributions/549/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/549/
END:VEVENT
BEGIN:VEVENT
SUMMARY:CI-Tron for kernel development
DTSTART;VALUE=DATE-TIME:20260928T210000Z
DTEND;VALUE=DATE-TIME:20260928T210500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-551@indico.freedesktop.org
DESCRIPTION:Speakers: Dmitry Baryshkov (Qualcomm)\nWhen several new boards
  could not fit my traditional setup\, I had to revert to use of the CI-Tro
 n for automation of those boards. This lightining talk shows the use of CI
 -Tron for the kernel developent and maintainer duties\, emphasising its us
 age out of the traditional CI area.\n\nhttps://indico.freedesktop.org/even
 t/12/contributions/551/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/551/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Supporting workgroups where there aren't any
DTSTART;VALUE=DATE-TIME:20260929T210000Z
DTEND;VALUE=DATE-TIME:20260929T210500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-557@indico.freedesktop.org
DESCRIPTION:Speakers: Timur Kristóf (Valve)\nWorkgroups are a concept whi
 ch allow multiple SIMD waves of shaders to run together and share some mem
 ory. API features such as compute and mesh shaders expect the driver to su
 pport workgroups. Modern hardware typically supports it\, but... What if y
 ou 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 supp
 ort larger workgroups on older hardware that has an upper limit on the wor
 kgroup size?\n\nThe new compiler pass nir_lower_workgroup_size was invente
 d exactly for this purpose. Your driver can now support workgroups where t
 here aren't any\, or support larger workgroups when the HW can't.\n\nIn th
 is lightning talk I'll present what the challenge is with "emulating" work
 groups\; how we solved it\, and how we've used it to implement NVK mesh sh
 aders\, to support larger compute workgroups on old GPUs on RADV\, and eve
 n to find ray tracing issues.\n\nhttps://indico.freedesktop.org/event/12/c
 ontributions/557/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/557/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Navigating the Tunnel : DisplayPort over USB4/TBT
DTSTART;VALUE=DATE-TIME:20260930T203500Z
DTEND;VALUE=DATE-TIME:20260930T204000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-567@indico.freedesktop.org
DESCRIPTION:Speakers: Kunal Joshi (intel)\nA familiar failure motivates th
 is talk: two high-resolution displays on one USB4/Thunderbolt dock\, each 
 working alone but not together\, because nothing arbitrates the shared lin
 k.\n\nA DisplayPort monitor on such a dock looks like an ordinary connecto
 r to userspace\, but in the kernel the work is split across two subsystems
  that never call each other. The graphics driver (i915/xe plus the DRM DP 
 tunnel helpers) owns the DP source\, mode validation\, and atomic state. T
 he USB4/Thunderbolt connection manager (drivers/thunderbolt\, or controlle
 r firmware) owns the physical link and the bandwidth of every tunnel (i.e.
  DisplayPort\, PCIe\, USB3) sharing it. The two domains coordinate only th
 rough the DisplayPort Bandwidth Allocation protocol: a small set of DPCD r
 egisters carried over AUX.\n\nFrom that starting point the full bandwidth 
 lifecycle unfolds: how available bandwidth is estimated\, how a stream's r
 equirement is computed\, how the group budget is enforced during the atomi
 c check\, how the request is issued at commit and answered by the connecti
 on manager\, and how the state is updated at runtime.\n\n###Overview\n![Ov
 erview][1]\n\n###Outline\n1. **DP over USB4/Thunderbolt\, and the subsyste
 m split**\n   - What DP tunneling is\, and how it appears to userspace.\n 
   - The split of responsibility: DRM/KMS vs. `drivers/thunderbolt`.\n2. **
 The Bandwidth Allocation protocol**\n   - The DPCD register interface and 
 how a request reaches the connection manager.\n   - How the DRM DP tunnel 
 helpers bridge the two domains.\n3. **Case study: two displays on one dock
 **\n   - Walkthrough of a dock bandwidth exhaustion scenario.\n   - Estima
 tion\, requests\, and atomic-state representation in `i915`/`xe`.\n4. **Ho
 tplug**\n   - Dynamic recalculation on hotplug and state changes.\n5. **Fu
 ture work and upstreaming**\n   - Panel Replay bandwidth optimization.\n  
  - Asymmetric USB4 links and UHBR.\n   - Validation strategies.\n\nUpstrea
 m contributor : Imre Deak \n\n  [1]: https://github.com/KunalJoshi95/xdc/b
 lob/main/abstract.svg "Overview"\n\nhttps://indico.freedesktop.org/event/1
 2/contributions/567/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/567/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Finally getting rid of TGSI?
DTSTART;VALUE=DATE-TIME:20260928T210500Z
DTEND;VALUE=DATE-TIME:20260928T211000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-568@indico.freedesktop.org
DESCRIPTION:Speakers: Erik Faye-Lund (Arm)\nIt's been well over a decade s
 ince 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.\n\nThis talk will try to answer the 
 question: How can we finally get rid of TGSI in Mesa?\n\nhttps://indico.fr
 eedesktop.org/event/12/contributions/568/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/568/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Turning Driver Bugs into Vulkan CTS Tests
DTSTART;VALUE=DATE-TIME:20260928T205500Z
DTEND;VALUE=DATE-TIME:20260928T210000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-553@indico.freedesktop.org
DESCRIPTION:Speakers: Madeeha Javed (Igalia)\nFixing a Vulkan driver bug i
 s 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 enco
 untered while reproducing bugs in a small\, reliable conformance test\, an
 d explain why a straightforward test often isn't enough to expose the orig
 inal issue. The talk will conclude with a few practical lessons learned fr
 om contributing bug-fix regression tests to Vulkan CTS.\n\nhttps://indico.
 freedesktop.org/event/12/contributions/553/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/553/
END:VEVENT
BEGIN:VEVENT
SUMMARY:drm/dp: statups update of the common kernel framework.
DTSTART;VALUE=DATE-TIME:20260929T211000Z
DTEND;VALUE=DATE-TIME:20260929T211500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-552@indico.freedesktop.org
DESCRIPTION:Speakers: Dmitry Baryshkov (Qualcomm)\nOn the last XDC the pla
 n for the common DisplayPort framework in DRM was announced. Thihs lightin
 ing talk provides a (small) status update over the past year.\n\nhttps://i
 ndico.freedesktop.org/event/12/contributions/552/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/552/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Introducing the Wayland Content Frame Rate Protocol
DTSTART;VALUE=DATE-TIME:20260930T203000Z
DTEND;VALUE=DATE-TIME:20260930T203500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-550@indico.freedesktop.org
DESCRIPTION:Speakers: Naveen Kumar (Intel Corporation)\n**Problem Statemen
 t**\nCompositors 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 vi
 deo 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 fp
 s content is presented with irregular frame timing on a 40–60 Hz VRR dis
 play.\n\nFigure 1\nhttps://github.com/k2naveen/xdc-2026/blob/main/media-pl
 ayback-frame-judder.png\n\n**Solution**\nTo 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] u
 ses this information to apply Low Frame Rate Compensation (LFC) on VRR dis
 plays by selecting the lowest stable refresh-rate multiple of the content 
 frame rate\, or to switch to a matching supported display mode on fixed-re
 fresh displays\, delivering smooth\, judder-free playback.\n\n[1] https://
 gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/518\n[2]
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5091\n\nhttps://in
 dico.freedesktop.org/event/12/contributions/550/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/550/
END:VEVENT
BEGIN:VEVENT
SUMMARY:rusticl status update
DTSTART;VALUE=DATE-TIME:20260928T211000Z
DTEND;VALUE=DATE-TIME:20260928T211500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-554@indico.freedesktop.org
DESCRIPTION:Speakers: Karol Herbst (Red Hat\, Nouveau)\nShort status updat
 e about new OpenCL features supported\, features work in progress\, change
 s in driver status and what the priorities are going forward.\n\nhttps://i
 ndico.freedesktop.org/event/12/contributions/554/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/554/
END:VEVENT
BEGIN:VEVENT
SUMMARY:v3d/v3dv: status update from last XDC
DTSTART;VALUE=DATE-TIME:20260929T205500Z
DTEND;VALUE=DATE-TIME:20260929T210000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-555@indico.freedesktop.org
DESCRIPTION:Speakers: Juan A. Suarez (Igalia\, S.L.)\nThe V3D (OpenGL) and
  V3DV (Vulkan) drivers power the Broadcom GPU found in the Raspberry Pi 4 
 and 5.\n\nIn this lightning talk we will go through a high-level tour of t
 he latest updates to these drivers that we deliveredwhat things have been 
 done on them: new extensions and features\, performance improvements in di
 fferent paths\, refactors\, CI\, and so on.\n\nAfter this talk you will ha
 ve a better understanding on what happened in the RPi GPU driver developme
 nt in the last year.\n\nhttps://indico.freedesktop.org/event/12/contributi
 ons/555/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/555/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Resolving game bugs using retry faults
DTSTART;VALUE=DATE-TIME:20260929T210500Z
DTEND;VALUE=DATE-TIME:20260929T211000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-558@indico.freedesktop.org
DESCRIPTION:Speakers: Timur Kristóf (Valve)\nModern games and game engine
 s 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 pag
 e faults during gameplay.\n\nIn 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 reso
 lve page faults and let the game continue. We can also use this to impleme
 nt some features of the VK_KHR_device_fault extension.\n\nhttps://indico.f
 reedesktop.org/event/12/contributions/558/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/558/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Testing a browser on a real Wayland compositor (and why we all wan
 t this standardized)
DTSTART;VALUE=DATE-TIME:20260930T204000Z
DTEND;VALUE=DATE-TIME:20260930T204500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-556@indico.freedesktop.org
DESCRIPTION:Speakers: Orko Garai (Igalia)\nChromium runs thousands of inte
 ractive UI tests that need synthesized input. On Wayland\nthere's no porta
 ble way to do that\, and the reference compositor (weston) doesn't impleme
 nt\nenough of the real protocol surface to be representative. So we forked
  mutter\, taught it\nChromium's ui-controls protocol\, and wired it into o
 ur CI to run interactive tests on a\nreal compositor for both pre- and pos
 t-submit. This lightning talk covers what that took\,\nwhat broke\, and wh
 y every app project shouldn't have to reinvent this\, closing with a pitch
 \nto standardize cross-compositor application testing (cf. [wayland-protoc
 ols #230][1]).\n\n\n  [1]: https://gitlab.freedesktop.org/wayland/wayland-
 protocols/-/work_items/230\n\nhttps://indico.freedesktop.org/event/12/cont
 ributions/556/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/556/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Wayland vs X.org latency comparison
DTSTART;VALUE=DATE-TIME:20260930T204500Z
DTEND;VALUE=DATE-TIME:20260930T205000Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-559@indico.freedesktop.org
DESCRIPTION:Speakers: Kamil Łysik (NVIDIA)\nWayland input latency is a to
 pic discussed in the Linux graphics community and claims that “Wayland a
 dds latency” have been repeated in the past. This talk explores end-to-e
 nd latency comparison in an automated A/B testing setup designed to produc
 e more rigorous and reproducible measurements. The session focuses on comp
 arative evaluation across multiple compositors or window managers\, high-l
 evel display configurations\, and measurement methods\, with the goal of g
 iving compositor and driver developers a fairer basis for discussing laten
 cy.\n\nhttps://indico.freedesktop.org/event/12/contributions/559/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/559/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Workshop recap: Vulkan "Gallium"
DTSTART;VALUE=DATE-TIME:20260930T205000Z
DTEND;VALUE=DATE-TIME:20260930T205500Z
DTSTAMP;VALUE=DATE-TIME:20260904T162905Z
UID:indico-contribution-68-575@indico.freedesktop.org
DESCRIPTION:Speakers: Faith Ekstrand (Collabora)\nhttps://indico.freedeskt
 op.org/event/12/contributions/575/
LOCATION:
URL:https://indico.freedesktop.org/event/12/contributions/575/
END:VEVENT
END:VCALENDAR
