Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Wayland 1.19 Released With Small Protocol Updates, Fixes

Filed under
Graphics/Benchmarks

Wayland 1.18 released back in February 2020 while now nearly one year later it's been succeeded by Wayland 1.19.

Even with one year passing, Wayland 1.19 is a very minor update over Wayland 1.18. That's part of the reason why they moved off timed releases in the first place was the core Wayland code and protocol being quite stable at this point: there is very little change. Most of the work remaining to get Wayland ready for production use across all workloads is on the compositor side with KDE Plasma's KWin seeing improvements, GNOME Shell + Mutter being in very good shape, etc. There is also the driver obstacle of the NVIDIA proprietary driver support at the moment not being ideal but improvements are pending there. That is all outside of the core Wayland code itself that is the protocol and key libraries.

Read more

Graphics: NVIDIA, AMD and Intel's Latest

Filed under
Graphics/Benchmarks

  • NVIDIA release the 460.39 Linux driver update, improved support for kernel 5.10+

    Ready for a new stable NVIDIA driver for Linux? There's a new one out now with added GPU support and some tidying up work done with bug fixes too.

  • AMD RDNA2 "Duty Cycle Scaling" Will Turn Off The GPU Under Heavy Load For Relief

    A new Radeon power management feature with RDNA2 graphics processors being exposed by the open-source Linux driver is Duty Cycle Scaling in the name of power/thermal management with a focus on low-power hardware.

    AMD graphics Duty Cycle Scaling is designed for "small power limit SKUs" and is designed to actually shut off the graphics core and power it back up based on current/power/temperature thresholds. Under heavy workloads, the AMD "DCS" functionality controlled by the graphics firmware will power down the GPU during heavy load scenarios for power/thermal relief before being powered back up to resume work.

  • Linux 5.12 Bringing VRR / Adaptive-Sync For Intel TIger Lake / Xe Graphics - Phoronix

    Finally with the upcoming Linux 5.12 cycle is support for Variable Rate Refresh (VRR) / Adaptive-Sync for Intel Tiger Lake "Gen12" Xe Graphics and newer. 

    The VRR/Adaptive-Sync support for the latest-generation Intel graphics with Tiger Lake and the likes of the forthcoming Rocket Lake, Alder Lake, and discrete DG1 graphics is now in order for the mainline kernel. The VRR enabling for Tiger Lake and newer was sent in this morning to DRM-Next ahead of the Linux 5.12 kernel. This effort has been going on for many months while now has reached the stage that it's ready for merging. 

  • Intel Iris Xe Discrete Card Will Only Work With Select CPUs and Motherboards

    These motherboards require a special BIOS that supports Intel Iris Xe, so the cards won’t be compatible with other systems.

AMD Schedutil vs. Performance Governor Benchmarks On Linux 5.11 Shows More Upside Potential

Filed under
Graphics/Benchmarks

With a pending patch, the Linux 5.11 AMD Zen 2 / Zen 3 performance is looking very good as far as the out-of-the-box performance is concerned when using Schedutil as is becoming the increasingly default CPU frequency scaling governor on more distributions / default kernels. With the previously noted Linux 5.11 regression addressed from when the AMD CPU frequency invariance support was first introduced, the Schedutil performance from small Ryzen systems up through big EPYC hardware is looking quite good. But how much upside is left in relation to the optimal CPU frequency scaling performance with the "performance" governor? Here is a look at those benchmarks on Ryzen and EPYC for Schedutil vs. Performance on a patched Linux 5.11 kernel.

Read more

Graphics: Iris Xe, NVIDIA, VKD3D-Proton, Gallium/Zink

