BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CERN//INDICO//EN
BEGIN:VEVENT
SUMMARY:"I'm not an AMD expert\, but..."
DTSTART;VALUE=DATE-TIME:20221005T182000Z
DTEND;VALUE=DATE-TIME:20221005T184000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-50@indico.freedesktop.org
DESCRIPTION:Speakers: Melissa Wen (Igalia)\nLet's talk about developing AM
 D display drivers in the DRM subsystem as an external contributor. Part of
  this work is a trail of breadcrumbs to build documentation. What are thos
 e breadcrumbs? How do they help to review\, fix\, improve and enable featu
 res of AMD drivers? How would both sides benefit if those pieces of inform
 ation were already documented? We are gathering information from anywhere 
 and also bothering experts for input. Ultimately\, this presentation focus
 es on AMD driver development but may fit DRM drivers of any GPU vendors.\n
 \nhttps://indico.freedesktop.org/event/2/contributions/50/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/50/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Opening session
DTSTART;VALUE=DATE-TIME:20221004T133000Z
DTEND;VALUE=DATE-TIME:20221004T135000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-82@indico.freedesktop.org
DESCRIPTION:Speakers: Arkadiusz Hiler (CodeWeavers)\, Jeremy White (CodeWe
 avers)\nhttps://indico.freedesktop.org/event/2/contributions/82/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/82/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Opening session
DTSTART;VALUE=DATE-TIME:20221005T133000Z
DTEND;VALUE=DATE-TIME:20221005T134000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-83@indico.freedesktop.org
DESCRIPTION:Speakers: Arkadiusz Hiler (CodeWeavers)\, Jeremy White (CodeWe
 avers)\nhttps://indico.freedesktop.org/event/2/contributions/83/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/83/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Introduction to DisplayPort MST support on Linux
DTSTART;VALUE=DATE-TIME:20221005T163000Z
DTEND;VALUE=DATE-TIME:20221005T165000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-67@indico.freedesktop.org
DESCRIPTION:Speakers: Lyude Paul (Red Hat)\nThis presentation will just be
  about:\n\n - The basics of how DisplayPort MST works w/r/t bandwidth mana
 gement and topology probing\n - The current state of DisplayPort MST suppo
 rt in the kernel\n - High-level overview of the helpers we provide and how
  drivers can use them\n - Future (as of writing this at least) plans for U
 API\n - Troubleshooting tips\n\nhttps://indico.freedesktop.org/event/2/con
 tributions/67/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/67/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Opening session
DTSTART;VALUE=DATE-TIME:20221006T140000Z
DTEND;VALUE=DATE-TIME:20221006T141000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-85@indico.freedesktop.org
DESCRIPTION:Speakers: Arkadiusz Hiler (CodeWeavers)\, Jeremy White (CodeWe
 avers)\nhttps://indico.freedesktop.org/event/2/contributions/85/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/85/
END:VEVENT
BEGIN:VEVENT
SUMMARY:FEX-Emu: Mesa interactions in an emulated environment
DTSTART;VALUE=DATE-TIME:20221006T153500Z
DTEND;VALUE=DATE-TIME:20221006T162000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-52@indico.freedesktop.org
DESCRIPTION:Speakers: Ryan Houdek (FEX-Emu)\nFEX-Emu is an emulator for ru
 nning x86 and x86-64 applications on AArch64.\nRunning Mesa inside of this
  emulated environment is an interesting challenge that cross architure\, A
 BI\, and kernel API boundaries.\n\nA short primer on how FEX-Emu works the
 n we will walk through the challenges of running video drivers on architec
 tures that they were not originally designed for. What it means to run ins
 ide of an emulated environment from the mesa perspective. Then what we are
  doing for performance optimizations\, debug improvements\, and future end
 eavors.\n\nChallenges include:\n\n - IOCTL/DRM interface isn't the same be
 tween architectures\n - Virtual address space not being 47-bit \n - Jumpin
 g across architecture boundaries for thunks\n - Running 32-bit application
 s as a 64-bit process\n - Compiling AArch64 drivers for an x86/x86-64 envi
 ronment\n\nhttps://indico.freedesktop.org/event/2/contributions/52/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/52/
