Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Graphics: TuxClocker and VK_EXT_depth_clip_enable

Filed under
Graphics/Benchmarks
  • TuxClocker: Another GPU Overclocking GUI For Linux

    Adding to the list of third-party GPU overclocking utilities for Linux is TuxClocker, a Qt5-based user-interface currently with support for NVIDIA graphics cards and experimental support for AMD GPUs. 

    TuxClocker is a Qt5 overclocking tool that supports adjusting not only the memory/core frequencies but also the power limit, fan speed, and other tunables based upon the GPU/driver in use. There is also graph monitors to show the power and temperature limit, where supported, among other features. 

    TuxClocker offers similar functionality to other third-party, open-source Linux GPU overclocking software though where as most utilities focus just on NVIDIA or AMD hardware, TuxClocker is pursuing both. Currently their stable release supports just NVIDIA GPUs but the development code has AMD Radeon support in the works.

  • Intel Wires VK_EXT_depth_clip_enable Into Their Vulkan Driver, Helping DXVK

    Intel's open-source ANV Vulkan driver now supports the VK_EXT_depth_clip_enable that was designed in part to help the DXVK project for mapping Direct3D atop of the Vulkan API.

Extensive Benchmarks Looking At AMD Znver1 GCC 9 Performance, EPYC Compiler Tuning

Filed under
Graphics/Benchmarks

With the GCC 9 compiler due to be officially released as stable in the next month or two, we've been running benchmarks of this near-final state to the GNU Compiler Collection on a diverse range of processors. In recent weeks that has included extensive compiler benchmarks on a dozen x86_64 systems, POWER9 compiler testing on the Talos II, and also the AArch64 compiler performance on recent releases of GCC and LLVM Clang. In this latest installment of our GCC 9 compiler benchmarking is an extensive look at the AMD EPYC Znver1 performance on various releases of the GCC compiler as well as looking at various optimization levels under this new compiler on the Znver1 processor.

Read more

Graphics: RadeonSI Gets NIR Improvements, Enabled By Default For Civilization VI, Mesa 19 is Almost Ready, Now at Fifth RC

Filed under
Graphics/Benchmarks
  • RadeonSI Gets NIR Improvements, Enabled By Default For Civilization VI

    The RadeonSI NIR back-end as an alternative to its longstanding TGSI usage continues to be improved upon as a prerequisite for supporting OpenGL 4.6 with SPIR-V ingestion. A fresh batch of RadeonSI NIR work was merged today, including to enable it by default for one Linux game.

    Several developers landed the latest NIR code into Mesa 19.1 Git on Monday, including Marek Olšák who added a radeonsi_enable_nir option to DriConf for allowing the NIR usage to be flipped on a per-game/per-executable basis. Up to now users had to manually set R600_DEBUG=nir (or now, AMD_DEBUG=nir as the other syntax now supported in recent days with Mesa 19.1). But now with this DriConf option, it can "whitelist" games as needed.

  • mesa 19.0.0-rc5

    Hi List,

    Hot off the press is mesa 19.0-rc5. Due to a number of still opened bugs in the
    release tracker this will not be the final release, and I predict at least one
    more release candidate before the final release happens.

    Just an FYI, I will not be working Thursday or Friday this week, so if I don't
    respond to nominations after tommorrow don't be surprised Smile

    Anyway, in the rc5 release we have a little bit of everything, but not too much
    of any one thing:

    - nir
    - radv
    - v3d
    - intel
    - swr
    - anv
    - spirv
    - meson
    - radeonsi

    Dylan

  • Mesa 19.0-RC5 Released As The Cycle Drags Into Overtime

    Mesa 19.0-RC5 was issued a short time ago as the latest release candidate for Mesa 19.0. Due to blocker bugs remaining, at least one more release candidate is likely next week before seeing the official release.

    The 19.0 bug tracker still shows more than a half dozen bugs blocking the release. These blocker bugs range from 1~2% performance regressions in Unigine benchmarks with Skylake graphics to other random performance regressions and also some test case failures on the Intel side.

Wayland 1.17 & Weston 6.0 Reach Alpha, Officially Releasing Next Month

Filed under
Graphics/Benchmarks

Out today are the first alpha releases for Wayland 1.17 and the Weston 6.0 reference compositor. This alpha release is about two weeks behind schedule but the developers have updated their plans to now ship the beta releases on 5 March, release candidates begin on 12 March, and potentially releasing the stable versions of Wayland 1.17.0 and Weston 6.0.0 on 19 March.