Filed under
Graphics/Benchmarks

  • Intel Announces Iris Xe Desktop Graphics For OEMs

    Intel today announced Iris Xe (DG1) discrete graphics cards are coming to OEMs with ASUS and Colorful being among the initial partners.

    The initial Iris Xe desktop graphics cards feature 80 execution units and a 30 Watt TDP. This is not the high-end, high performance desktop graphics but seems to largely be the Xe MAX discrete laptop graphics (but with 16 less EUs) now fitted for PCI Express cards for the desktop. The OEM cards are expected to feature 4GB of LPDDR4X memory. Other details are still light.

  • Nvidia Gets Certifiable About Systems

    If the emergence of Nvidia in datacenter compute shows anything, it is the value of controlling the software stack as you come to dominate the compute – and the revenue and profits – in the hardware stack.

    When it comes to AI, the combination of open source frameworks from the wider AI community, which Nvidia contributes to, and closed source libraries and tools that make up the Nvidia GPU Compute software stack that is underpinned by the CUDA environment, gives Nvidia the kind of control over a complete software/hardware stack that we have not seen in the datacenter since the RISC/Unix server days of the dot-com boom and earlier with proprietary systems from IBM, DEC, and HP, as well as IBM mainframes since the dawn of the data processing age.

    There are some differences this time around, and they are significant. The operating system is consequential, of course, but with all AI workloads being deployed on Linux, it really doesn’t matter which one you pick. Linux is about as interchangeable as DRAM memory modules in the server and it really comes down to preferences and a few technical differentiations. And to a certain extent, the X86 server that houses the Nvidia GPUs is fairly interchangeable, too. But fi you want to make GPU compute fluid and easy, then you have to realize that not every can – or wants to – buy an Nvidia DGX-A100 or DGX-2 system. Hyperscalers and cloud builders have their own ODM suppliers, enterprises have their own OEM suppliers, and they want to be able to run the Nvidia AI stack on platforms from their suppliers rather than having to add a new vendor into the mix.

  • NVIDIA 460.39 Linux Driver Brings RTX 30 Laptop Enablement, Improved 5.10+ Kernel Support

    NVIDIA has released 460.39 as their latest stable Linux proprietary graphics driver build.

    With this latest NVIDIA 460 series driver is support now for the RTX 3060 / RTX 3070 / RTX 3080 laptop GPUs as well as for the low-end GeForce GT 1010.

  • VKD3D-Proton begins work to support DirectX Raytracing on Linux | GamingOnLinux

    There's a few mountains that Steam Play Proton still needs to climb over the next few years, to enable more Windows games and more features in those games to work under Linux. One big one is at least in progress.

    Ray Tracing being one of the big things in gaming tech now, thanks to both AMD and NVIDIA having Ray Tracing cards out in the wild. With that, we can expect more games to begin using it.

    Thankfully, VKD3D-Proton, which is the Valve-funded fork of vkd3d to work with Direct3D 12 has a Pull Request open with the start of the work towards supporting Ray Tracing. Keep in mind though, while exciting for Steam Play Proton users, this is far from complete and not enabled directly for games as of yet as stated in the PR "Don't expose any features to app yet, but allow overriding FL to 12.2 for local testing while bringing up DXR.".

  • Mike Blumenkrantz: Samplin

    The goal in this post is to migrate a truckload block of code I wrote to handle sampler updating out of zink and into Gallium, thereby creating several days worth of rebase work for myself but also removing a costly codepath from the driver thread.

    The first step in getting sampler creation to work right in zink is getting Gallium to create samplers with the correct filters in accordance with Chapter 42 of the Vulkan Spec:

    VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT specifies that if VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT is also set, an image view can be used with a sampler that has either of magFilter or minFilter set to VK_FILTER_LINEAR, or mipmapMode set to VK_SAMPLER_MIPMAP_MODE_LINEAR. If VK_FORMAT_FEATURE_BLIT_SRC_BIT is also set, an image can be used as the srcImage to vkCmdBlitImage2KHR and vkCmdBlitImage with a filter of VK_FILTER_LINEAR. This bit must only be exposed for formats that also support the VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT or VK_FORMAT_FEATURE_BLIT_SRC_BIT.

    If the format being queried is a depth/stencil format, this bit only specifies that the depth aspect (not the stencil aspect) of an image of this format supports linear filtering, and that linear filtering of the depth aspect is supported whether depth compare is enabled in the sampler or not. If this bit is not present, linear filtering with depth compare disabled is unsupported and linear filtering with depth compare enabled is supported, but may compute the filtered value in an implementation-dependent manner which differs from the normal rules of linear filtering. The resulting value must be in the range [0,1] and should be proportional to, or a weighted average of, the number of comparison passes or failures.