END:VEVENT
BEGIN:VEVENT
SUMMARY:State of the X.org
DTSTART;VALUE=DATE-TIME:20221006T194000Z
DTEND;VALUE=DATE-TIME:20221006T200000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-58@indico.freedesktop.org
DESCRIPTION:Speakers: Lyude Paul (Red Hat)\nHere I discuss the state of th
 e X.org foundation!\n\nhttps://indico.freedesktop.org/event/2/contribution
 s/58/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/58/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Rusticl: An OpenCL implementation written in Rust
DTSTART;VALUE=DATE-TIME:20221005T153500Z
DTEND;VALUE=DATE-TIME:20221005T162000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-51@indico.freedesktop.org
DESCRIPTION:Speakers: Karol Herbst (Red Hat\, Nouveau)\nRusticl is an Open
 CL implementation inside Mesa written in Rust.\n\nI'd like to talk about t
 he general approach I had taken and what the biggest hurdles were\, like w
 hat common concepts in C map nicely and which do not. And what can we chan
 ge in Mesa\, to make it easier for other similar projects.\n\nhttps://indi
 co.freedesktop.org/event/2/contributions/51/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/51/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Closing session
DTSTART;VALUE=DATE-TIME:20221006T220000Z
DTEND;VALUE=DATE-TIME:20221006T222000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-86@indico.freedesktop.org
DESCRIPTION:Speakers: Arkadiusz Hiler (CodeWeavers)\, Jeremy White (CodeWe
 avers)\nhttps://indico.freedesktop.org/event/2/contributions/86/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/86/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Mesh shading implementation in Mesa
DTSTART;VALUE=DATE-TIME:20221004T143000Z
DTEND;VALUE=DATE-TIME:20221004T151500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-49@indico.freedesktop.org
DESCRIPTION:Speakers: Timur Kristóf (Valve)\nMesh shading introduces a ne
 w kind of graphics pipeline that replaces the traditional vertex/tessellat
 ion/geometry shaders. There are two new stages: mesh shaders which can cre
 ate an arbitrary primitive topology and the optional task shaders\, for ge
 ometry amplification.\n\nThis talk focuses on presenting how mesh and task
  shaders are implemented in Mesa\, with specific details on how the new sh
 ader stages are compiled to NIR and how the new API and shader features ma
 p to AMD "RDNA2" hardware.\n\nhttps://indico.freedesktop.org/event/2/contr
 ibutions/49/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/49/
END:VEVENT
BEGIN:VEVENT
SUMMARY:introduction to isaspec
DTSTART;VALUE=DATE-TIME:20221005T134500Z
DTEND;VALUE=DATE-TIME:20221005T140500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-55@indico.freedesktop.org
DESCRIPTION:Speakers: Rob Clark (Google)\nisaspec is tool to describe an i
 nstruction set in xml\, and generate assembler and disassembler from that 
 single description.  It is currently used by freedreno (ir3)\, with a WIP 
 MR for etnaviv conversion.  It has a number of interesting features do dea
 l with (at least slightly) weird instruction sets:\n\n - the base construc
 t is a "bitset"\, which can be an entire instruction\, or used as a field 
 type in a larger bitset\n - flexible override and display mechanism\, to d
 eal with instructions where some bits have completely different meaning de
 pending on other bit(s) in the instruction\, to deal with mnemonics\, etc\
 n - inheritance ("extends") to reduce duplication between groups of simila
 r instructions\n\nhttps://indico.freedesktop.org/event/2/contributions/55/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/55/
