X.Org developer's Conference + WineConf + FOSS XR 2022

US/Central
Aric Stewart (CodeWeavers) , Arkadiusz Hiler (CodeWeavers) , Daniel Vetter (Intel) , Frederic Plourde (Collabora ltd.) , Jeremy White (CodeWeavers) , Ricardo Garcia (Igalia, S.L.) , Samuel Iglesias Gonsálvez (Igalia)
Description

The X.Org Developer's Conference is the event for developers working on all things Open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.). WineConf is the annual technical meeting for developers and supporters of the Wine Project. FOSSXR is for everyone interested in VR/AR/MR and Free software. This year, the three events are being held together.  The event is free to attend and open to the general public.

Participants
  • Abhinav Kumar
  • Adam Ford
  • Adam Harwood
  • Alexandre Julliard
  • Alvaro Soliverez
  • Alyssa Rosenzweig
  • André Almeida
  • Aric Stewart
  • Arkadiusz Hiler
  • Babu Durairaj
  • Bas Nieuwenhuizen
  • Ben Widawsky
  • Brad Grantham
  • Bradley Kuhn
  • Brendan Shanks
  • Brian Skalak
  • Bryan Brown
  • Chad Versace
  • Charlton Rodda
  • Christoph Haag
  • Christopher Michael
  • Clayton Craft
  • Connor Abbott
  • Da Xue
  • Daniel Schürmann
  • Daniel Stone
  • Daniel Vetter
  • David Heidelberg
  • Derek Foreman
  • Derek Lesho
  • Drew Davenport
  • Emmy Schwab
  • Erik Faye-Lund
  • Erik Kurzinger
  • Eva Pace
  • eXsoR .
  • Fang Liu
  • Femi Adegunloye
  • Frank Binns
  • Frederic Plourde
  • Gabriel Krisman Bertazi
  • Giovanni Mascellani
  • Gustavo Diaz Prado
  • Hari Ganti
  • Harisankar Poomuttam Suresh
  • Henri Verbeet
  • Herman Remy
  • Huw Davies
  • Iago Toral
  • Imran Khan
  • Isaac Rosedale
  • Isabella Basso
  • Jagan Teki
  • Jake Freeland
  • Jakob Bornecrantz
  • James Shargo
  • Jana Schmid
  • Jason Ekstrand
  • Javier Martinez Canillas
  • Jeffrey Ellison
  • Jeremy White
  • Jesse Natalie
  • John Brooks
  • John Einar Reitan
  • Joshua Ashton
  • José María Casanova Crespo
  • Justin Green
  • Karen Ghavam
  • Karol Herbst
  • Kevin Brace
  • Kyle Russell
  • Laura Ekstrand
  • Leo Li
  • Lina Asahi
  • Liviu Dudau
  • Lubosz Sarnecki
  • Luke Leighton
  • Luna Jernberg
  • Magali Lemes
  • Manasi Navare
  • Mandi Gagne
  • Mark Filion
  • Martin Roukala (né Peres)
  • Mateo Brian de Mayo
  • Mathieu Comandon
  • Maíra Canal
  • Melissa Wen
  • Mickey Williams
  • Miguel Casas
  • Mike Blumenkrantz
  • Moses Turner
  • Murad Bashirov
  • Nat Brown
  • Nehemiah Nehemiah Dacres (dacresni)
  • Niko Ryan
  • Nova King
  • Owen Rudge
  • Paul Christian
  • Paul Cook
  • Pierre-Loup Griffais
  • Piotr Caban
  • Rajendar Talatam
  • Ray Huang
  • Reilly Brogan
  • Ricardo Garcia
  • Richard Wright
  • Rob Clark
  • Rohan Garg
  • Ryan Houdek
  • Ryan Pavlik
  • Sameer Lattannavar
  • Sameer Lattannavar
  • Samuel Iglesias Gonsálvez
  • Samuel Pitoiset
  • Scott Lembcke
  • Scott Mansell
  • Seung-Woo Kim
  • Solomon Chiu
  • Stefanos Kornilios Mitsis Poiitidis
  • Timur Kristóf
  • Tobias Platen
  • Tom Prohofsky
  • Tomeu Vizoso
  • Tony Wasserka
  • Ulrich Czekalla
  • Vikas Mishra
  • Wayne Lin
  • William Sherman
  • Zeb Figura