Graphics: GPUOpen, Vulkan, and NVIDIA

Filed under
Graphics/Benchmarks
  • AMD Celebrates Five Years Of GPUOpen

    Today marks five years since AMD began the GPUOpen initiative for providing more open-source Radeon GPU code projects, code samples, and more for better engaging GPU/game developers in the open.

    As any longtime Phoronix reader will know, AMD's open-source Linux driver initiative is going on for more than a decade while the celebration today is just over their GPUOpen initiative turning five years old. The three principles that continue to guide GPUOpen are providing code and documentation to PC developers to exert more control on the GPU, a commitment to open-source software, and a collaborative engagement with the developer community.

  • Vulkan 1.2.168 Released With Two New Extensions

    Today's Vulkan 1.2.168 specification update brings the usual specification corrections/clarifications while also introducing two new KHR extensions.

  • VKD3D-Proton Begins Working On DirectX 12 Ray-Tracing Atop Vulkan

    Those working on VKD3D-Proton as the Direct3D 12 implementation atop the Vulkan API are beginning to work on DirectX Ray-Tracing support but it isn't yet ready for gamers.

    Hans-Kristian Arntzen has opened the initial pull request for enabling ray-tracing extensions with VKD3D-Proton.

  • NVIDIA release the Vulkan Beta Driver 455.50.03, new extensions supported

    Need to be on the bleeding edge of what NVIDIA have to offer? They just released driver version 455.50.03, as part of their Vulkan Beta Driver series. This is actually the second driver released this month, with 455.50.02 appearing on January 19. Here's a look over all that's new in them together.

Patched Linux 5.11 Continues Looking Great For AMD Ryzen/EPYC Performance

Filed under
Graphics/Benchmarks

While the initial AMD Linux 5.11 performance regression written about at the end of last year was of much concern given the performance hits to AMD Zen 2 / Zen 3 processors with the out-of-the-box "Schedutil" governor, with a pending patch the regression is not only addressed but in various workloads we continue seeing better performance than even compared to Linux 5.10. Here is the latest from several more days of extensive performance testing.

Read more

Nouveau X.Org Driver Sees First Release In Two Years

Filed under
Graphics/Benchmarks

Two years and nine patches later, xf86-video-nouveau 1.0.17 is out as the latest X.Org driver update for this open-source NVIDIA driver component.

Like the other DDX drivers with the exception of the generic xf86-video-modesetting driver that is quite common now to those still running on X.Org with the open-source stack, xf86-video-nouveau seldom sees new activity. Since the prior v1.0.16 release two years ago there has been less than a dozen patches for it. The interesting activity happens in DRM/KMS kernel space and an increasing number of users are just relying upon xf86-video-modesetting over these hardware-specific X.Org user-space drivers.

Read more

Graphics: OpenGL, Intel and Zink