END:VEVENT
BEGIN:VEVENT
SUMMARY:moar fps in a vm\, with this one little trick
DTSTART;VALUE=DATE-TIME:20221005T210000Z
DTEND;VALUE=DATE-TIME:20221005T214500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-53@indico.freedesktop.org
DESCRIPTION:Speakers: Rob Clark (Google)\nvirtgpu drm native contexts - (n
 ear) native gpu performance in a VM utilizing virglrenderer drm native con
 texts.\n\nCompared to api level virtualization (aka virgl)\, native gfx pe
 rformance (within a few percent or less)\, and significant CPU overhead re
 duction (and therefore power savings)\, can be had with the new virglrende
 rer drm native context feature.  All it takes is a very small amount of co
 de in mesa and virglrenderer.  This talk covers the general approach\, per
 formance trade-offs in hostguest protocol design\, and why this important 
 for ChromeOS.\n\nhttps://indico.freedesktop.org/event/2/contributions/53/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/53/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Replacing the geometry pipeline with mesh shaders
DTSTART;VALUE=DATE-TIME:20221004T140000Z
DTEND;VALUE=DATE-TIME:20221004T142000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-48@indico.freedesktop.org
DESCRIPTION:Speakers: Ricardo Garcia (Igalia\, S.L.)\nThis talk will discu
 ss the problems with the traditional vertex processing pipeline and presen
 t how mesh shading solves these problems. Instead of processing a fixed se
 t of input vertices\, mesh shaders can create an arbitrary topology of ver
 tices and primitives. Mesh shading also includes a new solution for geomet
 ry amplification: task shaders.\n\nThe talk should be scheduled before Tim
 ur's talk about implementing mesh shaders in the RADV Mesa driver.\n\nhttp
 s://indico.freedesktop.org/event/2/contributions/48/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/48/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Zink: Staging a Global\, Cross-Platform OpenGL Takeover
DTSTART;VALUE=DATE-TIME:20221004T195500Z
DTEND;VALUE=DATE-TIME:20221004T204000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-64@indico.freedesktop.org
DESCRIPTION:Speakers: Mike Blumenkrantz (Valve)\nFor decades\, OpenGL has 
 been a widely used and supported cross-platform graphics API. Each vendor 
 has its own drivers\, and these implementations have been developed and ma
 intained with varying priorities\, leading to a scenario where application
 s may run very differently based on whether the environment is Linux or Wi
 ndows\, x86 or Adreno\, waxing or waning moon\, etc.\n\nThis is not a good
  user experience\, and it is not a tenable one for implementors either as 
 companies and projects begin to reassign resources towards more modern API
 s like D3D12 and Vulkan. What happens when the only OpenGL implementation 
 for a platform has poor performance and lacks the engineers needed to repa
 ir it? What happens when new hardware is designed and there is no OpenGL i
 mplementation at all?\n\nThis is where Zink shines as a layered OpenGL imp
 lementation atop Vulkan. By having common codepaths used by all Vulkan dri
 vers\, a given platform needs only create a Vulkan implementation which sa
 tisfies the Zink feature requirements in order to gain a free OpenGL imple
 mentation--One that is\, ideally\, performant and correct on all systems i
 n all scenarios.\n\nThis talk will explore the history and development pro
 gress of Zink\, the current status\, and plans for global OpenGL driver do
 mination.\n\nhttps://indico.freedesktop.org/event/2/contributions/64/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/64/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Runtime display switch implementation in a Linux DRM bridge subsys
 tem
DTSTART;VALUE=DATE-TIME:20221005T222000Z
DTEND;VALUE=DATE-TIME:20221005T224000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-76@indico.freedesktop.org
DESCRIPTION:Speakers: Jagan Teki ()\nDue to rapid graphical industrial evo
 lution\, display interface providers are coming up with display bridges to
  address the mismatch between application-specific display interfaces vs o
 n-chip display controllers (like from SoC\, MCU). This simplifies the on-c
 hip solution provider to concentrate on a single display interface so that
  the application can choose a direct interface or any other interface by u
 sing a display bridge.\n\nDisplay bridges are linear and one-to-one displa
 y interface convertors however the display interface provider makes the fu
 rther complexity to these bridges and came up with a display switch that c
 an take a single display interface input and convert more than one display
  interface output. This kind of display switch has a variety of use cases 
 in industrial and consumer graphic applications. A couple of display switc
 h designs are available in the market via conventional mux with display br
 idges and a complete converter bridge chip with a one-to-two interface.\n\
 nAs the Linux DRM subsystem progresses toward DRM bridges\, these display 
 switches are well suited to be part of DRM bridges. Supporting display swi
 tches in Linux DRM is complex and new as DRM bridges are linear in archite
 cture. In order to operate display switches via drm bridge\, it requires a
  pipeline to non-linear and tree structure as switch operate more than one
  output.\n\nThis talk will explain how this display switching is implement
 ed in DRM bridges on top of fbcon and KMS applications by considering real
 -time solutions of MIPI DSI host bridge with mux switch followed by HDMI a
 nd LVDS bridges on NXP i.MX8M platform.  \n\nAfter that\, this talk explai
 ns the current working status of runtime display switching\, issues\, comm
 unity suggestions\, and future plans.\n\nNote: links for community discuss
 ion on this topic\n- https://www.spinics.net/lists/dri-devel/msg318524.htm
 l\n- https://www.spinics.net/lists/dri-devel/msg340416.html\n\nhttps://ind
 ico.freedesktop.org/event/2/contributions/76/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/76/