XDC, WineConf, FOSS XR 2022
    • 07:30 08:30
      Coffee: Drinks and light pastries

      We will have breakfast beverages and light pastries

    • 08:30 16:55
      Main Track
      • 08:30
        Opening session 20m
        Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)
      • 09:00
        Replacing the geometry pipeline with mesh shaders 20m

        This talk will discuss the problems with the traditional vertex processing pipeline and present how mesh shading solves these problems. Instead of processing a fixed set of input vertices, mesh shaders can create an arbitrary topology of vertices and primitives. Mesh shading also includes a new solution for geometry amplification: task shaders.

        The talk should be scheduled before Timur's talk about implementing mesh shaders in the RADV Mesa driver.

        Speaker: Ricardo Garcia (Igalia, S.L.)
      • 09:30
        Mesh shading implementation in Mesa 45m

        Mesh shading introduces a new kind of graphics pipeline that replaces the traditional vertex/tessellation/geometry shaders. There are two new stages: mesh shaders which can create an arbitrary primitive topology and the optional task shaders, for geometry amplification.

        This talk focuses on presenting how mesh and task shaders are implemented in Mesa, with specific details on how the new shader stages are compiled to NIR and how the new API and shader features map to AMD "RDNA2" hardware.

        Speaker: Timur Kristóf (Valve)
      • 10:15
        Break 30m
      • 10:45
        How to write a Vulkan driver in 2022 45m

        A lot has changed in the last six and a half years since the Vulkan spec was first released. Instead 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 years. 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.

        Speaker: Jason Ekstrand (Collabora)
      • 11:40
        World's Slowest Raytracer 45m

        Continuing Jason's ray tracing 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 work we have to do in software. I will demonstrate some of the major performance challenges, contrast with how Intel solved them and show how ray tracing is on track to becoming probably the single most complex feature in radv.

        Speaker: Bas Nieuwenhuizen (RADV)
      • 12:25
        Lunch break 1h 35m
      • 14:00
        Tasting the Forbidden Apple 45m

        The hardware 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.

        That's a job for two witches, a spell book of reverse-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 powers to Asahi Linux.

        Speakers: Alyssa Rosenzweig (Collabora) , Lina Asahi
      • 14:55
        Zink: Staging a Global, Cross-Platform OpenGL Takeover 45m

        For 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 maintained with varying priorities, leading to a scenario where applications may run very differently based on whether the environment is Linux or Windows, x86 or Adreno, waxing or waning moon, etc.

        This 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 APIs like D3D12 and Vulkan. What happens when the only OpenGL implementation for a platform has poor performance and lacks the engineers needed to repair it? What happens when new hardware is designed and there is no OpenGL implementation at all?

        This is where Zink shines as a layered OpenGL implementation atop Vulkan. By having common codepaths used by all Vulkan drivers, a given platform needs only create a Vulkan implementation which satisfies the Zink feature requirements in order to gain a free OpenGL implementation--One that is, ideally, performant and correct on all systems in all scenarios.

        This talk will explore the history and development progress of Zink, the current status, and plans for global OpenGL driver domination.

        Speaker: Mike Blumenkrantz (Valve)
      • 15:40
        Break 30m
      • 16:10
        KUnit sorcery and the uncanny nature of FPU in the DRM 45m

        It's very easy for Linux 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 adoption of KUnit as a tool not only for making such code more reliable, but 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 explore this magic tool's adoption in the context of AMD's jarring DML submodule and how we can turn it from a spooky piece of code to a more friendly face.

        Speakers: Mrs Isabella Basso (University of São Paulo) , Mrs Maíra Canal (University of São Paulo) , Magali Lemes
    • 17:05 17:35
      Demos / Lightning talks I

      Demos have priority over lightning talks in this session.

      Lightning talks get schedule as time permits throughout the assigned time block. Please be ready!

      • 17:05
        Progress of MST improvement from AMD 10m

        For quite a while, MST doesn't work stably. As DisplayPort version 2.0 having MST as the default transmission method, MST is no longer just a specific scenario. Thus, we must have our MST support much more stable and robust than before.

        Besides the requirements from new technique, it's also a reasonable demand for laptop user to use multiple external disaplays. As the trend for laptop nowadays is having less output ports, USB Type-C is embraced by the industry which not only can transmit data but also video streams. User can leverage MST via type-c to send out video streams for the requirement of multiple external monitors.

        AMD has spended lots of effort recently on solving MST relevant issues and pushed to support DP2.0 128/132b encoding. At the same time, we also address dsc over mst relevant issues to have scenario of transmitting high resolution streams by MST more solid. Thanks to the help from many contributors, we now have MST into better stabilized status.

        Speaker: Mr Wayne Lin
      • 17:15
        Post OpenGL: casual graphics development 5m

        Vulkan is great, but it's not a great API for casually graphics development, like education or experimentation.

        With OpenGL slowly passing the horizon, we need some modern alternatives. This talk will discuss what we need, and maybe outline how we can get there.

        Speaker: Erik Faye-Lund (Collabora)
      • 17:20
        Update on OpenChrome Project 10m

        A quick update on OpenChrome Project progress since 2019 and its future roadmap.

        Speaker: Mr Kevin Brace (Brace Computer Laboratory)
    • 08:00 09:00
      Coffee: Drinks and light pastries

      We will have breakfast beverages and light pastries

    • 08:30 17:40
      Main Track
      • 08:30
        Opening session 10m
        Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)
      • 08:45
        introduction to isaspec 20m

        isaspec is tool to describe an instruction 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 deal with (at least slightly) weird instruction sets:

        • the base construct is a "bitset", which can be an entire instruction, or used as a field type in a larger bitset
        • flexible override and display mechanism, to deal with instructions where some bits have completely different meaning depending on other bit(s) in the instruction, to deal with mnemonics, etc
        • inheritance ("extends") to reduce duplication between groups of similar instructions
        Speaker: Rob Clark (Google)
      • 09:15
        Status of Vulkan on Raspberry Pi 20m

        There has been a lot of activity in V3DV, the Vulkan driver for Raspberry Pi 4, over the last year: we have significantly reworked our synchronization code, obtained Vulkan 1.1 conformance, implemented Vulkan 1.2 support, continued to work on compiler optimizations and more.

        In this talk I would like to go through the main development milestones and
        changes we implemented in the driver as well as discussing some limitations of the underlying hardware platform that have discouraged us from implementing features such as scalar block layout or fp16.

        Speaker: Iago Toral (Igalia, S.L.)
      • 09:45
        Enable hardware acceleration for GL applications without glamor on Xorg modesetting driver 20m

        This talk will focus on development efforts and progress of enabling hardware acceleration using the modesetting Xorg driver on Raspberry Pi 1-3 devices without using Glamor.

        We will discuss the reasons for disabling Glamor on these Raspberry Pi devices, along with some previous attempts to accomplish this. This talk will also cover the methods and technologies used in the current implementation such as DRI3, GEM and GBM.

        Speakers: José María Casanova Crespo (Igalia) , Christopher Michael (Igalia)
      • 10:05
        Break 30m
      • 10:35
        Rusticl: An OpenCL implementation written in Rust 45m

        Rusticl is an OpenCL implementation inside Mesa written in Rust.

        I'd like to talk about the general approach I had taken and what the biggest hurdles were, like what common concepts in C map nicely and which do not. And what can we change in Mesa, to make it easier for other similar projects.

        Speaker: Karol Herbst (Red Hat, Nouveau)
      • 11:30
        Introduction to DisplayPort MST support on Linux 20m

        This presentation will just be about:

        • The basics of how DisplayPort MST works w/r/t bandwidth management and topology probing
        • The current state of DisplayPort MST support in the kernel
        • High-level overview of the helpers we provide and how drivers can use them
        • Future (as of writing this at least) plans for UAPI
        • Troubleshooting tips
        Speaker: Lyude Paul (Red Hat)
      • 11:50
        Lunch break 1h 30m
      • 13:20
        "I'm not an AMD expert, but..." 20m

        Let's talk about developing AMD display drivers in the DRM subsystem as an external contributor. Part of this work is a trail of breadcrumbs to build documentation. What are those breadcrumbs? How do they help to review, fix, improve and enable features of AMD drivers? How would both sides benefit if those pieces of information were already documented? We are gathering information from anywhere and also bothering experts for input. Ultimately, this presentation focuses on AMD driver development but may fit DRM drivers of any GPU vendors.

        Speaker: Melissa Wen (Igalia)
      • 13:50
        Is HDR Harder? 45m

        Have you ever wondered why HDR seems to be so complicated? Isn't it simply brighter displays and more colors? Doesn't Android already support HDR displays? Why isn't there support for it upstream and on Linux desktops?

        This talk will try to make some sense of what HDR is, its different types, HDR use-cases, and how supporting them presents different challenges. It will give an overview of efforts 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 ChromeOS. We will touch on the need for tone and gamut mapping, including topics such as 3D LUT usage. Along the way we will try to de-mystify what happens inside the display HW on the transmitter side and what happens (or doesn't happen) on the panel side, and talk about GPU composition vs DRM/KMS composition for HDR planes.

        The goal of this talk is to give you a good 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.

        Speaker: Harry Wentland (AMD)
      • 14:45
        There are no dragons: porting fbdev drivers to DRM/KMS 45m

        Two common misconceptions about DRM/KMS are pervasive when compared against the fbdev subsystem.

        The first one is that it is tailored to complex graphic devices and that 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 writing graphic drivers. The argument is that fbdev on the other hand is simpler and easier to understand.

        This talk shares my experience, as someone with no previous experience writing DRM/KMS drivers, when porting fbdev drivers for the simplest displays I could find. The purpose is to debunk these myths and explain how straightforward that process was, thanks to the plethora of reusable and composable helper libraries that the subsystem provides to developers.

        Porting fbdev drivers to DRM/KMS not only allows devices to be used with modern graphical stacks but also leads to drivers that are more maintainable.

        Speaker: Javier Martinez Canillas
      • 15:30
        Break 30m
      • 16:00
        moar fps in a vm, with this one little trick 45m

        virtgpu drm native contexts - (near) native gpu performance in a VM utilizing virglrenderer drm native contexts.

        Compared to api level virtualization (aka virgl), native gfx performance (within a few percent or less), and significant CPU overhead reduction (and therefore power savings), can be had with the new virglrenderer drm native context feature. All it takes is a very small amount of code in mesa and virglrenderer. This talk covers the general approach, performance trade-offs in host<->guest protocol design, and why this important for ChromeOS.

        Speaker: Rob Clark (Google)
      • 16:55
        Async page flip in atomic API 20m

        Flip pages asynchronously has been available for a long time in DRM through the old API. This operation allows userspace to update the display content as soon as possible, regardless of the vblank. However, it still not possible to do so using DRM's Atomic commit API yet.

        This talk will present the progress made so far to enable this, the challenges and the remaining work to get this merged.

        Speaker: André Almeida (Igalia)
      • 17:20
        Runtime display switch implementation in a Linux DRM bridge subsystem 20m

        Due to rapid graphical industrial evolution, display interface providers are coming up with display bridges to address the mismatch between application-specific display interfaces vs on-chip display controllers (like from SoC, MCU). This simplifies the on-chip solution provider to concentrate on a single display interface so that the application can choose a direct interface or any other interface by using a display bridge.

        Display bridges are linear and one-to-one display interface convertors however the display interface provider makes the further complexity to these bridges and came up with a display switch that can 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 switch designs are available in the market via conventional mux with display bridges and a complete converter bridge chip with a one-to-two interface.

        As the Linux DRM subsystem progresses toward DRM bridges, these display switches are well suited to be part of DRM bridges. Supporting display switches in Linux DRM is complex and new as DRM bridges are linear in architecture. 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.

        This talk will explain how this display switching is implemented 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 and LVDS bridges on NXP i.MX8M platform.

        After that, this talk explains the current working status of runtime display switching, issues, community suggestions, and future plans.

        Note: links for community discussion on this topic
        - https://www.spinics.net/lists/dri-devel/msg318524.html
        - https://www.spinics.net/lists/dri-devel/msg340416.html

        Speaker: Jagan Teki
    • 08:45 10:45
      Workshop
      • 08:45
        Bare-metal CI: Successes and pain points of Mesa CI, future developments, and bringing CI to other projects 2h

        Mesa has one of the best collaborative, multi-vendor, in-depth testing system found in the
        open source world. It has prevented countless regressions and increased the quality of the
        project to the point that it ships to millions of gamers through distributions or the Steam Deck.

        Let's take some time to reflect on what makes the project successful, its pain points for users
        and developers, and how it could be applied to other components of the graphics stack such as
        the Linux DRM subsystem, DXVK/VKD3D, IGT, ...

        Proposed topics of conversation

        • Reducing the amount of environment variables that are passed around to increase re-usability of containers and ease local execution
        • Reducing the duplication of efforts between the containers and the rootfs: use the container as a base? run the container directly?
        • Reducing the number of instances of "CI took too long" by prioritizing jobs coming from Marge
        • Making running on bare metal as easy as running in the cloud runners. This would make other projects easier to get into the CI train: No visible spring boards in Mesa's code by moving the code to custom Gitlab Executors?
        • Making it easier to create new CI test farms, or for developers to share access to their test machines: Speccing up a kit, instructions to set things up, and making it easy to maintain/updates like in valve-infra.
        Speaker: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor)
    • 09:00 17:20
      WineConf

      Talks related to the Wine Project

      Convener: Jeremy White (CodeWeavers)
      • 09:00
        Wine keynote 40m

        The traditional WineConf opening keynote, where we review recent accomplishments and the plans for the upcoming stable release.

        Speaker: Alexandre Julliard
      • 09:45
        Proton: What Lies Down the Stream? 30m

        Proton is a downstream Wine distribution that bundles complementary software and replaces some built-ins with independent alternatives.

        The project also drives a lot of Wine development both up- and downstream.

        In this talk, I'll go through the current state of Proton's Wine and try to reflect on how are we doing on the upstreaming front and what remains downstream and why.

        Speaker: Arkadiusz Hiler (CodeWeavers)
      • 11:00
        The Time Has Come: Defending Wine's License 50m

        Wine is unique among copylefted projects for many reasons. One unique trait
        of Wine is that so rarely is LGPL — the copyleft license of Wine — violated.
        However, with the advent of more adoption of Linux-based system, and the need
        for vendors to run old Windows application on they systems, we now are seeing
        violations for the first time.

        This session will present the properties of the LGPL and what it should
        accomplish for users who find themselves in front of a Linux system that uses
        Wine to run Windows binaries. We'll discuss strategy and planning for
        enforcement of Wine's copyleft and discuss how we can accomplish this
        together as a community that includes Software Freedom Conservancy (Wine's
        non-profit home) and the many contributors to Wine.

        Speaker: Bradley Kuhn (Software Freedom Conservancy)
      • 13:20
        Wine hacking tips 45m

        This talk will discuss a variety of tips for hacking on Wine and present hints to ease your patches through the review process.

        Speaker: Huw Davies (CodeWeavers)
      • 14:20
        Wine + GitLab 45m

        Wine development has recently moved away from mailing lists and custom patch tracker to Merge Requests on GitLab, to which I have contributed a little.

        I want to trace the path we have taken to get here and discuss the current state and the future with the people who have contributed to the effort as well as the audience.

        Speaker: Arkadiusz Hiler (CodeWeavers)
      • 15:30
        Wine-Staging update 30m

        A brief update on the progress of wine-staging since last WineConf.

        Speaker: Zeb Figura (CodeWeavers, Inc.)
      • 16:00
        Wine Soapbox Session 1h
    • 17:50 18:50
      X.Org Foundation board of directors meeting 1h
      Speakers: Alyssa Rosenzweig (Collabora) , Daniel Vetter (Intel) , Emma Anholt (Google) , Lyude Paul (Red Hat) , Manasi Navare (Intel Corporation) , Mark Filion (Collabora) , Ricardo Garcia (Igalia, S.L.) , Samuel Iglesias Gonsálvez (Igalia)
    • 18:00 20:00
      Happy hour: Drinks and light appetizers

      We will have drinks and light appetizers for all three projects to enjoy and to socialize.

    • 08:00 09:00
      Coffee: Drinks and light pastries

      We will have breakfast beverages and light pastries

    • 09:00 17:20
      Main Track
      • 09:00
        Opening session 10m
        Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)
      • 09:15
        A step towards explicit synchronization 20m

        This talk will be about the recent work to remove implicit synchronization from RADV. I will talk about how we used implicit sync previously including the hacks we had to make it not terrible, then I will discuss why I'm trying to kill it and finally I will talk about how we are moving over to explicit sync.

        This will not cover user mode fences or getting more windowing systems to use explicit synchronization.

        Speaker: Bas Nieuwenhuizen (RADV)
      • 09:45
        Explicit Synchronization for Linux Display Servers 20m

        Current Linux display server architecture is based on the assumption that memory access by direct rendering devices is implicitly synchronized by the kernel. There is a growing consensus in the community that this has inherent limitations for both performance and functionality. This talk will discuss current efforts towards moving to an explicit synchronization model across Wayland [1], X11 / Xwayland [2], and user-space graphics drivers, including some of the challenges posed, potential solutions, and expected benefits to the Linux graphics ecosystem.

        [1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90

        [2] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967

        Speaker: Erik Kurzinger
      • 10:05
        Break 30m
      • 10:35
        FEX-Emu: Mesa interactions in an emulated environment 45m

        FEX-Emu is an emulator for running x86 and x86-64 applications on AArch64.
        Running Mesa inside of this emulated environment is an interesting challenge that cross architure, ABI, and kernel API boundaries.

        A short primer on how FEX-Emu works then we will walk through the challenges of running video drivers on architectures that they were not originally designed for. What it means to run inside of an emulated environment from the mesa perspective. Then what we are doing for performance optimizations, debug improvements, and future endeavors.

        Challenges include:

        • IOCTL/DRM interface isn't the same between architectures
        • Virtual address space not being 47-bit
        • Jumping across architecture boundaries for thunks
        • Running 32-bit applications as a 64-bit process
        • Compiling AArch64 drivers for an x86/x86-64 environment
        Speaker: Ryan Houdek (FEX-Emu)
      • 11:30
        GFXReconstruct - a tool to capture and replay streams of Vulkan API calls 45m

        LunarG’s GFXReconstruct is a suite of tools for capturing streams of graphics API calls from running Vulkan applications, processing those streams in various ways, and replaying streams on live devices.

        GFXReconstruct 1.0 supports capturing 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 for bug reporting. The container format is API-agnostic and LunarG plans support for more APIs. A capture file contains all context to replay the captured API call stream and is stored compressed by default.

        In this session we’ll introduce GFXReconstruct 1.0. We’ll talk about how we develop gfxreconstruct and how we incorporate community contributions. We’ll show where to get it, how to install binaries, and also how to build it. 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 human-readable dump of those calls and how to replay the captured stream. We'll briefly review the other tools in the GFXReconstruct package too.

        LunarG is a software engineering consultancy specializing in 3D graphics software solutions and is an active developer and maintainer of Vulkan Ecosystem components such as the Vulkan Loader, Vulkan Validation Layer, GFXReconstruct, and the Vulkan SDK.

        Speaker: Brad Grantham (LunarG, Inc.)
      • 12:15
        Lunch break 1h 30m
      • 13:45
        Implementing the graphics pipeline on compute 45m

        Over the last decade or so, the GPU has gone from something of a
        nice-to-have feature to an absolute must, across a lot of industries. You
        can hardly boot a modern system without supporting Vulkan or OpenGL (ES).

        Technologies such as LLVMpipe has allowed us to emulate such hardware, at
        a significant performance and memory bandwidth loss. It's proven very
        useful for purposes such as bringing up new platforms before GPU support
        has been added, for instance. And it can be a great solution in some cases
        where the amount of data to process is low.

        But in some industries, the needs for compute-pipeline processing power
        greatly outweigh the needs for graphics-pipeline processing power. Yet
        most GPUs still have fixed function graphics-pipeline support, such as
        primitive assembly, rasterization, blending. Implementing these in
        hardware is a very time-consuming task, and can sometimes brings little
        benefit.

        For instance, a modern camera processor needs to perform heavy image
        processing algorithms, even though it might not have a display. In such
        cases, a GPU compute kernel is typically used.

        It should be entirely possible to implement a reusable graphics pipeline
        on top of the compute-pipeline, paving the way for simpler GPU designs
        while still remaining useful. Think of this approach as something like
        LLVMpipe, except generating compute shader kernels instead of CPU code.

        Implementing a compute-shader-only GPU is something that's much more
        feasible for new players, for instance for an initial open source GPU
        design.

        Speaker: Erik Faye-Lund (Collabora)
      • 14:40
        State of the X.org 20m

        Here I discuss the state of the X.org foundation!

        Speaker: Lyude Paul (Red Hat)
      • 15:00
        Break 30m
      • 17:00
        Closing session 20m
        Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)
    • 09:00 17:00
      WineConf

      Talks related to the Wine Project

      Convener: Jeremy White (CodeWeavers)
      • 09:05
        Wineconf - Soapbox 2 20m

        We will work through the remaining ad hoc issues

      • 09:30
        vkd3d-shader and the HLSL compiler 45m

        Within the vkd3d project, vkd3d-shader is the library that is responsible for converting shaders from one fromat to another. Since version 1.3 it gained (initial) support for Microsoft's HLSL (High Level Shader Language) and it is now used as a the workhorse behind Wine's D3DCompile() and D3DCompile2() functions.

        So let's see how vkd3d-shader works, how you can use it and how you can add support for what's missing (of course we didn't want to take all the fun from you).

        Speaker: Giovanni Mascellani (CodeWeavers, Debian)
      • 10:30
        What's New in Direct3D 45m

        A look at the new features and work that has gone into the Direct3D implementation in Wine (and some work related to the broader GPU ecosystem), including but not limited to: the Direct3D Vulkan backend, huge performance improvements, MoltenVK work and Mac support, WoW64 support, the HLSL compiler, and Direct3D 12 work.

        Speaker: Zeb Figura (CodeWeavers, Inc.)
      • 11:30
        Wine on macOS State of the Union 45m

        Wine on macOS has taken an interesting journey over the last several years, from the 2019 removal of 32-bit support in macOS 10.15 Catalina to the 2020 introduction of ARM64-based "Apple Silicon" Macs.

        I'd like to discuss how Wine has navigated these changes in the past, and
        the directions being taken for the future.

        Speaker: Brendan Shanks
      • 13:45
        MoltenVK 45m

        I will present a brief description of MoltenVK, and current development plans for the future.

        Speaker: Bill Hollings
      • 14:50
        ProtonDB: One Can Make A Difference 30m

        Join the creator of ProtonDB for a discussion about the origins of the site, its approach in design and development, and what role it may have in the future of Linux gaming.

        Speaker: buck defore
      • 15:25
        32 on 64 demo 20m

        Jacek will demo 32 on 64.

      • 16:00
        WineConf - Wrap up 1h

        We'll cover any missed topics, discuss next Wineconf, and say farewell.

    • 09:15 11:15
      Workshop
      • 09:15
        HDR KMS API Workshop 2h

        As a follow-up to the "HDR is Harder" talk I will lead a workshop. The goal will be to workshop a DRM/KMS API and try to arrive at a solution that most people are happy with and everyone can live with.

        In question are pre-, and post-blending (drm_plane) 1D LUTs, 3D (cubic) LUTs, matrices, and predefined transfer functions.

        Use cases will include things such as tone mapping, color space conversion, display color correction, etc.

        We will also discuss whether it makes sense to hard-code placement of these elements or allow drives to define a custom color pipeline in a way that is parseable by KMS clients.

        Speaker: Harry Wentland (AMD)
    • 15:15 17:00
      Lightning Talks II: Lightning talks II
      • 15:30
        Report on the Bare-Metal CI workshop 5m

        This lightning talk will summarize the discussions that happened during the Bare-Metal CI workshop.

        Speaker: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor)
      • 15:35
        HDR Workshop Summary 5m

        I will give a brief summary of the discussions we had in the HDR workshop this morning.

        Speaker: Harry Wentland (AMD)
      • 15:40
        Where's your OpenCL driver? 5m

        Between CLon12's NIR improvements and the new Rusticl frontend, Mesa is ready for conformant OpenCL. Many drivers support compute shaders. Extending to OpenCL should be easy.

        So where's your OpenCL driver?


        OpenCL from the perspective of a backend compiler developer.

        Speaker: Alyssa Rosenzweig (Collabora)
      • 15:45
        Uncovering DRM's KUnit test coverage 5m

        In this lightning talk, we'll have an idea of how much unit test coverage the DRM subsystem has. In the last couple of months, we've seen the conversion of selftests to KUnit tests, addition of new tests using KUnit, and also the development of unit tests for AMD's display driver. So it might be time to compare and see what we had before and what we have now.

        Speaker: Magali Lemes
      • 15:50
        Zink on Rusticl 5m

        boom, done

        Speaker: Karol Herbst (Red Hat, Nouveau)