Filed under
Graphics/Benchmarks
  • More OpenGL Threading Improvements Land For Mesa 21.1 - Phoronix

    Even in 2021 longtime open-source AMD Mesa driver developer Marek Olšák isn't done optimizing OpenGL for delivering the best possible performance with the Radeon graphics driver. Marek's latest work includes more OpenGL threading enhancements and other work seemingly targeted at SPECViewPerf workloads.

    Marek has spent the past several weeks working to remove the last OpenGL threading synchronization stalls that happen with SPECViewPerf 13. As part of this latest pull request he added support to glthread for executing display lists asynchronously. Plus there are some other OpenGL code improvements too.

  • More Intel Graphics Work In Linux 5.12: Gen7 Improvements, Faster Suspend/Resume

    New feature material for Linux 5.12 continues getting ready ahead of the merge window opening in February to formally kick off the cycle.

    On top of the prior Intel graphics driver improvements queued up in recent weeks to DRM-Next, another batch of Intel updates were sent out this week.

  • Zink OpenGL On Vulkan Now Supports OpenGL 4.2 With Mesa 21.1

    Going back to last summer there have been patches experimentally taking Zink as far as OpenGL 4.6 albeit it's been a lengthy process getting all of the relevant patches upstreamed. Additionally, some patches have required reworking or proper adjustments after going through the conformance test suite to ensure they are up to scratch for merging. Thanks to that ongoing effort by Mike Blumenkrantz working under contract for Valve and the work by Collabora developers, it was a quick jump this month from seeing OpenGL 4.1 to OpenGL 4.2 in mainline.

  • Mike Blumenkrantz: Itshappening.gif

    I meant to blog a couple times this week, but I kept getting sidetracked by various matters. Here’s a very brief recap on what’s happened in zinkland over the past week.

  • Zink OpenGL-On-Vulkan vs. RadeonSI OpenGL Performance As Of January 2021 - Phoronix

    With the Zink OpenGL-on-Vulkan implementation within Mesa on a nice upward trajectory with most recently now having the backing of a Valve contract developer and a focus on getting the backlog of patches to this Gallium3D code upstreamed, here are some fresh benchmarks looking at where the performance currently stands when using Zink atop the RADV Vulkan driver compared to using the native RadeonSI driver with this round of testing from a Radeon RX 5700 XT graphics card.

Zink OpenGL-On-Vulkan vs. RadeonSI OpenGL Performance As Of January 2021

Filed under
Graphics/Benchmarks

With the Zink OpenGL-on-Vulkan implementation within Mesa on a nice upward trajectory with most recently now having the backing of a Valve contract developer and a focus on getting the backlog of patches to this Gallium3D code upstreamed, here are some fresh benchmarks looking at where the performance currently stands when using Zink atop the RADV Vulkan driver compared to using the native RadeonSI driver with this round of testing from a Radeon RX 5700 XT graphics card.

Read more

Linux Kernel Space and Graphics: Linux Memory Management, Dbus-Broker 26, Vulkan Wayland Compositors

Filed under
Graphics/Benchmarks
Linux
  • The Maple Tree, A Modern Data Structure for a Complex Problem

    The Linux Memory Management layer supports the very common technique of virtual memory. Linux splits blocks of virtual memory into areas specified by the c structure vm_area_struct. Each vm_area_struct contain information associated with mapped memory and are used to find the associated pages of memory which contain the actual information. Virtual memory areas (VMAs) could be the contents of a file on disk, the memory that contains the program, or even the memory the program uses during execution. Literally everything that is run on Linux uses vm_area_struct for memory mapping. This vital area of the kernel needs to be quick and avoid contention whenever possible.

  • Dbus-Broker 26 Released For High Performance D-Bus

    With the BUS1 in-kernel IPC not panning out and not seeing any major code work in nearly two years, the user-space based, D-Bus compatible DBus-Broker remains the performant and current option for those looking at something faster and more reliable than D-Bus itself.

  • Vulkan Wayland Compositors Are Nearing Reality - Phoronix

    One of the last pieces of the puzzle for supporting an entirely Vulkan-based Wayland compositor is coming together with a new extension that looks like it will be merged soon and there already being work pending against Sway/WLROOTS to make use of the Vulkan path.

    The VK_EXT_physical_device_drm extension to Vulkan has been in the works for a number of months and is for allowing the mapping of Vulkan physical devices and DRM nodes. VK_EXT_physical_device_drm allows for querying DRM properties for physical devices and in turn matching the with DRM nodes on Linux systems.

  • Mesa's R600 Driver Nears Feature Complete NIR Support For Radeon HD 5000/6000 Series - Phoronix

    For those still making use of pre-GCN AMD graphics cards supported by the R600 Gallium3D driver (namely the Radeon HD 5000/6000 series), the open-source "R600g" Gallium3D driver now has nearly feature complete NIR support.

    Gert Wollny has been near single handedly working on NIR support for the R600g driver to make use of this modern graphics driver intermediate representation as an alternative to the long-standing Gallium3D TGSI IR.

Syndicate content

More in Tux Machines

EasyOS Dunfell 2.6.1 released for x86_64 PC

