Wayland layer-shell protocol

As Wayland is increasingly getting hold in desktop and embedded systems and many discussions have settled, there wasn't much talk about Wayland on this year's conference.

Still Drew DeVault, maintainer of sway and the wlroots library, presented the layer shell protocol. This new Wayland protocol allows clients to specify their position and z-order in in relation to the remaining desktop and applications. Usually the compositor, e.g., Weston, Mutter or KDE, takes full care of implementing the desktop user interface by providing a specific shell. The layer shell allows users to extend and customize their desktops with additional applications without relying on the configuration means of the existing shell. Currently this protocol is used in sway to implement the wallpaper, lock screen, panel, and notification bar.

While the security of this protocol remains an open question, because it breaks the assumption that Wayland clients don't know anything about the desktop layout, wlroots is working towards adding the layer-shell protocol to the standard Wayland protocols.

The layer-shell could simplify the creation of GUIs for embedded systems in the same way it helps to write desktop application components. However, to be really interesting for embedded use cases, wlroot still needs more improvements in the drm-backend, especially proper use of hardware display overlays.

Heterogeneous memory management

On Thursday, a highlight was the talk by Jerome Glisse about the current state of heterogeneous memory management (HMM). HMM allows to synchronize the CPU page table and the device page table, and, thus, enables a shared address space between the CPU and devices and avoids relocations.

Additionally, HMM provides a unified interface to migrate memory between main memory and device memory, which allows device drivers to take advantage of separate device memory which has a higher bandwidth and lower latency than main memory. The interface still requires drivers to define the policy for the migration, because the conditions for optimal usage are highly device and use case specific.

My colleague Lucas Stach considered using HMM for implementing the reloc support for texture descriptors in etnaviv. This is still missing for support of the GC7000, which is, e.g., found on the i.MX8M. Unfortunately HMM requires that the device address space to be at least as large as the CPU address space, which is not the case for the 64 bit ARM cores on the i.MX8M, as the Vivante GPU only supports 32 bit addresses. The discussions lead to the decision to use per process address spaces to solve the reloc support on the GC7000. Stay tuned for news about GC7000 support in etnaviv.

OpenCL with Clover using SPIR-V and NIR

Friday started with a talk by Karol Herbst about OpenCL support inside Mesa through SPIR-V and NIR.

While the AMDGPU driver already supports OpenCL via its LLVM intermediate representation (IR), other drivers that don't use the LLVM IR for generating the machine code have a hard time supporting OpenCL. Adding means to use NIR as the general purpose IR within Mesa would enable all NIR-based drivers (currently Nouveau and freedreno) to benefit from Mesa OpenCL support.

Rob Clark, Pierre Moreau and Karol Herbst have been working on converting OpenCL C code into SPIR-V, which in turn can be translated into NIR. The talk covered which features are still missing in NIR and Clover for supporting OpenCL in NIR. Especially NIR is missing support for real pointers and various OpenCL specific opcodes and intrinsics and Clover lacks support for SPIR-V files and the conversion using the SPIRV-LLVM-Translator.

While there were patches for experimental NIR support in etnaviv, these haven't been merged into Mesa mainline yet. However, adding NIR support to etnaviv is essential for using this work to implement OpenCL in etnaviv.

Panfrost

Also on Friday, Lyude Paul and Alyssa Rosenzweig introduced their work on Panfrost, a reverse-engineered open source 3D driver for Mali GPUs. Mali is a GPU architecture by ARM, which is commonly found on embedded systems. The work is focused on the more recent Midgard (Txxx) and Bifrost (Gxx) series, which still leaves the older Utgard architecture something to avoid in maintainable systems.

Midgard is already supported by a prototype Mesa driver, which shows impressive results compared to the binary blob driver. Bifrost shares a kernel driver with Midgard, but the shader core has been completely changed. Although much of the ISA has been reverse-engineered, there is no Mesa support, yet.

Maybe with their work on the Mali GPUs, we might be able to start using SoCs that contain Mali GPUs for maintainable and updatable embedded systems.

Conclusion

Thanks to the X.Org Foundation and the GPUL (Galician Linux User Group) for organizing a great conference.