Language Selection

English French German Italian Portuguese Spanish

Kernel: AMX, OpenZFS, and AMDGPU

Filed under
Graphics/Benchmarks
Linux
  • Intel AMX Support Appears Ready For Linux 5.16 - Phoronix

    It's been over one year since Intel disclosed Advanced Matrix Extensions and began posting patches for bringing up AMX support under Linux in anticipation of Xeon Scalable "Sapphire Rapids" processors. While the compiler-side work to GCC and LLVM/Clang has been landing, finally with the forthcoming Linux 5.16 cycle that AMX support appears ready for landing.

    Merged today to tip/tip.git's "x86/fpu" branch where kernel FPU changes are queued ahead of the next merge window, the last of the AMX enablement patches were queued up. Most notably, the work for actually enabling the AMX feature and being able to expose it to user-space via the new interface.

  • BLK-MQ Support For OpenZFS Pending As Latest Performance Optimization

    A new pull request is pending for implementing multi-queue block (blk-mq) support within OpenZFS' Zvol code, which can lead to sizable performance benefits.

    Tony Hutter opened up the pull request at the end of last week for blk-mq support. Utilizing blk-mq allows for queuing and submitting I/O requests to block devices simultaneously. With modern multi-core CPUs and speedy storage devices, BLK-MQ can lead to very real benefits.

  • AMDGPU DP 2.0 MST Support Sent In For DRM-Next - Phoronix

    AMDGPU changes already queued up in DRM-Next for Linux 5.16 brought initial code for DisplayPort 2.0 ahead of next-gen GPUs with this connectivity support. Sent out today as a separate pull request is wiring up the DisplayPort 2.0 Multi-Stream Transport (MST) capability for the AMDGPU kernel driver.

    Sent in as a late topic branch is the AMDGPU DP 2.0 MST support along with a necessary change to the DRM common DisplayPort MST helper code. Multi-Stream Transport allows for multiple independent displays to be driven from a single DisplayPort output, AMDGPU has supported DP MST for DisplayPort 1.x, but additional changes are needed for DP 2.0 compatibility.

More in Tux Machines

Infrastructure living the ideals of software freedom

Can organisations with limited resources be digitally sovereign and still provide modern services? It is not trivial, but the FSFE proves it's possible. Take a deep dive with us into our infrastructure to learn how we run all the different services within the FSFE and cope with numerous challenges. A story non only for techies. Charity, non-profit organisations run into limits every day: personnel, budget, time, and the pressing question how to use donations most efficiently. When it comes to technical infrastructure, many organisations unfortunately decide to outsource and use proprietary, non-free services. By this, they give up software freedom and thereby digital sovereignty and independence. Since its founding more than 20 years ago, the FSFE has been pursuing the opposite way. Right from the start, we have relied on Free Software although it sometimes meant not being able to use and offer trendy services. Also, given the limited resources, we constantly have to choose between useful features and maintainability. Read more

Ubuntu Frame - A picture is worth a thousand snaps

The development of graphical applications intended for use on IoT devices isn’t trivial. The complexity goes beyond the usual challenges that exist in the classic desktop and server domains. One, the IoT world is much less mature. Two, developers need to take into consideration various edge cases that do not apply to hands-on devices like laptops, for instance. Kiosks, industrial displays and digital signage devices require additional focus and rigor. Ubuntu Frame is a solution designed to simplify and streamline the build and development of products that need graphical output. On a technical level, it is a fullscreen shell, based on Wayland, intended for interactive usage applications. On a product level, Ubuntu Frame bundles communication protocols, input protocols and security policies into a single kit, which can then be used in IoT devices. You can test it today. Read more

LoRa HAT starts at $31

SB Components is crowdfunding a $31-and-up “LoRa HAT for Raspberry Pi” with a 5-Km range at 868MHz or 433MHz. There is also a $47 “LoRa Expansion for Pico” board with a pre-soldered RPi Pico. Raspberry Pi milliner SB Components, which is behind such RPi HATs as the PiFinger fingerprint sensor HAT, has won Kickstarter funding for a simple, low-cost LoRa communications HAT. The LoRa HAT for Raspberry Pi is still available in a super early bird special for 23 UK Pounds ($31), as well as an identical 30-Pound ($40) package discounted from the eventual 40-Pound retail price. Read more

Preparing for PipeWire

In the coming year, PipeWire will replace PulseAudio resulting in better audio on Linux. If you can't wait, here's what you need to know to get started with PipeWire. Unless you use a version of Fedora released in 2021, you may not have heard of PipeWire. However, by this time next year, PipeWire will likely be installed on your computer. Already, many distributions are starting to carry PipeWire (marked as experimental) in their repositories. Still unfinished with its installation varied depending on distribution, PipeWire is about to replace PulseAudio as Linux’s main audio server. If you are unwilling to wait until PipeWire becomes a standard part of a Linux installation, here is what you should know. PipeWire was created by Wim Taymans of Red Hat in 2015. Based on an earlier project called PulseVideo, PipeWire was originally intended as a server for capture and playback of audio and video. The video side of the project is still in development, but the audio side is mature enough that in the spring of 2021 Fedora 34 become the first Linux distribution to install it by default. In Fedora 34, PipeWire is used to manage PulseAudio, JACK, ALSA, and GStreamer-based applications. Read more