The Wayland 1.17 Alpha release adds to the protocol support for expressing an internal server error message as well as an updated wl_seat protocol. There are also memory leak fixes for the Wayland scanner and various test updates. Details on the 1.17 alpha via wayland-devel.

Also out today is the Weston 6.0 Alpha. On the Weston compositor front they have shifted to using the Meson build system while deprecating Autotools, XDG-Shell stable support, FreeRDP 2.0 updates, IVI shell improvements, and many other changes.

Read more

NVIDIA 418.31.03 Linux Driver

Filed under
Graphics/Benchmarks
Gaming

Mesa 18.3.4

Filed under
Graphics/Benchmarks

Mesa 18.3.4 is now available.

In this release we have:

A fix in the XvMC state-tracker, which was causing some video attributes to
not take affect. On the video front the VAAPI state tracker has seen
improvements with VP9 streams while the amdgpu driver advertises all available
profiles.

On Intel side we have compiler fixes and extra PCI IDs for Coffee Lake and
Ice Lake parts. In the Broadcom drivers a couple of memory leaks were
addressed and the NEON assembly should compile properly on armhf.

Other drivers such as radeonsi, nouveau and freedreno have also seen some
love. The RADV driver has seen addressed to compile correctly with GCC9
amongst other changes.

The Xlib based libGL have been addressed to work with X servers, which lacks
the MIT-SHM extension such as XMing.

To top it up we have a few fixes to the meson build system.

Read more

Also: Mesa 18.3.4 Brings VA-API VP9 Improvements, More Coffeelake/Icelake IDs For Intel

Chamferwm: A Vulkan-Powered X11 Window Manager

Filed under
Graphics/Benchmarks

While we have talked about the possibilities of writing a Vulkan Wayland compositor and there was even a short-lived Vulkan renderer for KDE's KWin, it's also possible to write a X11 window manager around the Vulkan interfaces.

Chamferwm is a new tiling X11 window manager that features a Vulkan compositor. Chamferwm doesn't support Wayland at this point but is written using Vulkan and XCB for the X11 bits. This tiling window manager already supports a lot of standard window management functionality, all rendering is done with Vulkan and there is support for user-supplied shaders for decorations/borders, and support as well for using an external compositor.

Read more

Linux 5.0 I/O Scheduler Benchmarks On Laptop & Desktop Hardware

Filed under
Graphics/Benchmarks

Our past tests have shown that while most Linux distributions default to "none" for their I/O scheduler on NVMe solid-state storage, that isn't necessarily the best scheduler decision in all cases. Here are tests using the Linux 5.0 Git kernel using laptop and desktop hardware while evaluating no I/O scheduler, mq-deadline, Kyber, and BFQ scheduler options.

Out today is the latest installment of our routine I/O scheduler kernel benchmarks. For this round of testing using a Linux 5.0 Git kernel atop Ubuntu 18.04 LTS, tests were done on an AMD Ryzen 5 2400G desktop and Intel Core i7 8550U laptop. The Ryzen 5 2400G had a Corsair Force MP500 120GB NVMe SSD. The laptop was a Dell XPS 9370 with Samsung PM961 solid-state drive. EXT4 was the file-system in use on both systems and with the default mount options.

Read more

Intel Graphics: Discrete Graphics Cards and SVT-AV1

Filed under
Graphics/Benchmarks
Hardware
  • Intel Preps For Discrete Graphics Cards With Linux Patches

    Intel has confirmed that recent patches to its Linux graphics driver were related to its continued work on preparing the ecosystem for its new line of discrete graphics cards.

    Phoronix reported that Intel released 42 such patches with more than 4,000 lines of code between them on February 14. The main purpose of the patches was to introduce the concept of memory regions in "preparation for upcoming devices with device local memory." (Such as, you know, discrete graphics cards.)

    [...]

    Still, any information about Intel's graphics plans is welcome. Right now the graphics market is dominated by AMD and Nvidia, and as we noted in December, Intel is probably the only company that even has a possibility of successfully introducing a new discrete graphics architecture. Why not enjoy the occasional glimpse behind the curtain as that architecture's being built?

  • SVT-VP9 Is Intel's Latest Open-Source Video Encoder Yielding High Performance VP9

    At the start of the month Intel open-sourced SVT-AV1 aiming for high-performance AV1 video encoding on CPUs. That complemented their existing SVT-HEVC encoder for H.265 content and already SVT-AV1 has been seeing nice performance improvements. Intel now has released SVT-VP9 as a speedy open-source VP9 video encoder.

    Uploaded on Friday was the initial public open-source commit of SVT-VP9, the Intel Scalable Video Technology VP9 encoder. With this encoder they are focusing on being able to provide real-time encoding of up to two 4Kp60 streams on an Intel Xeon Gold 6140 processor. SVT-VP9 is under a BSD-style license and currently runs on Windows and Linux.