END:VEVENT
BEGIN:VEVENT
SUMMARY:World's Slowest Raytracer
DTSTART;VALUE=DATE-TIME:20221004T164000Z
DTEND;VALUE=DATE-TIME:20221004T172500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-62@indico.freedesktop.org
DESCRIPTION:Speakers: Bas Nieuwenhuizen (RADV)\nContinuing Jason's ray tra
 cing series this talk will be all about how we ended up implementing it in
  radv. I will talk about what hardware support RDNA provides and all the w
 ork we have to do in software. I will demonstrate some of the major perfor
 mance challenges\, contrast with how Intel solved them and show how ray tr
 acing is on track to becoming probably the single most complex feature in 
 radv.\n\nhttps://indico.freedesktop.org/event/2/contributions/62/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/62/
END:VEVENT
BEGIN:VEVENT
SUMMARY:KUnit sorcery and the uncanny nature of FPU in the DRM
DTSTART;VALUE=DATE-TIME:20221004T211000Z
DTEND;VALUE=DATE-TIME:20221004T215500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-65@indico.freedesktop.org
DESCRIPTION:Speakers: Isabella Basso (University of São Paulo)\, Maíra C
 anal (University of São Paulo)\, Magali Lemes ()\nIt's very easy for Linu
 x kernel driver maintainers to build strongholds around their code\, as it
 's very difficult for the lay contributor to understand unusual macros or 
 code that's often not properly documented and assumed to be only edited by
  "experts". As this is often the case with DRM drivers\, we propose the ad
 option of KUnit as a tool not only for making such code more reliable\, bu
 t also for making it more approachable as unit tests provide a simple and 
 elegant way of finding exactly which piece of code has been broken. We exp
 lore this magic tool's adoption in the context of AMD's jarring DML submod
 ule and how we can turn it from a spooky piece of code to a more friendly 
 face.\n\nhttps://indico.freedesktop.org/event/2/contributions/65/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/65/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Status of Vulkan on Raspberry Pi
DTSTART;VALUE=DATE-TIME:20221005T141500Z
DTEND;VALUE=DATE-TIME:20221005T143500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-68@indico.freedesktop.org
DESCRIPTION:Speakers: Iago Toral (Igalia\, S.L.)\nThere has been a lot of 
 activity in V3DV\, the Vulkan driver for Raspberry Pi 4\, over the last ye
 ar: we have significantly reworked our synchronization code\, obtained Vul
 kan 1.1 conformance\, implemented Vulkan 1.2 support\, continued to work o
 n compiler optimizations and more.\n\nIn this talk I would like to go thro
 ugh the main development milestones and\nchanges we implemented in the dri
 ver as well as discussing some limitations of the underlying hardware plat
 form that have discouraged us from implementing features such as scalar bl
 ock layout or fp16.\n\nhttps://indico.freedesktop.org/event/2/contribution
 s/68/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/68/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Enable hardware acceleration for GL applications without glamor on
  Xorg modesetting driver
