Tag Archives: Linux Hardware

Debian Moves Closer To Voting On Proposals Over Init System Diversity


Following the decision by Debian Project Leader Sam Hartman to seek a general resolution over init system diversity and just how much Debian developers care about supporting systemd alternatives, the general resolution vote is moving closer.

The text is now laid out over three proposals drafted by Sam Hartman in weighing the importance of systemd / init system diversity by Debian developers.

The three choices include affirming init diversity, focusing on systemd but supporting the exploration of alternatives, and focusing on systemd for the init system and other facilities.

Ultimately this will decide whether Debian developers should still focus on making their distribution work outside of the systemd realm or if enough developers just want to focus on catering to a systemd workflow. This stems from months of conflict / limited resources over dealing with non-systemd bugs in the Debian space.

The proposals can be found via this Wiki page to mark the start of the discussion period followed by the voting.

AMD OverDrive Overclocking To Finally Work For Radeon Navi GPUs With Linux 5.5 Kernel


While most Linux gamers don’t appear to be into GPU overclocking, one of the limitations of the Radeon RX 5000 “Navi” series support with the AMD open-source driver to date has been no overclocking support. With the upcoming Linux 5.5 kernel that is set to change.

With the Linux 5.5 kernel there is slated to be the “OverDrive” overclocking support in place for Navi graphics processors with the AMDGPU kernel driver.

The Navi OverDrive support was sent in as part of Friday’s amdgpu drm-next-5.5 pull. In addition to the Navi overclocking there is fixed voltage handling for SMU7 hardware with custom power tables, power limit handling fixes for SMU11, properly stopping memory management worker threads on shutdown, and correct PCIe link reporting for Navi.

With there being no “Radeon Software Settings” or other official GUI control panel for the AMD Radeon graphics driver on Linux, the OverDrive GPU overclocking support for AMD graphics cards remains command-line based. The OverDrive Linux overclocking is done via reading and writing values to the respective sysfs interfaces. There have been third-party AMD Linux GUI control panel attempts but no official support in a number of years, but that’s something we can still cross our fingers and hope for a change in 2020.

The AMD Navi OverDrive overclocking support via sysfs is similar to the existing OverDrive support for Vega, Polaris, and prior on AMDGPU. Besides setting the frequencies, the support does allow editing the voltage curve for Navi 10 too.

Besides this Navi OverDrive support taking until months after the July launch to materialize for Linux users, making this support even more peculiar is that it was led by a seemingly independent developer. Matt Coffin who is an active Linux user but with no apparent affiliate to AMD was the one contributing the patches among his first upstream commits to AMDGPU.

Intel Spins Up Latest Graphics Compiler + Compute Runtime With Ice/Tiger Lake Work


The Intel developers working on their open-source compute run-time this morning released a new version as they continue making improvements to their Gen11 Ice Lake support as well as further bringing up the Gen12/Xe Tiger Lake support.

As part of the compute runtime is the Intel Graphics Compiler to which this morning they released IGC 1.0.2805. With this compiler update is a memory leak fix, an OpenCL fix, and minor fixes/improvements.

With the Intel Compute Runtime 19.45.14764 release they pulled in the new IGC, an updated GMMLIB is also included, 64-bit atomics are now enabled for Ice Lake and Tiger Lake, there is support for thread-group preemption on Tiger Lake GEN12LP, and updates to using a newer GMM (Graphics Memory Management Library) API. Of those changes the 64-bit atomics being flipped on for Ice Lake and Tiger Lake is most notable for this week’s Intel compute open-source work.

Overall the Intel Compute Runtime for Linux continues maturing as we approach Intel’s oneAPI beta release this quarter and next year the highly anticipated launch of their first Xe graphics card.

Zombieload V2 TAA Performance Impact Benchmarks On Cascade Lake

While this week we have posted a number of benchmarks on the JCC Erratum and its CPU microcode workaround that introduces new possible performance hits, also being announced this week as part of Intel’s security disclosures was “Zombieload Variant Two” as the TSX Async Abort vulnerability that received same-day Linux kernel mitigations. I’ve been benchmarking the TAA mitigations to the Linux kernel since the moment they hit the public Git tree and here are those initial benchmark results on an Intel Cascade Lake server.

While Intel’s latest-generation Cascade Lake server processors have hardware protections against other MDS vulnerabilities like RIDL and Fallout, they require software mitigations for Zombieload V2 / TAA. Researchers had disclosed this Zombieload variant back to Intel earlier in the year but was placed under an extended embargo and not revealed back during the original May disclosures.

Besides Cascade Lake, other Intel CPUs requiring the extra TAA mitigations are Whiskey Lake and Coffeelake-R processors — at least those where Intel TSX (Transactional Synchronization Extensions) are supported. Those wanting to learn more about all of the intracices of Zombieload V2 / TSX Async Abort can see ZombieloadAttack.com and the Intel Deep Dive. For your viewing pleasure in this article are the initial Cascade Lake benchmarks following Linux’s TAA mitigations landing. Details on the Linux kernel’s TAA mitigations can be found via this documentation.

For this Cascade Lake testing, which is also believed to be the first public benchmarks of the TAA Linux mitigations anywhere, tests were done on a dual Intel Xeon Platinum 8280 server. The server platform in use was the Gigabyte S451-3R0 Xeon Scalable, kindly provided by Gigabyte.

During this benchmarking the server was running Ubuntu 19.10 with the Linux 5.4 Git kernel. Being compared in this article was the new TAA mitigations by default when TSX is enabled, the performance impact when disabling the mitigation (using the new tsx_async_abort=off switch), and the performance when simply disabling Intel TSX using the new tsx=off switch.

This article isn’t comparing the combined impact of the other speculative execution mitigations, the JCC Erratum, or any other combinations. Follow-up articles will be looking at the different combinations while for today is just seeing what this new TSX Async Abort code in the kernel presents. Also keep in mind for all these tests today SMP/HT was left enabled, but again the current no-HT performance is something that will be revisited in the future.

When firing up different benchmarks found to be impacted by the TAA mitigations, the geometric mean of those results pointed to the Cascade Lake server running just under 8% slower from the new kernel mitigation this week on affected workloads. Meanwhile disabling TSX and running TSX without any mitigations yielded similar performance.

Now let’s look at the individual benchmark results.

CodeWeavers Is Hiring Another Graphics Developer To Help With Wine D3D / Steam Play


CodeWeavers is looking to hire another developer to work on Wine’s graphics stack and in particular the WineD3D code while having an emphasis that it’s part of Valve’s Steam Play (Proton) efforts.

CodeWeavers’ new job post lays out all of the exciting elements of the job, “Recently we partnered with [Valve] Software to integrate Wine into the Steam for Linux client as a part of the Steam Play (Proton) initiative. This along with many other clients in the video game industry has increased our demand for developers with strong graphics development experience. You would be would be working on Wine’s Direct3D implementation—covering everything from early DirectDraw up until modern Direct3D 12, as well as other graphics APIs like Wine’s Vulkan, OpenGL and Direct2D implementations. Underlying API includes Vulkan and OpenGL on both Linux and macOS across different hardware configurations. There may be some compiler work on vkd3d-shader and/or d3dcompiler.

Qualified candidates would already be skilled at C programming and experienced with OpenGL / DirectX / Vulkan / Metal as well as being experienced in debugging. Those interested can learn more via LinkedIn jobs.

It’s great to see CodeWeavers continuing to invest in the Wine graphics code thanks to their contract with Valve. With more contributions recently going into VKD3D, the state of Direct3D 12 over Vulkan for Wine / Proton should be good as we move further into 2020. Exciting times ahead.