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

4 Oct 2022, 07:30 → 6 Oct 2022, 20:00 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)

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.

Tuesday, 4 October

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

Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)

09:00 Replacing the geometry pipeline with mesh shaders

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.)

mesh-shaders-2.odp

mesh-shaders-2.pdf

09:30 Mesh shading implementation in Mesa

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)

How mesh shaders are implemented in an AMD driver

Latex source for the slides

Mesh and task shaders intro and basics

Task shader driver implementation on AMD HW

xdc2022_mesa_mesh_shader_implementation.pdf

10:15 Break

10:45 How to write a Vulkan driver in 2022

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)

2022-10-04 XDC 2022.pdf

11:40 World's Slowest Raytracer

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)

slowest-raytracer.pdf

12:25 Lunch break

14:00 Tasting the Forbidden Apple

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

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)

pres.pdf

15:40 Break

16:10 KUnit sorcery and the uncanny nature of FPU in the DRM

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

2022-10-04-kunit-xdc-presentation (1).pdf

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

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

XDC_20220920_final.pdf

17:15 Post OpenGL: casual graphics development

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)

post-gl.pdf

17:20 Update on OpenChrome Project

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

Speaker: Mr Kevin Brace (Brace Computer Laboratory)

Update_on_OpenChrome_Project_XDC_2022.pdf

Wednesday, 5 October

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

Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)

08:45 introduction to isaspec

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)

XDC2022_ isaspec.pdf

09:15 Status of Vulkan on Raspberry Pi

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.)

v3dv-update-xdc2022.pdf

09:45 Enable hardware acceleration for GL applications without glamor on Xorg modesetting driver

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)

XDC-20220-DRI3-modesetting-without-glamor.pdf

10:05 Break

10:35 Rusticl: An OpenCL implementation written in Rust

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)

main.pdf

11:30 Introduction to DisplayPort MST support on Linux

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)

MST Presentation.pdf

11:50 Lunch break

13:20 "I'm not an AMD expert, but..."

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)

XDC2022_Im_not_an_AMD_expert_but.pdf

13:50 Is HDR Harder?

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)

2022 XDC Is HDR Harder.pdf

14:45 There are no dragons: porting fbdev drivers to DRM/KMS

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

xdc_2022_porting_fbdev_drivers_to_drm.pdf

15:30 Break

16:00 moar fps in a vm, with this one little trick

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)

XDC2022_ virtgpu drm native context.pdf

16:55 Async page flip in atomic API

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)

async_atomic_drm_xdc22.pdf

17:20 Runtime display switch implementation in a Linux DRM bridge subsystem

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

XDC2022 - DRM Bridge Switch.pdf

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

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

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

Speaker: Alexandre Julliard

wineconf-2022.pdf

09:45 Proton: What Lies Down the Stream?

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

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

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)

upstreaming-tips-wineconf-2022.pdf

14:20 Wine + GitLab

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

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

Speaker: Zeb Figura (CodeWeavers, Inc.)

staging2022-v2.odp

16:00 Wine Soapbox Session

17:50 → 18:50 X.Org Foundation board of directors meeting

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.

Thursday, 6 October

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

Speakers: Arkadiusz Hiler (CodeWeavers) , Jeremy White (CodeWeavers)

09:15 A step towards explicit synchronization

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)

A step toward explicit synchronization.pdf

09:45 Explicit Synchronization for Linux Display Servers

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

explicit_sync.pdf

10:05 Break

10:35 FEX-Emu: Mesa interactions in an emulated environment

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)

FEX-Emu - Interactions in an emulated environment - XDC 2022.pdf

Sizzle reel

11:30 GFXReconstruct - a tool to capture and replay streams of Vulkan API calls

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.)

GFXReconstruct 2022 XDC.pdf

12:15 Lunch break

13:45 Implementing the graphics pipeline on compute

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)

compute-gpu.fodp

terrible prototype

14:40 State of the X.org

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

Speaker: Lyude Paul (Red Hat)

State of the X.org - XDC 2022.pdf

15:00 Break

17:00 Closing session

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

We will work through the remaining ad hoc issues

09:30 vkd3d-shader and the HLSL compiler

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)

vkd3d-shader.pdf

10:30 What's New in Direct3D

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.)

d3d2022-v2.odp

d3d-script

11:30 Wine on macOS State of the Union

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

Wine on macOS State of the Union - WineConf 2022.pdf

13:45 MoltenVK

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

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

Jacek will demo 32 on 64.

16:00 WineConf - Wrap up

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

09:15 → 11:15 Workshop

09:15 HDR KMS API Workshop

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

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

Speaker: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor)

xdc2022-bare-metal-ci-workshop-notes.pdf

15:35 HDR Workshop Summary

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

Speaker: Harry Wentland (AMD)

2022 XDC Is HDR Harder - Lightning.pdf

15:40 Where's your OpenCL driver?

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

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

[Lightning Talk] Uncovering DRM's KUnit test coverage.pdf

15:50 Zink on Rusticl

boom, done

Speaker: Karol Herbst (Red Hat, Nouveau)