Given the recent Intel presentation alleging AMD Ryzen laptop performance being worse on battery relative to the AC vs. battery performance seen with Intel EVO notebooks featuring Tiger Lake processors, I ran a mini comparison on my side to see whether there is any merit to Intel's information when testing under Ubuntu Linux.

Here is just some initial data on my side when benchmarking AMD Ryzen "Renoir" versus Intel Core i7 "Tiger Lake" when running Ubuntu 20.10 and comparing the AC power versus battery performance.

Last week we delivered AMD Radeon RX 6800 / RX 6800 XT Linux benchmarks and the performance was great both for Linux gaming as well as the OpenCL compute performance. But for as good as those Big Navi numbers were on the open-source Linux graphics driver stack, they are now even better.

That launch-day testing was based on the Linux state in the second-half of October when the cards arrived and initial (re-)testing began in preparing for the Radeon RX 6800 series reviews -- not only the Radeon RX 6800 series but re-testing all of the other AMD Radeon and NVIDIA GeForce graphics cards for the comparison too. Thanks to the rate of the open-source graphics driver progression and the newest code always being available, now just days after launch the numbers are even more compelling for Linux gamers with the slightly newer Linux 5.10 and Mesa Git compared to just weeks ago.

In particular were the last minute NGG fixes and other Big Navi tweaks along with an important Radeon RX 6800 (non-XT) fix. There has also been other RADV improvements and more that accumulated in Mesa 21.0-devel this month. On the kernel side, Linux 5.10 is still at play. Both the old and newer Mesa snapshots were also on LLVM 11.0.

Also: Intel: AMD Gimps On Battery-Powered Laptop Performance - But DPTF On Linux Still Sucks - Phoronix

In addition to squaring away the Radeon RX 6000 series RDNA 2 support and promoting the Arcturus support for the new GPU found within the AMD MI100 accelerator, this month AMD open-source Linux driver developers have been devoting a fair amount of work towards power optimizations.

With the many different DC display core patch series this month and other patches floating around, there has been seemingly a lot of work on optimizing the graphics power usage. And in particular a lot of work on the optimizations from the DCN3 (Display Core Next 3) perspective with Van Gogh in particular being a focus.

• Why eBPF is the Future of Linux and Cloud Native Networking

  For decades, IPtables has been the cornerstone of Linux networking, but that's no longer the case. Over the last few years, extended Berkeley Packet Filter (eBPF) has emerged as a better option for Linux whether it's running on-premises, or more likely than not, in the cloud.

  What eBPF provides is a low-level interface to enable data packet transmission and control. On its own it has tremendous potential for networking. While there is lots of open source eBPF code now in the Linux kernel, on its own, it can be quite complex, which is where the open source Cilium project has been making inroads in the last few years.

  I first wrote on Cilium in 2017, when the project first got started and the company behind it - Isovlanet - was still shrouded in stealth. Cilium and Isovalent are led by CEO and co-founder Dan Wendlandt, who helped to create the OpenStack Quantum networking project and was a pioneer in the Software Defined Networking (SDN) industry at VMware.

  Last week, Isovalent emerged from stealth, along with $29 million in funding led by Andreessen Horowitz. Wendlandt and Andreessen Horowitz are hardly strangers; after he left VMware in 2016 he went to work as a partner at the venture capital firm, alongside fellow SDN pioneer and VMware alum Martin Casado.

• [Mesa-dev] Intent to retire ancient driver support

  Sending this on to the list for visibility, since not everyone follows
  everything on gitlab. In this merge request:
  
  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660
  
  I retire support for DRI drivers older than Mesa 8.0, which was
  February 2012. In particular this retires the ability for libGL to
  even load DRI1 drivers, which last existed in Mesa 7.11. We are not
  aware of any currently supported distros trying to ship both DRI1
  drivers and anything newer. In fact the only distro I'm aware of that
  ever _tried_ was RHEL 6, which goes into extended-life support at the
  end of the month, and which is currently shipping Mesa 11.0.7 and is
  thus _way_ behind the times in terms of hardware enablement.
  
  Eric Anholt suggested that glvnd is the better way to retain DRI1
  support at this point, and to that end there is also:
  
  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7674
  
  Which allows us to override the glvnd vendor name. xserver could then
  select a different name for DRI1 screens, and now you get
  parallel-installable Mesa packages, which could be nice for a bunch of
  reasons.
  
  If you still care about DRI1 support, I am very sorry, but hopefully
  !7674 (backported to 20.x) and a bit of polish to xserver should keep
  things working for you, and your feedback/testing would be greatly
  appreciated.
  

• Mesa To Drop Support For Ancient Drivers - Phoronix

  The fallout should be minimal and hopefully not impact any Phoronix readers, but as Mesa rolls into 2021 it is looking to drop support for loading DRI1 graphics drivers.

  Back in 2011 the classic Radeon drivers were removed Adam Jackson of Red Hat is planning to remove the ability for Mesa's current libGL to be able to load DRI1 drivers. This is basically about trying to load old DRI1 drivers from Mesa pre-8.0 onto a system with the current Mesa libGL loader. Mesa has retained this ability for being able to load these classic DRI1 drivers but nearly nine years after old driver code was dropped from Mesa, phasing out this ability to load DRI1 drivers is now planned.

• Arcturus No Longer Experimental - AMD Instinct MI100 Linux Support Is Ready - Phoronix

  Being sent in as a "fix" this week to the Linux 5.10 kernel is removing the experimental flag for the Arcturus GPU, days after AMD announced the MI100 accelerator at SC20.

  Going back to the summer of 2019 there have been Linux graphics driver patches for "Arcturus" as an evolution of GFX9/Vega but with not a lot being known about it. Much work was poured into this open-source driver code for Arcturus and the Linux support all squared away over the past year. This week it finally entered the limelight in the form of the AMD Instinct MI100 accelerator.

• NVIDIA Is Working On Vulkan Support With RDMA Memory - Phoronix

  Well this will be interesting to see what NVIDIA use-case pans out... NVIDIA engineers are working on a Vulkan extension for making use of RDMA memory.

  Remote Direct Memory Access (RDMA) for zero-copy networking with high throughput and low latency is very common for cluster computing and other enterprise scenarios to allow direct memory access from one computer to another without the intervention of the CPU. NVIDIA now though is preparing to support RDMA memory usage in the Vulkan context.