Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

AMD Ryzen 9 3900X vs. Intel Core i9 9900K Performance In 400+ Benchmarks

Filed under
Graphics/Benchmarks

Given the recent AMD "ABBA" Ryzen 3000 boost fix, the upcoming release of Ubuntu 19.10 powered by Linux 5.3, here is a fresh round of AMD Ryzen 9 3900X vs. Intel Core i9 9900K benchmarks in a side-by-side matchup . It's just not any comparison but our largest i9-9900K vs. 3900X comparison ever: 112 gaming benchmarks and 321 system/CPU benchmarks carried out for our most extensive look yet at how these ~$500 CPUs are competing in this fierce race.

This round of Core i9 9900K vs. Ryzen 9 3900X benchmarking was done while both systems were running the latest daily release of Ubuntu 19.10 powered by the Linux 5.3 kernel, which itself brought some nice performance-related work over previous kernels. Ubuntu 19.10 is also now running GNOME 3.34.0 that can make a difference for some gaming benchmarks while its default driver stack is currently on Mesa 19.1.6.

The Core i9 9900K was running with the ASUS PRIME Z390-A motherboard and the Ryzen 9 3900X with the ROG CROSHAIR VIII HERO WiFi motherboard, both boards using their very latest public BIOS releases as of testing. Both systems were tested with the same GSKILL 2 x 8GB DDR4-3600 memory, 280GB Intel Optane 900p NVMe SSD, and Radeon RX Vega 64 graphics card. The RX Vega 64 was used over the Radeon RX 5700 series due to Ubuntu 19.10's older Mesa build not having Navi support and the Navi support in general still maturing and recommended for use with Mesa 19.3-devel, so with this not being a graphics card comparison anyhow, the RX Vega 64 was the safer and more accurate card to use for this round of testing.

Read more

Graphics: Panfrost Gallium3D and GPU Offloading

Filed under
Graphics/Benchmarks
  • Panfrost Gallium3D Driver Focusing On Bettering The Arm Midgard Support

    While there hasn't been too much to write on it in recent weeks, the Panfrost Gallium3D driver within Mesa for Arm Midgard/Bifrost graphics continues chugging along. The latest work on it is switching over to a new scheduler for Midgard.

    If using a Midgard GPU, a.k.a. the Mali T604 through T880, that seems to be the recent focus of lead Panfrost developer Alyssa Rosenzweig.

  • GCC Is Potentially Months From Seeing Radeon OpenMP 4.5 / OpenACC 2.6 GPU Offloading

    At last month's GNU Tools Cauldron was an update on the Radeon GCN back-end state for the GCC compiler, which is likely to see more code land around year's end.

    Merged for GCC 9 was the initial Radeon GCN back-end for targeting AMD GPUs from the GNU Compilers Collection as an alternative to their long-standing AMDGPU LLVM compiler support. With GCC 9 the Radeon GCN support was limited, but for next year's GCC 10 support it should be in better shape. They have a path forward to make it quite capable, but it might not all land in time for GCC 10.

GeForce RTX SUPER Linux Compute Performance - 18 GPU NVIDIA OpenCL Comparison

Filed under
Graphics/Benchmarks

Last week we began our belated NVIDIA GeForce RTX SUPER benchmarking by looking at the RTX 2060 / 2070 / 2080 SUPER Linux gaming performance in a 26-way graphics card comparison. For those more interested in the RTX SUPER graphics cards for their OpenCL compute performance potential, these benchmarks today are for you.

This article provides a look at the compute performance potential for these newest NVIDIA graphics cards. Given the workloads and AMD still not providing any Radeon Open Compute (ROCm) support for their newest Navi graphics cards, this comparison is just looking at the NVIDIA compute potential between the Maxwell / Pascal / Turing line-ups. You can treat this as a reference comparison and for those curious about the generational power efficiency / performance-per-Watt and other metrics.

Read more

Graphics Leftovers

