시몽

Status update, January 2021

Hi all!

This month again, my main focus has been wlroots. I’ve focused on the internal renderer refactoring (the so-called “renderer v6"). A lot of the work has now been completed, and all backends now use the new interfaces under-the-hood. With the help of Simon Zeni, we’ve gotten rid of the remaining OpenGL-specific stuff from the backends. This means it’s now possible to start working on non-GL renderers! I’ve started to put together a Vulkan allocator, and Simon Zeni plans to work on a Pixman software renderer.

The work-in-progress Vulkan allocator uses VK_EXT_physical_device_drm, a Vulkan extension I’ve been working on to allow Wayland compositors to use Vulkan for rendering. I’ve implemented it for radv (Mesa’s Vulkan driver for AMD GPUs) and James Jones has been helping with a test suite patch.

While doing this, I’ve realized it causes some regressions on Nouveau, the open-source driver for NVIDIA GPUs. I’ve tracked down a bunch of bugs, and submitted a patch for one of them. The Nouveau folks have been very helpful, special thanks to Ilia Mirkin! They even went through the trouble of setting up Sway locally to reproduce and fix one of the Mesa bugs, and then sent a wlroots patch for a bug they’ve hit on the way. Note, I still have some multi-GPU-related Nouveau regressions to figure out, so not everything’s been ironed out yet.

Ilia Bozhinov has contributed xdg-foreign support to wlroots, so applications running in Flatpak should behave better when a dialog (like a file selection dialog) is opened. He also helped reviewing some of the DRM backend pull requests.

In other DRM-related news, I’ve continued sending some DRM documentation patches and I’ve improved drmdb. The main drmdb change is a performance improvement: I’ve been so far ignoring a performance bug by hiding it with a Varnish caching proxy (yes, it’s embarassing). drmdb deals with deeply-nested JSON documents: each “snapshot” is stored as a JSON file. Operations on that type of database are costly: I needed to open each file, parse the JSON blob, then decide what to do with it. Many pages show information coming from a lot of devices, thus took seconds to load.

For now, I’ve implemented a cache to keep the last few hundred used snapshots in memory instead of loading each of them from disk. This has greatly helped and I’ve been able to remove Varnish. I wonder if at some point I’ll need to improve this further. If anyone knows about a lightweight simple database for deeply nested objects that ideally can be embedded in a Go executable, I’m all ears.

I’ve also added some new features: the index page shows some stats, the snapshot page now contains links for properties & objects, and buttons to toggle some tree nodes (example). Maybe I’ll add some kind of syntax highlighting as well to make it more readable, ideas welcome!

Some of my other projects received some smaller updates too. minus added config reloading support to tlstunnel, soju now has an in-memory history buffer when the on-disk logs aren’t enabled, and gamja will automatically reconnect when the connection to the IRC server is lost. Aditionally, I’ve started the release process for Wayland 1.19, and I’ve released libdrm 2.4.104.

That’s all, see you next month!


Questions, comments? Please use my public inbox by sending a plain-text email to ~emersion/public-inbox@lists.sr.ht.

Articles from blogs I follow

Reverse-engineering the Mali G78

After a month of reverse-engineering, we’re excited to release documentation on the Valhall instruction set, available as a PDF. The findings are summarized in an XML architecture description for machine consumption. In tandem with the documentation, we’v…

via On Life and Lisp

Status update, July 2021

Hallo uit Nederland! I’m writing to you from a temporary workstation in Amsterdam, pending the installation of a better one that I’ll put together after I visit a furniture store today. I’ve had to slow a few things down somewhat while I prepare for this mov…

via Drew DeVault's blog

Updating the Go Memory Model

What changes should we make to Go's memory model? (Memory Models, Part 3)

via research!rsc

Generated by openring