Noctua's NH-U9 TR4-SP3 Is Still The Best 4U EPYC / Threadripper Cooler I've Found

Filed under
Graphics/Benchmarks

If you are in the market for an AMD Ryzen Threadripper or AMD EPYC heatsink that fits within 4U height requirements, the Noctua NH-U9 TR4-SP3 is still easily the best option available. I'm now running the NH-U9 TR4-SP3 in five different EPYC/Threadripper systems in the racks and they work out splendid.

I've already covered the NH-U9 TR4-SP3 multiple times before, but with having picked up another one of these coolers this past week and being satisfied with the results, just wanted to give another shout-out to Noctua and pass along the latest thermal results. For this latest build, the NH-U9 TR4-SP3 is cooling an EPYC 7351P 16-core / 32-thread CPU that tops out at 3.9GHz.

Read more

Syndicate content

More in Tux Machines

Games: Surviving Mars and OpenMW

Kernel and Security: BPF, Mesa, Embedded World, Kernel Address Sanitizer and More

  • Concurrency management in BPF
    In the beginning, programs run on the in-kernel BPF virtual machine had no persistent internal state and no data that was shared with any other part of the system. The arrival of eBPF and, in particular, its maps functionality, has changed that situation, though, since a map can be shared between two or more BPF programs as well as with processes running in user space. That sharing naturally leads to concurrency problems, so the BPF developers have found themselves needing to add primitives to manage concurrency (the "exchange and add" or XADD instruction, for example). The next step is the addition of a spinlock mechanism to protect data structures, which has also led to some wider discussions on what the BPF memory model should look like. A BPF map can be thought of as a sort of array or hash-table data structure. The actual data stored in a map can be of an arbitrary type, including structures. If a complex structure is read from a map while it is being modified, the result may be internally inconsistent, with surprising (and probably unwelcome) results. In an attempt to prevent such problems, Alexei Starovoitov introduced BPF spinlocks in mid-January; after a number of quick review cycles, version 7 of the patch set was applied on February 1. If all goes well, this feature will be included in the 5.1 kernel.
  • Intel Ready To Add Their Experimental "Iris" Gallium3D Driver To Mesa
    For just over the past year Intel open-source driver developers have been developing a new Gallium3D-based OpenGL driver for Linux systems as the eventual replacement to their long-standing "i965 classic" Mesa driver. The Intel developers are now confident enough in the state of this new driver dubbed Iris that they are looking to merge the driver into mainline Mesa proper.  The Iris Gallium3D driver has now matured enough that Kenneth Graunke, the Intel OTC developer who originally started Iris in late 2017, is looking to merge the driver into the mainline code-base of Mesa. The driver isn't yet complete but it's already in good enough shape that he's looking for it to be merged albeit marked experimental.
  • Hallo Nürnberg!
    Collabora is headed to Nuremberg, Germany next week to take part in the 2019 edition of Embedded World, "the leading international fair for embedded systems". Following a successful first attendance in 2018, we are very much looking forward to our second visit! If you are planning on attending, please come say hello in Hall 4, booth 4-280! This year, we will be showcasing a state-of-the-art infrastructure for end-to-end, embedded software production. From the birth of a software platform, to reproducible continuous builds, to automated testing on hardware, get a firsthand look at our platform building expertise and see how we use continuous integration to increase productivity and quality control in embedded Linux.
  • KASAN Spots Another Kernel Vulnerability From Early Linux 2.6 Through 4.20
    The Kernel Address Sanitizer (KASAN) that detects dynamic memory errors within the Linux kernel code has just picked up another win with uncovering a use-after-free vulnerability that's been around since the early Linux 2.6 kernels. KASAN (along with the other sanitizers) have already proven quite valuable in spotting various coding mistakes hopefully before they are exploited in the real-world. The Kernel Address Sanitizer picked up another feather in its hat with being responsible for the CVE-2019-8912 discovery.
  • io_uring, SCM_RIGHTS, and reference-count cycles
    The io_uring mechanism that was described here in January has been through a number of revisions since then; those changes have generally been fixing implementation issues rather than changing the user-space API. In particular, this patch set seems to have received more than the usual amount of security-related review, which can only be a good thing. Security concerns became a bit of an obstacle for io_uring, though, when virtual filesystem (VFS) maintainer Al Viro threatened to veto the merging of the whole thing. It turns out that there were some reference-counting issues that required his unique experience to straighten out. The VFS layer is a complicated beast; it must manage the complexities of the filesystem namespace in a way that provides the highest possible performance while maintaining security and correctness. Achieving that requires making use of almost all of the locking and concurrency-management mechanisms that the kernel offers, plus a couple more implemented internally. It is fair to say that the number of kernel developers who thoroughly understand how it works is extremely small; indeed, sometimes it seems like Viro is the only one with the full picture. In keeping with time-honored kernel tradition, little of this complexity is documented, so when Viro gets a moment to write down how some of it works, it's worth paying attention. In a long "brain dump", Viro described how file reference counts are managed, how reference-count cycles can come about, and what the kernel does to break them. For those with the time to beat their brains against it for a while, Viro's explanation (along with a few corrections) is well worth reading. For the rest of us, a lighter version follows.