Filed under
Graphics/Benchmarks
  • QEMU's Assortment Of Virtual VGA/GPU Options & What To Pick For Desktop Virtualization

    The virtual GPU/display landscape particularly for having accelerated guest graphics was once non-existent and then suffering for the open-source Linux virtualization stack around QEMU, but that is no longer the case. There are options these days to rival the GPU/display offerings of VirtualBox and VMware albeit to newcomers may not be so clear.

    Longtime QEMU/virtualization developer Gerd Hoffmann has written a blog post outlining the VGA/display devices for QEMU and the recommended options. The options he covers at length include the standard VGA device, Bochs display device, VirtIO VGA, VirtIO GPU, Vhost-user VirtIO GPU, QXL VGA, QXL, Cirrua VGA, ATI VGA, and RAMFB.

  • Intel's Inaugural Release Of OpenVKL Ties Into Their Promising oneAPI Rendering Toolkit

    While announced some months ago, today in-step with the OSPray 2.0 Alpha ray-tracing release is the inaugural development release of the Open Volume Kernel Library (OpenVKL).

    Intel's Open Volume Kernel Library is a set of volume computation kernels optimized for AVX/AVX2/AVX-512 and leverages their SPMD Program Compiler. OpenVKL ties into Intel's other open-source render components like OSPray for what will form their oneAPI rendering tool-kit. We're now in Q4 and that is when the beta release of Intel's oneAPI is expected.

  • LuxCoreRender 2.2 Released With Intel Open Image Denoise Yields Faster Render Times

    LuxCoreRender, the open-source physically based renderer for execution on CPUs as well as OpenCL accelerators / GPUs, is out with version 2.2 and now integrates Intel's open-source Open Image Denoise.

    LuxCoreRender already made use of Intel's Embree library (as happened to be covered this morning with benchmark results in The Xeon vs. EPYC Performance With Intel's oneAPI Embree & OSPray Render Projects) while now they have also pulled in Intel's Open Image Denoise.

  • Unofficial Radeon ROCm Packages Re-Enable APU Support

    Over a year ago the AMD APU support in the Radeon Open Compute (ROCm) stack was quietly removed and has yet to be re-enabled in the upstream ROCm packages. But should you be wanting to use ROCm for their compute APIs or OpenCL on APUs, unofficial Ubuntu packages are now available to provide this capability.

    Engineering firm Bruhnpace AB has resorted to providing their own ROCm packages for Ubuntu 18.04 with AMD APU support enabled to make up for AMD's lack of official packages handling APUs in the different ROCm libraries. The repository doesn't provide its own rocm-dkms package but rather recommends users run the latest upstream kernels for the AMDKFD kernel driver support.

  • Phoronix Test Suite 9.0.1 Available Along With Several New/Updated Test Profiles

    As a minor update following last month's Phoronix Test Suite 9.0 release, version 9.0.1 is now available and also for all PTS users are a number of new/updated test profiles via OpenBenchmarking.org.

AMD Navi 12 Gets 256-bit memory bus according to Linux drivers, Radeon RX 5600 128-bit

Filed under
Graphics/Benchmarks
Linux

A lot has been said and spoken already about AMD's upcoming NAVI 12 (RX 5600) and 14 (RX 5500). More information from Linux drivers indicates that AMD Navi 12 gets a 256-bit memory bus and the RX 5600 128-bit, likely GDDR6.

The news arrives today though a user at Germany based 3DCenter forums called Berniyh, he found Navi 12 and Navi 14 in Linux drivers, the two GPUs could end up in the RX 5800 and RX 5600 cards respectively. Navi 12 is mentioned to get a 256-bit memory bus. Navi 14 would, according to previously surfaced drivers, get versions with 3, 4 and 8 GB volume graphics memory but on a 128-bit memory bus.

Read more

Phoronix: IO_uring, Speculative Execution, Encode/Decode Benchmark

Filed under
Graphics/Benchmarks
Linux
  • IO_uring Is More Polished With Linux 5.4

    Added back during the Linux 5.1 cycle was IO_uring for fast and efficient I/O. This new interface allows for queue rings to be shared between the application and kernel to avoid excess copies and other efficiency improvements over the existing Linux AIO code. With Linux 5.4, IO_uring is in even better shape.

    In the months since IO_uring was merged to mainline, we've seen a ton of continued work on it including the likes of a 755x performance improvement. With Linux 5.4, it seems following extensive optimizations by Jens Axboe and others, it's in quite a polished shape.

  • It Turns Out CPU Speculative Execution Can Be Useful For Random Entropy / RNG

    While CPU speculative execution has caused a lot of frustrations over the past two years due to the likes of the Spectre vulnerabilities, it turns out CPU speculative execution can be exploited to be a viable source of random entropy for random number generators.

    Particularly on newer Intel/AMD CPU microarchitectures where speculative execution is much more advanced than hardware from years ago, it's been found that measuring the execution time of loops relying upon speculation is random enough to be a cheap and speedy source of entropy.

    [...]

    Linus Torvalds commented and he believes that this is not very reliable and a simple jitter entropy implementation. But he did post his own proof-of-concept code for improving the jitter entropy code based upon this.

  • Fresh Video Encode/Decode Benchmark Numbers For Xeon Platinum 8280 vs. EPYC 7742

    Given recent updates to the Intel Scalable Video Technology (SVT) open-source video encoders as well as other open-source video encoders/decoders, here is a fresh look at the performance of the AMD EPYC 7742 2P server against the Intel competition with the dual Xeon Platinum 8280.

Peter Bengtsson: How much faster is Redis at storing a blob of JSON compared to PostgreSQL?

Filed under
Graphics/Benchmarks
Server
OSS