Yesterday announced EasyOS Dunfell 2.6.1 aarch64 for the Raspberry Pi4: https://bkhome.org/news/202101/easyos-dunfell-261-released-for-the-raspberry-pi4.html Today it is the turn for EasyOS Dunfell-series 2.6.1 64-bit on the PC. This is the first official release in this series. Same packages compiled in OpenEmbedded. Latest SeaMonkey 2.53.6. A different kernel for the PC build, 5.10.11. Read all about it here: http://distro.ibiblio.org/easyos/amd64/releases/dunfell/2.6.1/release-notes-2.6.1.htm As stated in the release notes, all three streams are being sync'ed to the same version number. The Buster-series 2.6.1 will probably be uploaded tomorrow. I have to compile the latest 5.4.x kernel, and SeaMonkey 2.53.6. As to which you would choose for the PC, it is like asking "which is better, strawberry icecream or chocolate icecream?" Read more

Top 20 Uses of Linux

The Linux OS and its related distros and flavors have transformed it from hardcore software into an industrial brand. Even if you are not a fan of it, the Linux OS might be as common as the air you breathe if you closely analyze your day to day interactive activities. Almost all the modern technologies that transform and innovate the tech industry have a Linux OS DNA imprinted on them. Those that are yet to be branded with their innovative uniqueness and recognition are waiting in line for the famed chance. Therefore, you might boldly claim that the Linux OS does not run your life, but the world around you cannot avoid the flirty pursuits of this open-source and free software. Nowadays, almost anything that can be described as cool is either pursuing Linux or is being pursued by Linux. It is the perfect symbiotic relationship in a world that tries to find a balance in technology and innovation. This article explores the awesomeness and outreach of the Linux OS in the world around us. It might even be an eye-opener for some of us to start taking our Linux skills to the next level. Top500 quotes Linux as the powerhouse or engine behind five-hundred fastest computers worldwide. I do not know of the speed of the computer composing this article or whether it qualifies to be among the listed five-hundred fastest computers worldwide. However, one thing is certain; it is 100% Linux DNA. On this note, let us start parading the top 20 uses of Linux. Read more

parted-3.4 released [stable]

Parted 3.4 has been released.  This release includes many bug fixes and new features. 
Here is Parted's home page: 
    http://www.gnu.org/software/parted/ 
For a summary of all changes and contributors, see: 
  https://git.savannah.gnu.org/cgit/parted.git/log/?h=v3.4 
or run this command from a git-cloned parted directory: 
  git shortlog v3.3..v3.4 (appended below) 
Here are the compressed sources and a GPG detached signature[*]: 
  http://ftp.gnu.org/gnu/parted/parted-3.4.tar.xz 
  http://ftp.gnu.org/gnu/parted/parted-3.4.tar.xz.sig 
Use a mirror for higher download bandwidth: 
  https://www.gnu.org/order/ftp.html 
[*] Use a .sig file to verify that the corresponding file (without the 
.sig suffix) is intact.  First, be sure to download both the .sig file 
and the corresponding tarball.  Then, run a command like this: 
  gpg --verify parted-3.4.tar.xz.sig 
If that command fails because you don't have the required public key, 
then run this command to import it: 
  gpg --keyserver keys.gnupg.net --recv-keys 117E8C168EFE3A7F 
and rerun the 'gpg --verify' command. 
This release was bootstrapped with the following tools: 
  Autoconf 2.69 
  Automake 1.16.1 
  Gettext 0.21 
  Gnulib v0.1-4131-g252c4d944a 
  Gperf 3.1 
Read more