Blacklisting insecure filesystems in openSUSE

The Linux kernel supports a wide variety of filesystem types, many of which have not seen significant use — or maintenance — in many years. Developers in the openSUSE project have concluded that many of these filesystem types are, at this point, more useful to attackers than to openSUSE users and are proposing to blacklist many of them by default. Such changes can be controversial, but it's probably still fair to say that few people expected the massive discussion that resulted, covering everything from the number of OS/2 users to how openSUSE fits into the distribution marketplace. On January 30, Martin Wilck started the discussion with a proposal to add a blacklist preventing the automatic loading of a set of kernel modules implementing (mostly) old filesystems. These include filesystems like JFS, Minix, cramfs, AFFS, and F2FS. For most of these, the logic is that the filesystems are essentially unused and the modules implementing them have seen little maintenance in recent decades. But those modules can still be automatically loaded if a user inserts a removable drive containing one of those filesystem types. There are a number of fuzz-testing efforts underway in the kernel community, but it seems relatively unlikely that any of them are targeting, say, FreeVxFS filesystem images. So it is not unreasonable to suspect that there just might be exploitable bugs in those modules. Preventing modules for ancient, unmaintained filesystems from automatically loading may thus protect some users against flash-drive attacks. If there were to be a fight over a proposal like this, one would ordinarily expect it to be concerned with the specific list of unwelcome modules. But there was relatively little of that. One possible exception is F2FS, the presence of which raised some eyebrows since it is under active development, having received 44 changes in the 5.0 development cycle, for example. Interestingly, it turns out that openSUSE stopped shipping F2FS in September. While the filesystem is being actively developed, it seems that, with rare exceptions, nobody is actively backporting fixes, and the filesystem also lacks a mechanism to prevent an old F2FS implementation from being confused by a filesystem created by a newer version. Rather than deal with these issues, openSUSE decided to just drop the filesystem altogether. As it happens, the blacklist proposal looks likely to allow F2FS to return to the distribution since it can be blacklisted by default. Read more

gitgeist: a git-based social network proof of concept

Are you tired of not owning the data or the platform you use for social postings? I know I am. It's hard to say when I "first" used a social network. I've been on email for about 30 years and one of the early ad-hoc forms of social networks were chain emails. Over the years I was asked to join all sorts of "social" things such as IRC, ICQ, Skype, MSN Messenger, etc. and eventually things like Orkut, MySpace, Facebook, etc. I'll readily admit that I'm not the type of person that happily jumps onto every new social bandwagon that appears on the Internet. I often prefer preserving the quietness of my own thoughts. That, though, hasn't stopped me from finding some meaningfulness participating in Twitter, Facebook, LinkedIn and more recently Google+. Twitter was in fact the first social network that I truly embraced. And it would've remained my primary social network had they not killed their own community by culling the swell of independently-developed Twitter clients that existed. That and their increased control of their API effectively made me look for something else. Right around that time Google+ was being introduced and many in the open source community started participating in that, in some ways to find a fresh place where techies can aggregate away from the noise and sometimes over-the-top nature of Facebook. Eventually I took to that too and started using G+ as my primary social network. That is, until Google recently decided to pull the plug on G+. While Google+ might not have represented a success for Google, it had become a good place for sharing information among the technically-inclined. As such, I found it quite useful for learning and hearing about new things in my field. Soon-to-be-former users of G+ have gone in all sorts of directions. Some have adopted a "c'mon guys, get over it, Facebook is the spot" attitude, others have adopted things like Mastodon, others have fallen back to their existing IDs on Twitter, and yet others, like me, are still looking. Read more