• KDE Goals Update – June 2021

  With every recent Plasma update (and especially the just released version 5.22) the list of features that are X11 exclusive gets smaller and smaller.

  Conversely, many users may not be aware that the opposite is also happening: every day there are more features available on Wayland that cannot be found on X11!

  There are many resources available describing the security advantages of Wayland over X11, but the ageing protocol has some other shortcomings as well. For example, the last update we highlighted was the recently released VRR support in 5.22. Among other things, this enables an important use case for me: it allows each of my connected displays to operate at their highest refresh rate. I have a 144Hz main display, but occasionally I plug in my TV, which works at 60Hz. Because of limitations of X11, for everything to work, my main display needs to be limited to 60Hz when both of them are active. But not any more thanks to Wayland!

  While the KDE developers always try to bring new functionalities to all users, the above example shows that sometimes, either due to X11 limitations or for other reasons, feature parity will not be possible.

  [...]

  As announced on the community mailing list and the Goals matrix room, there was a meeting last Monday to discuss the way forward with the huge list of topics mentioned in the previous update.

  In the meeting, the conclusion was to start with the topics regarding the different platforms we support, as well as the automation of the build/release process of apps.

  Taking advantage of the upcoming Akademy, the topics will be discussed during the BoF sessions. Check out the schedule to see when you can attend! Also, don’t miss the “Creating Plasma Mobile apps” BoF!

  Of course, like the other Goal Champions, Aleix will have a talk on the first day of Akademy, don’t miss it!

• Mike Blumenkrantz: Suballocate Me

  There’s a lot that goes into this item. The post you’re reading now isn’t about to go so far as to claim that zink(-wip) is usable for gaming. No, that day is still far, far away. But this post is going to be the first step.

  To begin with, a riddle: what change was made to zink between these two screenshots?

  [...]

  A suballocator is a mechanism by which small blocks of memory can be suballocated out of larger one. For example, if I want to allocate an 64byte chunk of memory, I could allocate it directly and get my block, or I could allocate a 4096byte chunk of memory and then take 64bytes out of it.

  When performance is involved, it’s important to consider the time-cost of allocations, and so yes, it’s useful to have already allocated another 63 instances of 64bytes when I need a second one, but there’s another, deeper issue that’s also necessary to address, especially as it relates to gaming: 32bit environments.

  In a 32bit process, the amount of address space available is limited to 4GB, regardless of how much actual memory is physically present, some of which is dedicated to system resources and unavailable for general use. Any time a buffer or image is mapped by the driver in a process, this uses up address space in order to create an addressable region of memory that can be read or written to. Once all the address space has been used up, no other resources can be mapped, and it becomes impossible to continue normal operations.

• Zink OpenGL-On-Vulkan Hits Another "Massively Improved Performance" Milestone - Phoronix

  The Zink component to Mesa that provides a generic OpenGL implementation built atop the Vulkan API recently hit another "massively improved performance" milestone by Valve contractor Mike Blumenkrantz.

  Mike began work on a suballocator for Zink that is based on the Gallium3D auxiliary/pipebuffer code originally started by the RadeonSI Gallium3D driver. After making significant changes to that code, Zink's new suballocator implementation is showing off significant performance improvements in just shy of 700 lines of new code.

Intel's "Gen12" Xe Graphics should be performing marginally better with next quarter's Mesa 21.2 feature release for its open-source ANV Vulkan driver.

Merged today into Mesa 21.2-devel is an ANV driver improvement to reduce the tile and data cache flushing for Gen12. This in turn translates into small but measurable performance improvements across a variety of workloads.

Given the recent forum discussion stemming from the -O3 optimization level still too unsafe for the Linux kernel (in part due to older, buggy compilers) and some users wondering about the current -O2 versus -O3 compiler optimization level impact, here is a fresh round of reference benchmarks using GCC 11.1 on Fedora Workstation 33 looking at various optimization levels and optimizations tested on dozens of different application benchmarks to see the overall impact on performance.

With the recent optimization level discussions and not having done any thorough optimization level comparison tests and link-time optimization (LTO) testing of the recently released GCC 11, here is this Monday article for those interested in compiler optimizations.

• Old Motorola 68000 Systems Can Finally Move Away From Linux's Deprecated IDE Code - Phoronix

  Earlier this year was talk of Linux finally removing its legacy IDE subsystem that has been deprecated for years in favor of just maintaining the still-supported libata code for IDE support. The libata path is much better supported and matured for nearly two decades, but one of the holdouts was some Motorola 68000 series hardware -- like early Macintosh computers -- not being supported outside of the legacy context. That is finally set to change with Linux 5.14 so in turn the legacy IDE code will likely be able to be removed soon.

  The Motorola 68000 "m68k" series is still popular with some enthusiasts and found in early Apple Macintosh computers. Two m68k class drivers not having libata equivalents was one of the rare scenarios where the legacy IDE code within the Linux kernel is still used.

• HW News - Dell Class Action Lawsuit, NVIDIA DLSS on Linux, AMD x Samsung GPUs | GamersNexus - Gaming PC Builds & Hardware Benchmarks

  On top of the RTX 3080 Ti and 3070 Ti announcements, Nvidia also announced expanded DLSS support -- namely that DLSS is coming to Linux. Nvidia’s DLSS will be delivered through Steam’s Proton, a compatibility layer based on Wine, which Linux users have long relied on to play Windows games on Linux distros.

  Previously, Nvidia’s DLSS had two exclusive requirements: An RTX GPU and a Windows OS. It appears as if Nvidia is starting to take Linux gaming a bit more seriously, which also aligns with Valve’s previous declaration to better support Linux. Nvidia claims that DLSS support for Vulcan titles is coming later this month, and that support for DirectX games will come this fall.

• Panfrost Gallium3D Driver For Open-Source Arm Mali Graphics Now Has OpenGL ES 3.1 - Phoronix

  Merged today into Mesa 21.2-devel is OpenGL ES 3.1 support being exposed for the Panfrost Gallium3D driver that provides open-source Arm Mali graphics.

  Panfrost lead developer Alyssa Rosenzweig landed more than 100 patches today for Panfrost into Mesa Git. These 100+ commits in the single merge request amount to a wide variety of OpenGL conformance fixes.