A couple years ago, Alyssa Rosenzweig developed a compute-based geometry and tessellation shader implementation for the Asahi (OpenGL) and Honeykrisp (Vulkan) drivers. Since then, the core of this implementation has been extracted into a common library within Mesa called libpoly. In this talk, Faith will talk about the changes needed to libpoly as well as panvk in order to integrate libpoly into panvk for geometry shader support on Mali GPUs.
This years update on the FOSDEM videobox!
FOSDEM is a massive event with 30 different tracks spread over two days. Our goal is to not only capture video of every talk, but also to fully live stream everything. In this talk, the current versions of the hardware and software powering this crazy endeavour will be presented.
In October 2023, when Raspberry Pi 5 was announced, a new version of Raspberry Pi OS based on Debian 12 Bookworm was released. After two years, in October 2025, the new release based on Debian 13 Trixie was released.
This talk will review what improvements have been made in the graphics stack of the Raspberry Pi, focusing on the kernel (v3d) and user space (v3d/v3dv) GPU driver upgrades.
Now all Trixie Raspberry Pi users are taking advantage of Mesa 25.0.7. It exposes Vulkan 1.3 and OpenGL 3.1 with significant performance improvements on Raspberry Pi 4/5.
We will also review what could be expected based on current and upcoming development cycles - from Mesa 25.0 to the latest upstream work - and how these advances improve the capabilities on the Raspberry Pi platform.
[1] https://www.mesa3d.org/ [2] https://www.raspberrypi.com/
Along the years, FOSDEM and its Graphics Devrooms have featured many talks about the status of different Mesa3D drivers. But what is Mesa3D? How did the project start? How is it structured?
This talk provides a comprehensive introduction to Mesa3D, aimed at people who have some graphics knowledge, but have never written a GPU driver. We will trace the project from its origins to being the industry standard for several vendors nowadays.
More specifically, we will cover its architecture and components, how it translates API calls from standards like Vulkan or OpenGL into hardware instructions, how the shader compilation process looks like, and various other topics.
Attendees will leave with a clear understanding of what happens behind the curtains when they invoke a draw command.
https://mesa3d.org/
With the sunsetting of Xorg based environments the need for bespoke window management experiences has not gone away. But a new approach is needed that fits the Wayland paradigm.
Mir is a library for building Wayland compositors that supports a wide range of projects with their own Window Management needs: 1. embedded displays with a single fullscreen app (Ubuntu Frame); 2. phones and tablets with multiple fullscreen or staged apps (Lomiri); 3. "floating" Desktop Environments (Lomiri and Miriway); and, 3. "tiling" Desktop Environments (Miracle-wm).
We will cover a range of topics including: 1. building a compositor with Mir and customizing the window management; 2. integration with Desktops Environments such as XFCE, LXQt, MATE and Budgie; and 3. the deployment in distributions (Fedora LXQt Spin and Fedora Miracle Window Manager Spin)
This talk introduces Tyr, a new Rust-based GPU driver for the Linux kernel. We’ll begin with a brief look at how modern GPUs work before diving into Arm’s GPU architecture and explain how it’s supported at the kernel level, highlighting the key components of a Linux GPU driver. We’ll conclude with an overview of the project’s current status and what’s ahead on the roadmap.
Like most window-system architectures, X is fundamentally event-driven. So why not use an API that reflects that?
This talk is about an X interface library which is built on event-driven paradigms from the ground up. It sits in the same place in the software stack as Xlib and xcb; it's an alternative to them for an application to use when talking to the X server, most appropriate for applications which are themselves event-driven.
Current Wayland compositor implementations handle window management and compositing in the same monolithic process. Wayland does not however force this architecture.
I am the author of the river Wayland compositor. It supports a custom Wayland protocol, river-window-management-v1, which allows a special "window manager" Wayland client to handle all window management policy, draw server side decorations, setup keybindings, and more.
My goal with this work is to make hacking on Wayland window managers significantly more accessible and promote ecosystem diversity. There is already a growing list of window managers developed for the new protocol.
This talk will give an overview of this new protocol and the advantages/disadvantages of separating the Wayland compositor and window manager. There will also be a brief demo.
I've added Vulkan to our game (0 A.D. https://play0ad.com/) in the beginning of 2023 and game version with its support was released in the beginning of 2025. Since that we've collected many different feedbacks and issues with Vulkan: our implementation, driver issues and hardware problems. I'm going to share most significant ones for us including device selection and creation, RPI visual artifacts, "remote" debugging and performance fluctuations.
Chinese or Korean style of text field switching? Synchronization or YOLO? text-input, input-method, virtual-keyboard?
This will be a summary of my work on problems in Wayland input (methods).
How to fix your Wayland problem? How to get your protocol accepted? Which projects will implement it? How long is it going to take?
Less about code, I will talk more about needs and people, based on my experiences over the past year.
Honestly, I'm the worst person to work on input methods. Why did no one kick me out from this sandbox yet?
Testing shader compilers is hard. There are many test suites available, but they primarily test simple shaders. As a result, the test suites have many coverage gaps. Testing real applications is necessary. It is impractical to test every application on every platform for every change to the compiler. As a proxy, the shaders from those applications can be compiled, and changes to the resulting shader code can be checked against various metrics. If the compiler itself is built with additional validation checks, functional regressions may also be detected. Hours might still be required to test a single change. This talk discusses software and hardware techniques to best utilize available computational resources for this testing.