First of all, I'm still a PostgreSQL fan-boy and have no intention of ceasing that. These times are made up of much more than just the individual databases. For example, the PostgreSQL speeds depend on the Django ORM code that makes the SQL and sends the query and then turns it into the model instance. I don't know what the proportions are between that and the actual bytes-from-PG's-disk times. But I'm not sure I care either. The tooling around the database is inevitable mostly and it's what matters to users.

Both Redis and PostgreSQL are persistent and survive server restarts and crashes etc. And you get so many more "batch related" features with PostgreSQL if you need them, such as being able to get a list of the last 10 rows added for some post-processing batch job.

I'm currently using Django's cache framework, with Redis as its backend, and it's a cache framework. It's not meant to be a persistent database. I like the idea that if I really have to I can just flush the cache and although detrimental to performance (temporarily) it shouldn't be a disaster. So I think what I'll do is store these JSON blobs in both databases. Yes, it means roughly 6GB of SSD storage but it also potentially means loading a LOT more into RAM on my limited server. That extra RAM usage pretty much sums of this whole blog post; of course it's faster if you can rely on RAM instead of disk. Now I just need to figure out how RAM I can afford myself for this piece and whether it's worth it.

Read more

DXVK 1.4.1 Released

Filed under
Graphics/Benchmarks
Gaming

Initial Benchmarks Of CentOS 8.0 & CentOS Stream On Intel Xeon / AMD EPYC

Filed under
Graphics/Benchmarks

With this week's release of the much anticipated CentOS 8.0 as the community/free rebuild of Red Hat Enterprise Linux 8 as well as the surprise announcement of the bleeding-edge, rolling-release CentOS Stream, we have begun benchmarking these enterprise Linux distribution releases. Up today are our first tests of CentOS 7.7 against CentOS 8.0 and the early CentOS Stream state on Intel Xeon Cascadelake and AMD EPYC Rome servers.

This is just the first of our CentOS 8.0 benchmarks over the past few days with more performance tests being worked on, including a cross-distribution comparison of the enterprise Linux x86_64 distributions and more. But for ending out the week, here is an initial look at the CentOS 8.0 performance for those that may be using the weekend downtime for upgrading from CentOS 7.

Read more

Linux: VirtIO-FS and Intel

Filed under
Graphics/Benchmarks
Linux
  • VirtIO-FS Sent In For Linux 5.4 With Better Performance Over VirtIO-9P

    VirtIO-FS as a better approach for sharing folders/files with guest VMs is set to debut in Linux 5.4.

    VirtIO-FS makes use of FUSE and is much faster than virtio-8p that serves a similar purpose for sharing folders/files between the host and guest virtual machines. Directories can be exported from the host and mounted by the guest with VirtIO-FS and is effectively the "glue" between FUSE and VirtIO.

  • UDOO X86 II SBC Combines Intel Braswell SoC with Microchip ATMega32U4 “Arduino” MCU

    UDOO X86 development board was first introduced in a crowdfunding campaign in 2016 with a quad-core Intel Braswell processor coupled with an Arduino 101 compatible Intel Curie module for real-time I/O processing.

    Early July of next year (2019) the Intel processor and module seems to be going so well and have a bright future together with UDOO X86 board and accessories becoming broadly available. But life can be cruel at times, and Intel announced their plan to discontinue Intel Curie and other IoT projects just a few weeks later with the last shipment scheduled for July 2018.

  • Intel's Mesa Drivers Point To Even More Comet Lake Parts

    There were already 18 new PCI IDs for Intel's open-source OpenGL/Vulkan Linux graphics drivers for forthcoming Comet Lake processors with UHD Graphics, but now it appears there are even more models en route.

    As of Wednesday, three more PCI IDs were added for Comet Lake, making more than 20 different PCI IDs for graphics on Comet Lake processors. Granted, some of the PCI IDs are reserved for pre-production models / engineering samples or otherwise reserved for possible future revisions that aren't necessarily planned for market at this time, but either way it's a lot.

Syndicate content

More in Tux Machines