DTSTART;VALUE=DATE-TIME:20221005T144500Z
DTEND;VALUE=DATE-TIME:20221005T150500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-60@indico.freedesktop.org
DESCRIPTION:Speakers: José María Casanova Crespo (Igalia)\, Christopher 
 Michael (Igalia)\nThis talk will focus on development efforts and progress
  of enabling hardware acceleration using the modesetting Xorg driver on Ra
 spberry Pi 1-3 devices without using Glamor. \n\nWe will discuss the reaso
 ns for disabling Glamor on these Raspberry Pi devices\, along with some pr
 evious attempts to accomplish this. This talk will also cover the methods 
 and technologies used in the current implementation such as DRI3\, GEM and
  GBM.\n\nhttps://indico.freedesktop.org/event/2/contributions/60/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/60/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Async page flip in atomic API
DTSTART;VALUE=DATE-TIME:20221005T215500Z
DTEND;VALUE=DATE-TIME:20221005T221500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-61@indico.freedesktop.org
DESCRIPTION:Speakers: André Almeida (Igalia)\nFlip pages asynchronously h
 as been available for a long time in DRM through the old API. This operati
 on allows userspace to update the display content as soon as possible\, re
 gardless of the vblank. However\, it still not possible to do so using DRM
 's Atomic commit API yet.\n\nThis talk will present the progress made so f
 ar to enable this\, the challenges and the remaining work to get this merg
 ed.\n\nhttps://indico.freedesktop.org/event/2/contributions/61/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/61/
END:VEVENT
BEGIN:VEVENT
SUMMARY:A step towards explicit synchronization
DTSTART;VALUE=DATE-TIME:20221006T141500Z
DTEND;VALUE=DATE-TIME:20221006T143500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-77@indico.freedesktop.org
DESCRIPTION:Speakers: Bas Nieuwenhuizen (RADV)\nThis talk will be about th
 e recent work to remove implicit synchronization from RADV. I will talk ab
 out how we used implicit sync previously including the hacks we had to mak
 e it not terrible\, then I will discuss why I'm trying to kill it and fina
 lly I will talk about how we are moving over to explicit sync.\n\nThis wil
 l not cover user mode fences or getting more windowing systems to use expl
 icit synchronization.\n\nhttps://indico.freedesktop.org/event/2/contributi
 ons/77/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/77/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Is HDR Harder?