Kernel: LWN's Latest and IO_uring Patches

  • Resource limits in user namespaces

    User namespaces provide a number of interesting challenges for the kernel. They give a user the illusion of owning the system, but must still operate within the restrictions that apply outside of the namespace. Resource limits represent one type of restriction that, it seems, is proving too restrictive for some users. This patch set from Alexey Gladkov attempts to address the problem by way of a not-entirely-obvious approach. Consider the following use case, as stated in the patch series. Some user wants to run a service that is known not to fork within a container. As a way of constraining that service, the user sets the resource limit for the number of processes to one, explicitly preventing the process from forking. That limit is global, though, so if this user tries to run two containers with that service, the second one will exceed the limit and fail to start. As a result, our user becomes depressed and considers a career change to goat farming. Clearly, what is needed is a way to make at least some resource limits apply on per-container basis; then each container could run its service with the process limit set to one and everybody will be happy (except perhaps the goats).

  • Fast commits for ext4

    The Linux 5.10 release included a change that is expected to significantly increase the performance of the ext4 filesystem; it goes by the name "fast commits" and introduces a new, lighter-weight journaling method. Let us look into how the feature works, who can benefit from it, and when its use may be appropriate. Ext4 is a journaling filesystem, designed to ensure that filesystem structures appear consistent on disk at all times. A single filesystem operation (from the user's point of view) may require multiple changes in the filesystem, which will only be coherent after all of those changes are present on the disk. If a power failure or a system crash happens in the middle of those operations, corruption of the data and filesystem structure (including unrelated files) is possible. Journaling prevents corruption by maintaining a log of transactions in a separate journal on disk. In case of a power failure, the recovery procedure can replay the journal and restore the filesystem to a consistent state. The ext4 journal includes the metadata changes associated with an operation, but not necessarily the related data changes. Mount options can be used to select one of three journaling modes, as described in the ext4 kernel documentation. data=ordered, the default, causes ext4 to write all data before committing the associated metadata to the journal. It does not put the data itself into the journal. The data=journal option, instead, causes all data to be written to the journal before it is put into the main filesystem; as a side effect, it disables delayed allocation and direct-I/O support. Finally, data=writeback relaxes the constraints, allowing data to be written to the filesystem after the metadata has been committed to the journal. Another important ext4 feature is delayed allocation, where the filesystem defers the allocation of blocks on disk for data written by applications until that data is actually written to disk. The idea is to wait until the application finishes its operations on the file, then allocate the actual number of data blocks needed on the disk at once. This optimization limits unneeded operations related to short-lived, small files, batches large writes, and helps ensure that data space is allocated contiguously. On the other hand, the writing of data to disk might be delayed (with the default settings) by a minute or so. In the default data=ordered mode, where the journal entry is written only after flushing all pending data, delayed allocation might thus delay the writing of the journal. To assure data is actually written to disk, applications use the fsync() or fdatasync() system calls, causing the data (and the journal) to be written immediately.

  • MAINTAINERS truth and fiction

    Since the release of the 5.5 kernel in January 2020, there have been almost 87,000 patches from just short of 4,600 developers merged into the mainline repository. Reviewing all of those patches would be a tall order for even the most prolific of kernel developers, so decisions on patch acceptance are delegated to a long list of subsystem maintainers, each of whom takes partial or full responsibility for a specific portion of the kernel. These maintainers are documented in a file called, surprisingly, MAINTAINERS. But the MAINTAINERS file, too, must be maintained; how well does it reflect reality? The MAINTAINERS file doesn't exist just to give credit to maintainers; developers make use of it to know where to send patches. The get_maintainer.pl script automates this process by looking at the files modified by a patch and generating a list of email addresses to send it to. Given that misinformation in this file can send patches astray, one would expect it to be kept up-to-date. Recently, your editor received a suggestion from Jakub Kicinski that there may be insights to be gleaned from comparing MAINTAINERS entries against activity in the real world. A bit of Python bashing later, a new analysis script was born.

  • Experimental Patches Allow For New Ioctls To Be Built Over IO_uring

    IO_uring continues to be one of the most exciting technical innovations in the Linux kernel in recent years not only for more performant I/O but also opening up other doors for new Linux innovations. IO_uring has continued adding features since being mainlined in 2019 and now the newest proposed feature is the ability to build new ioctls / kernel interfaces atop IO_uring. The idea of supporting kernel ioctls over IO_uring has been brought up in the past and today lead IO_uring developer Jens Axboe sent out his initial patches. These initial patches are considered experimental and sent out as "request for comments" - they provide the infrastructure to provide a file private command type with IO_uring handling the passing of the arbitrary data.