Programming: GCC, RcppEigen and Python

  • Introduce a new GCC option, --record-gcc-command-line
    I would like to propose the following patches which introduce a compile option --record-gcc-command-line. When passed to gcc, it saves the command line option into the produced object file. The option makes it trivial to trace back how a file was compiled and by which version of the gcc. It helps with debugging, reproducing bugs and repeating the build process.
    
    This option is similar to -frecord-gcc-switches. However, they have three fundamental differences: Firstly, -frecord-gcc-switches saves the internal state after the argv is processed and passed by the driver. As opposed to that, --record-gcc-command-line saves the command-line as received by the driver. Secondly, -frecord-gcc-switches saves the switches as separate entries into a mergeable string section. Therefore, the entries belonging to different object files get mixed up after being linked. The new --record-gcc-command-line, on the other hand, creates one entry per invocation. By doing so, it makes it clear which options were used together in a single gcc invocation. Lastly, --record-gcc-command-line also adds the version of the gcc into this single entry to make it clear which version of gcc was called with any given command line. This is useful in cases where .comment section reports multiple versions.
    
    While there are also similarities between the implementations of these two options, they are completely independent. These commands can be used separately or together without issues. I used the same section that -frecord-gcc-switches uses on purpose. I could not use the name -frecord-gcc-command-line for this option; because of a {f*} in the specs, which forwards all options starting with -f to cc1/cc1plus as is. This is not we want for this option. We would like to append it a filename as well to pass the argv of the driver to child processes.
    
    This functionality operates as the following: It saves gcc's argv into a temporary file, and passes --record-gcc-command-line <tempfilename> to cc1 or cc1plus. The functionality of the backend is implemented via a hook. This patch includes an example implementation of the hook for elf targets: elf_record_gcc_command_line function. This function reads the given file and writes gcc's version and the command line into a mergeable string section, .GCC.command.line.
    
    
  • GCC Developers Discuss New Option For Recording Compiler Flags / Details In Binaries

    GCC developers recently have been discussing a new proposal over an option for preserving the command-line flags/options used when building a binary as well as the associated compiler version. The proposal sent out last week was over a --record-gcc-command-line option to save the compiler options into the produced object file. The proposal is in the name of helping debugging, reproducing bugs, and repeating build process. There is already a -frecord-gcc-switches option that is somewhat similar in behavior but with key differences as explained in the proposal.

  • RcppEigen 0.3.3.7.0

    A new minor release 0.3.3.7.0 of RcppEigen arrived on CRAN today (and just went to Debian too) bringing support for Eigen 3.3.7 to R. This release comes almost a year after the previous minor release 0.3.3.5.0. Besides the upgrade to the new upstream version, it brings a few accumulated polishes to the some helper and setup functions, and switches to the very nice tinytest package for unit tests; see below for the full list. As before, we carry a few required changes to Eigen in a diff.

  • “Higher Performance Python” at PyDataCambridge 2019

    I’ve had the pleasure of speaking at the first PyDataCambridge conference (2019), this is the second PyData conference in the UK after PyDataLondon (which colleagues and I co-founded 6 years back). I’m super proud to see PyData spread to 6 regional meetups and now 2 UK conferences.

today's howtos

Games: Baba, Dicey Dungeons, Factorio and Enabling GameMode

  • Excellent rule-changing puzzle game Baba Is You is getting an official level editor

    Baba Is You, the truly excellent puzzle game where you have to break the rules of each level to beat them is getting a big update soon. See Also: previous thoughts on it here. How do you break these rules? Well, on each level there's logic blocks you can push around to change everything. Turn yourself into a rock, a jellyfish, make it so touching a wall wins instead of a flag you can't access and all kinds of really crazy things it becomes quite hilarious.

  • Dicey Dungeons outsold Terry Cavanagh's last two Steam games in the first month

    Terry Cavanagh, the indie developer behind VVVVVV, Super Hexagon and the latest Dicey Dungeons has a new blog post out talking about how well Dicey Dungeons has done and what's to come next. Leading up to the release, Cavanagh was doing a blog post each day for seven days. This latest post from yesterday then, is long overdue considering Dicey Dungeons launched in August.

  • Factorio is leaving Early Access in September next year

    As a result of the team behind Factorio feeling like it's going on for too long, they've now set a proper release date. In their latest Friday Facts update, they mentioned how their "when it's done" approach has served them well to create a high-quality game "but if we continued this way, we would be doing it basically forever". Part of the issue is that they want to work on new features and add content, instead of constant polishing. So they're setting a date publicly now "so we have to stick with it". With that in mind, it's going to leave Early Access on September 25, 2020. Development is not ending once they hit the big 1.0, they also don't want to say it's 100% finished either. Like a lot of games, as long as the money keeps coming in they will likely keep adding to it.

  • Enabling GameMode on Linux for best gaming performance

Red Hat Enterprise Linux and CentOS Now Patched Against Latest Intel CPU Flaws

After responding to the latest security vulnerabilities affecting Intel CPU microarchitectures, Red Hat has released new Linux kernel security updates for Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 operating systems to address the well-known ZombieLoad v2 flaw and other issues. The CentOS community also ported the updates for their CentOS Linux 6 and CentOS Linux 7 systems. The security vulnerabilities patched in this new Linux kernel security update are Machine Check Error on Page Size Change (IFU) (CVE-2018-12207), TSX Transaction Asynchronous Abort (TAA) (CVE-2019-11135), Intel GPU Denial Of Service while accessing MMIO in lower power state (CVE-2019-0154), and Intel GPU blitter manipulation that allows for arbitrary kernel memory write (CVE-2019-0155). Read more