DTSTART;VALUE=DATE-TIME:20221005T185000Z
DTEND;VALUE=DATE-TIME:20221005T193500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-56@indico.freedesktop.org
DESCRIPTION:Speakers: Harry Wentland (AMD)\nHave you ever wondered why HDR
  seems to be so complicated? Isn't it simply brighter displays and more co
 lors? Doesn't Android already support HDR displays? Why isn't there suppor
 t for it upstream and on Linux desktops?\n\nThis talk will try to make som
 e sense of what HDR is\, its different types\, HDR use-cases\, and how sup
 porting them presents different challenges. It will give an overview of ef
 forts to enable HDR in Weston\, including work to the wayland-protocol and
  DRM/KMS APIs\, as well as discuss efforts to improve HDR support for Chro
 meOS. We will touch on the need for tone and gamut mapping\, including top
 ics such as 3D LUT usage. Along the way we will try to de-mystify what hap
 pens inside the display HW on the transmitter side and what happens (or do
 esn't happen) on the panel side\, and talk about GPU composition vs DRM/KM
 S composition for HDR planes.\n\nThe goal of this talk is to give you a go
 od foundation to follow the HDR work on Linux and trigger discussions that
  will help us come to a consensus for an HDR DRM/KMS APIs\, as well as for
  the wayland-protocol. Hopefully this will allow us to enable HDR displays
  for full glorious HDR video playback on an HDR desktop that mixes HDR and
  SDR content\, looks good doing so\, and saves sweet\, sweet battery life 
 at the same time.\n\nhttps://indico.freedesktop.org/event/2/contributions/
 56/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/56/
END:VEVENT
BEGIN:VEVENT
SUMMARY:How to write a Vulkan driver in 2022
DTSTART;VALUE=DATE-TIME:20221004T154500Z
DTEND;VALUE=DATE-TIME:20221004T163000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-57@indico.freedesktop.org
DESCRIPTION:Speakers: Jason Ekstrand (Collabora)\nA lot has changed in the
  last six and a half years since the Vulkan spec was first released.  Inst
 ead of only having one Vulkan driver in Mesa\, we now have nine.  Mesa has
  also built quite a bit of shared Vulkan driver infrastructure over the ye
 ars.  Writing a new Vulkan driver today looks little like it did six years
  ago.  In this talk\, Jason will give an overview of the infrastructure we
  have today and how it makes writing Vulkan drivers easier.\n\nhttps://ind
 ico.freedesktop.org/event/2/contributions/57/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/57/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Explicit Synchronization for Linux Display Servers
DTSTART;VALUE=DATE-TIME:20221006T144500Z
DTEND;VALUE=DATE-TIME:20221006T150500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-78@indico.freedesktop.org
DESCRIPTION:Speakers: Erik Kurzinger ()\nCurrent Linux display server arch
 itecture is based on the assumption that memory access by direct rendering
  devices is implicitly synchronized by the kernel. There is a growing cons
 ensus in the community that this has inherent limitations for both perform
 ance and functionality. This talk will discuss current efforts towards mov
 ing to an explicit synchronization model across Wayland [1]\, X11 / Xwayla
 nd [2]\, and user-space graphics drivers\, including some of the challenge
 s posed\, potential solutions\, and expected benefits to the Linux graphic
 s ecosystem.\n\n[1] https://gitlab.freedesktop.org/wayland/wayland-protoco
 ls/-/merge_requests/90\n\n[2] https://gitlab.freedesktop.org/xorg/xserver/
 -/merge_requests/967\n\nhttps://indico.freedesktop.org/event/2/contributio
 ns/78/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/78/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Tasting the Forbidden Apple
DTSTART;VALUE=DATE-TIME:20221004T190000Z
DTEND;VALUE=DATE-TIME:20221004T194500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-66@indico.freedesktop.org
DESCRIPTION:Speakers: Alyssa Rosenzweig (Collabora)\, Lina Asahi ()\nThe h
 ardware is full of dark magic. The firmware is magic ring buffers all the 
 way down. And the driver must chant special incantations to bring to life 
 this Frankenstein GPU.\n\nThat's a job for two witches\, a spell book of r
 everse-engineering tricks\, and a heap of cursed software. Join us in our 
 quest to free the Apple GPU from its Metal chains and summon its magic pow
 ers to Asahi Linux.\n\nhttps://indico.freedesktop.org/event/2/contribution
 s/66/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/66/
END:VEVENT
BEGIN:VEVENT
SUMMARY:There are no dragons: porting fbdev drivers to DRM/KMS
DTSTART;VALUE=DATE-TIME:20221005T194500Z
DTEND;VALUE=DATE-TIME:20221005T203000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-54@indico.freedesktop.org
DESCRIPTION:Speakers: Javier Martinez Canillas ()\nTwo common misconceptio
 ns about DRM/KMS are pervasive when compared against the fbdev subsystem.\
 n\nThe first one is that it is tailored to complex graphic devices and tha
 t it does not scale down well to support very simple display controllers. 
 The second one is that it is complicated and not easy to delve into for wr
 iting graphic drivers. The argument is that fbdev on the other hand is sim
 pler and easier to understand.\n\nThis talk shares my experience\, as some
 one with no previous experience writing DRM/KMS drivers\, when porting fbd
 ev drivers for the simplest displays I could find. The purpose is to debun
 k these myths and explain how straightforward that process was\, thanks to
  the plethora of reusable and composable helper libraries that the subsyst
 em provides to developers.\n\nPorting fbdev drivers to DRM/KMS not only al
 lows devices to be used with modern graphical stacks but also leads to dri
 vers that are more maintainable.\n\nhttps://indico.freedesktop.org/event/2
 /contributions/54/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/54/
END:VEVENT
BEGIN:VEVENT
SUMMARY:GFXReconstruct - a tool to capture and replay streams of Vulkan AP
 I calls
DTSTART;VALUE=DATE-TIME:20221006T163000Z
DTEND;VALUE=DATE-TIME:20221006T171500Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-59@indico.freedesktop.org
DESCRIPTION:Speakers: Brad Grantham (LunarG\, Inc.)\nLunarG’s GFXReconst
 ruct is a suite of tools for capturing streams of graphics API calls from 
 running Vulkan applications\, processing those streams in various ways\, a
 nd replaying streams on live devices.\n\nGFXReconstruct 1.0 supports captu
 ring and replaying Vulkan API calls on Linux\, Android\, and Windows.  The
  use cases that drive development of the tool include GPU bringup\, driver
  feature regression testing\, and submission of reproducible test cases fo
 r bug reporting.  The container format is API-agnostic and LunarG plans su
 pport for more APIs.  A capture file contains all context to replay the ca
 ptured API call stream and is stored compressed by default.\n\nIn this ses
 sion we’ll introduce GFXReconstruct 1.0.  We’ll talk about how we deve
 lop gfxreconstruct and how we incorporate community contributions.  We’l
 l show where to get it\, how to install binaries\, and also how to build i
 t.  Using the `VK_LAYER_LUNARG_gfxreconstruct` Vulkan API layer to capture
  a Linux application's Vulkan calls\, we'll demonstrate how to look at a h
 uman-readable dump of those calls and how to replay the captured stream. W
 e'll briefly review the other tools in the GFXReconstruct package too.  \n
 \nLunarG is a software engineering consultancy specializing in 3D graphics
  software solutions and is an active developer and maintainer of Vulkan Ec
 osystem components such as the Vulkan Loader\, Vulkan Validation Layer\, G
 FXReconstruct\, and the Vulkan SDK.\n\nhttps://indico.freedesktop.org/even
 t/2/contributions/59/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/59/
END:VEVENT
BEGIN:VEVENT
SUMMARY:Implementing the graphics pipeline on compute
DTSTART;VALUE=DATE-TIME:20221006T184500Z
DTEND;VALUE=DATE-TIME:20221006T193000Z
DTSTAMP;VALUE=DATE-TIME:20260717T235720Z
UID:indico-contribution-5-63@indico.freedesktop.org
DESCRIPTION:Speakers: Erik Faye-Lund (Collabora)\nOver the last decade or 
 so\, the GPU has gone from something of a\nnice-to-have feature to an abso
 lute must\, across a lot of industries. You\ncan hardly boot a modern syst
 em without supporting Vulkan or OpenGL (ES).\n\nTechnologies such as LLVMp
 ipe has allowed us to emulate such hardware\, at\na significant performanc
 e and memory bandwidth loss. It's proven very\nuseful for purposes such as
  bringing up new platforms before GPU support\nhas been added\, for instan
 ce. And it can be a great solution in some cases\nwhere the amount of data
  to process is low.\n\nBut in some industries\, the needs for compute-pipe
 line processing power\ngreatly outweigh the needs for graphics-pipeline pr
 ocessing power. Yet\nmost GPUs still have fixed function graphics-pipeline
  support\, such as\nprimitive assembly\, rasterization\, blending. Impleme
 nting these in\nhardware is a very time-consuming task\, and can sometimes
  brings little\nbenefit.\n\nFor instance\, a modern camera processor needs
  to perform heavy image\nprocessing algorithms\, even though it might not 
 have a display. In such\ncases\, a GPU compute kernel is typically used.\n
 \nIt should be entirely possible to implement a reusable graphics pipeline
 \non top of the compute-pipeline\, paving the way for simpler GPU designs\
 nwhile still remaining useful. Think of this approach as something like\nL
 LVMpipe\, except generating compute shader kernels instead of CPU code.\n\
 nImplementing a compute-shader-only GPU is something that's much more\nfea
 sible for new players\, for instance for an initial open source GPU\ndesig
 n.\n\nhttps://indico.freedesktop.org/event/2/contributions/63/
LOCATION:Opus Hall 201
URL:https://indico.freedesktop.org/event/2/contributions/63/
END:VEVENT
END:VCALENDAR