Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Samsung 870 QVO SSD Performance On Ubuntu Linux

Filed under
Graphics/Benchmarks

The Samsung 870 QVO solid-state drives announced at the end of June have begun appearing at Internet retailers. The Samsung 870 QVO is the company's latest QLC NAND solid-state drive offering 1TB of storage for a little more than $120 USD all the way up to 4TB for $500 and an 8TB variant for $900. For those curious about the EXT4 file-system Linux performance out of the Samsung 870 QVO, here are some benchmarks.

Read more

Mesa: "Navy Flounder", Jason Ekstrand's Merge Request and Versioning

Filed under
Graphics/Benchmarks

  • AMD "Navy Flounder" Support Merged Into Mesa 20.2

    "Navy Flounder" as the codename for another Navi 2 GPU following the "Sienna Cichlid" Linux driver work has made it into Mesa 20.2 for the RadeonSI Gallium3D driver.

    The Navy Flounder AMDGPU kernel driver support for Linux was sent out several weeks ago and will come with the Linux 5.9 kernel alongside the newly-enabled Sienna Cichlid support for these initial Navi 2 GPUs seeing open-source Linux driver support.

  • Mike Blumenkrantz: Internal Changes

    Today I’m going to briefly go over a big-ish API change that’s taking place as a result of a MR from Jason Ekstrand.

  • Mike Blumenkrantz: Versioning

    Today I thought it might be interesting to dive into how mesa detects version support for drivers.

    To do so, I’m going to be jumping into mesa/src/mesa/main/version.c, which is where the magic happens.

Linux To Allow Limiting Tiger Lake SoC PL4 Package Maximum Power Limit

Filed under
Graphics/Benchmarks
Linux

Intel has been preparing "Power Limit4" support for their Linux PowerCap driver that is being rolled out for the forthcoming Tiger Lake SoCs.

The Power Limit4 (PL4) support allows limiting the SoC's maximum power limit at a package level. The user can mandate the maximum Wattage the SoC is allowed in order to prevent power spikes from tripping any power adapter, battery over-current protection, or other limitations.

The user can control the PL4 power limit in Watts via the RAPL (Runtime Average Power Limiting) sysfs interface. RAPL has already allowed power limiting while this PL4 support is about providing the limit at a package-level.

Read more

Also: Radeon "Southern Islands" Support Continues Improving In AMDGPU Driver - GPU Reset

GCC Benchmarks At Varying Optimization Levels With Core i9 10900K Show An Unexpected Surprise

Filed under
Graphics/Benchmarks

With the Intel Core i9 10900K "Comet Lake" processor here are some fresh GCC compiler benchmarks when looking at the performance of GCC 8.4 versus 9.3 versus a 10.2 snapshot while testing with optimization flags of -O2, -O3 -march=native, and -O3 -march=native -flto.
On Ubuntu 20.04 with the Linux 5.8 kernel the compilers GCC 8.4.0, GCC 9.3.0, and a GCC 10.2 snapshot from 10.2 were built from source while using the same build arguments across all tested builds and using the same compiler (Ubuntu 20.04 default compiler) for building these different GCC compiler releases. Various C/C++ benchmarks were carried out with each GCC release while setting the CFLAGS/CXXFLAGS to "-O2", "-O3 -march=native", and "-O3 -march=native -flto" for a mix of common optimization levels.
Via the Phoronix Test Suite dozens of different benchmarks were carried out for looking at the compiler performance on the current Core i9 10900K that still makes use of the Skylake era target.

Read more

Graphics: DragonFlyBSD, LuxCoreRender and SWVKC

Filed under
Graphics/Benchmarks

  • DragonFlyBSD Updates Its Intel + Radeon Linux-Ported Graphics Driver Code

    DragonFlyBSD developer François Tigeot continues his trek of near single-handedly porting the Intel and Radeon DRM graphics driver code from the Linux kernel to this BSD.

    For years now Tigeot has been working on bringing the Direct Rendering Manager code from the Linux kernel to that of the DragonFlyBSD kernel and all the headaches involved from interface differences to porting other Linux kernel bits where needed.

  • LuxCore Open-Source Renderer v2.4 Released With CUDA Support, Better Windows Scaling

    Debuting this weekend was LuxCoreRender 2.4, the newest version of this impressive open-source physically based renderer.

    Most significant to LuxCoreRender 2.4 is that NVIDIA's CUDA is now supported alongside the OpenCL and CPU-based render paths. Using this CUDA support for LuxCoreRender can lead to speed-ups for NVIDIA GPUs and has seemingly come together well over the past few months. This code also supports out-of-core CUDA rendering for being able to render scenes larger than what can fit in the available video RAM. With this additional back-end there is also now support for building the LuxCoreRender SDK without OpenCL or CUDA but to then load that support at run-time.

  • SWVKC Is A Vulkan-Powered Wayland Compositor Focused On Performance + Correctness

    While the current Vulkan API is exhaustive enough to implement full-featured Wayland compositors and X11 window managers, to date there hasn't been too much adoption considering OpenGL is still more pervasive among hardware/drivers and it's obviously a significant effort writing a new compositor from scratch. One of the leading (among few) examples of a Vulkan-powered window manager / compositor is ChamferWM, which does continue to be developed. SWVKC meanwhile is one that has been seeing development this year as an alpha-stage Wayland Vulkan compositor.

    SWVKC is a Wayland compositor focused on performance and correctness over features. SWVKC tries to maximize use of direct scan-out of client buffers when possible in the name of greater performance. SWVKC still tries though to avoid screen tearing or stuttering and adhere to the Wayland protocol specification in a strict manner.

Intel Core i5 10600K Comet Lake vs. Core i5 Skylake / Haswell / Sandy Bridge

Filed under
Graphics/Benchmarks

As some additional Core i5 10600K Linux benchmarks for historical perspective, here is a look at how the Core i5 10600K looks in comparison to the Core i5 7600K Skylake, Core i5 4670 Haswell, and Core i5 2500K Sandy Bridge processors on Ubuntu Linux. There were 250 benchmarks ran on each of the CPUs under test.

The ~$270 Core i5 10600K "Comet Lake" processor features six cores and twelve threads with a 4.1GHz base frequency and 4.8GHz turbo frequency while having a 12MB L3 cache. The i5-10600L has a 125 Watt TDP. The i5-10600K is much better than the days of Intel Core i5 CPUs for several generations just being quad-core CPUs without Hyper Threading, but for quantifying the difference here is a look at this mid-range Comet Lake CPU to Kabylake, Haswell, and Sandy Bridge.

Read more

Linux Graphics: Nouveau, Mir, Intel and More

Filed under
Graphics/Benchmarks
Linux

  • Nouveau Changes For Linux 5.9 Bring Fixes, Prep For Future Improvements

    With basically at the cut-off for new feature material wanting to get into DRM-Next for Linux 5.9, Nouveau DRM maintainer Ben Skeggs of Red Hat today sent in the primary feature pull.

    There isn't a whole lot to the open-source NVIDIA driver changes for Linux 5.9, which come in addition to the Nouveau CRC support that came by way of DRM-Misc-Next.

  • Mir 2.0 Released In Dropping Legacy Bits, New Platform Improvements

    Approaching two years already since the release of Mir 1.0 following its shift to Wayland support, Mir 2.0 is now available.

    Mir 2.0 was released this morning and it clears out the legacy Mir client/server packages as well as mir-utils and mirtest-dev. The legacy options around the host socket and nested passthrough were also removed. Various "obsolete stuff" from the Mir client code was also removed.

  • Intel Graphics Compiler Merges New Vector Compute Backend

    While Intel on the hardware manufacturing side continues facing stiff challenges, on the open-source software side the company continues making legendary progress. Out in today's Intel Graphics Compiler and in turn Intel Compute Runtime releases as part of their GPGPU toolchain is the recent open-sourcing and integration of their Vector Compute back-end.

  • Mike Blumenkrantz: Fast Friday

    At this point, longtime readers are well aware of the SPIR-V spec since I reference it in most posts. This spec covers all the base operations and types used in shaders, which are then (occasionally) documented more fully in the full Vulkan spec.

    There comes a time, however, when the core SPIR-V spec is not enough to maintain compatibility with GLSL instructions. In such cases, there are additional specifications which extend the base functionality.

Kernel Security and Graphics

Filed under
Graphics/Benchmarks
Linux
Security

  • The Seccomp Notifier – New Frontiers in Unprivileged Container Development

    That (Linux) Containers are a userspace fiction is a well-known dictum nowadays. It simply expresses the fact that there is no container kernel object in the Linux kernel. Instead, userspace is relatively free to define what a container is. But for the most part userspace agrees that a container is somehow concerned with isolating a task or a task tree from the host system. This is achieved by combining a multitude of Linux kernel features. One of the better known kernel features that is used to build containers are namespaces. The number of namespaces the kernel supports has grown over time and we are currently at eight.

    [...]

    So from the section above it should be clear that seccomp provides a few desirable properties that make it a natural candiate to look at to help solve our mknod(2) and mount(2) problem. Since seccomp intercepts syscalls early in the syscall path it already gives us a hook into the syscall path of a given task. What is missing though is a way to bring another task such as the LXD container manager into the picture. Somehow we need to modify seccomp in a way that makes it possible for a container manager to not just be informed when a task inside the container performs a syscall it wants to be informed about but also how to make it possible to block the task until the container manager instructs the kernel to allow it to proceed.

  • FGKASLR Revved For Improving Linux Kernel Security

    Intel open-source developer Kristen Carlson Accardi continues work on Function Granular Kernel Address Space Layout Randomization (FGKASLR) as a big improvement over traditional KASLR address space layout randomization.

    FGKASLR was originally published earlier this year, 15 years after the debut of KASLR for randomizing the base address of the running kernel. With FGKASLR, individual kernel functions are reordered so that even if the kernel's randomized based address is revealed, an attacker still wouldn't know the location in memory of particular kernel functions as the relative addresses will be different.

  • AMDVLK 2020.Q3.2 Radeon Vulkan Driver Christened Early Due To Bugs

    While it was just two days ago that AMDVLK 2020.Q3.1 debuted and normally there is a two to three week release cadence for these open-source AMD Radeon Vulkan driver code drops, this morning was already met by the debut of AMDVLK 2020.Q3.2.

    This expedited AMDVLK 2020.Q3.2 release is coming principally due to a few bugs. AMDVLK 2020.Q3.2 has changed its preference around Y-coordinate swizzle modes for 3D color attachments with GFX10/Navi, restricts its pipeline cache flush optimization to only cases where it's certainly legal behavior, updating against the Vulkan API 1.2.146 headers, and extends its "defer reusing command stream chunk concept" to all scenarios. There is also fixes for a shared metadata bug on GFX6 (Southern Islands) and fixing of some 999e5 format failures.

  • Mike Blumenkrantz: Partial Writes

    It’s a very slow day, and I awoke at 4:30 with the burning need to finish tessellation shaders. Or maybe I was just burning because it’s so hot out.

    In either case, I had a couple remaining tests that were failing, and, upon closer inspection and a lot of squinting, I determined that the problem was the use of partial writes to patch output variables in tessellation control shaders.

    With this knowledge in hand, I set about resolving the issue in the most bulldozer way possible, with no regard for how much of the code would survive once I discovered which nir pass I probably wanted to be running instead.

Kernel and Graphics: User-Space Threading, I/O, RenderDoc and Mesa

Filed under
Graphics/Benchmarks
Linux
  • Google Finally Begins Their Open-Source Dance Around Linux User-Space Threading

    Way back in 2013 there was a presentation at the Linux Plumbers Conference around Google's work on user-level threads and how they were working on new kernel functionality for using regular threads in a cooperative fashion and building various features off that. Fast forward to today, that functionality has been in use internally at Google for a range of services for latency-sensitive services and greater control over user-space scheduling while now finally in 2020 they are working towards open-sourcing that work.

    [...]

    While FUTEX_SWAP could be honored for the Linux 5.9 cycle, this is just the start and will likely be a few more cycles before all of this Google work is finally open-source and mainlined.

  • Operations restrictions for io_uring

    The io_uring subsystem is not much over one year old, having been merged for the 5.1 kernel in May 2019. It was initially added as a better way to perform asynchronous I/O from user space; over time it has gained numerous features and support for functionality beyond just moving bits around. What it has not yet gained is any sort of security mechanism beyond what the kernel already provides for the underlying system calls. That may be about to change, though, as the result of this patch set from Stefano Garzarella adding a set of user-configurable restrictions to io_uring.

    As one might expect from its name, io_uring is based around a ring buffer shared between the kernel and user space that allows user space to submit operations to the kernel. There is a second ring that is filled with the results of those operations. Each operation can be thought of as a way of expressing a system call; operations may read or write buffers, open files, send network messages, or request any of a number of other actions. Operations can be made contingent on the successful completion of previous operations. In short, the operation stream feeding into the kernel is a sort of language expressing a program that the kernel should execute asynchronously.

    Operations executed by io_uring result in calls to the code within the kernel that implements the corresponding system calls; an IORING_OP_READV operation, for example, ends up in the same place as a readv() system call. That code will perform the usual privilege checks, using the credentials of the process that created the ring in the first place. So, in the absence of bugs, a process can do nothing with io_uring that it would not be allowed to do with direct system calls — with the exception that seccomp() filters do not apply to io_uring. This model has worked well for io_uring so far, but it turns out that there is a use case that could use a bit more control.

    In particular, what happens if a process wants to create a ring and hand it over to another, less-trusted process? For example, I/O from within virtualized guests could perhaps be accelerated considerably if it used io_uring. This I/O, which often goes through the Virtio mechanism now, involves a certain amount of data copying and context shifting that could be avoided this way. The hypervisor could create whatever file descriptors the client would need, which would correspond to specific devices or open network connections, then let the guest handle things directly through the ring from there.

    The problem with this idea is that the guest could then perform any operation that io_uring supports. Remember that the ring retains the credentials of the creator, which would be the hypervisor in this case; giving such a ring to a client would open the door to actions like accessing other file descriptors opened by the hypervisor or opening new files with the hypervisor's credentials. This is likely to prove extremely disappointing to anybody counting on virtualization as a security barrier.

  • RenderDoc 1.9 Released - The Open-Source Graphics Debugging Tool Gets Even Better

    RenderDoc as the open-source, cross-platform, cross graphics API debugger tool for profiling and analyzing issues across Vulkan / Direct3D / OpenGL / GLES continues getting even better with its advanced tool set. 

    RenderDoc 1.9 was released on Wednesday and comes with support for pixel history and shader debugging along with various other enhancements and fixes. The Vulkan shader debugging with RenderDoc 1.9 covers SPIR-V shaders at vertex, fragment and compute shader stages. Meanwhile Google engineers contributed support for RenderDoc's Vulkan support to fetch pixel history. 

  • LLVMpipe Gallium3D Driver Now Exposes OpenGL 4.3

    It was just at the start of July that the LLVMpipe software driver gained OpenGL 4.0 support at long last. Days after that milestone OpenGL 4.2 support was reached for this driver that offers OpenGL acceleration atop CPUs either for fallback purposes or a vendor-neutral debug path. Now just days before the Mesa 20.2 branching, OpenGL 4.3 support has been cleared! 

    With Mesa 20.2 coming out around the end of August, that now takes this Gallium3D software rasterizer from OpenGL 3.3 to OpenGL 4.3 (or possibly even GL 4.4)! Red Hat's David Airlie who has been leading the charge on LLVMpipe added the remaining bits today for being able to expose OpenGL 4.3 with LLVMpipe. Those bits included the OpenGL robust buffer access and also enabling OpenGL ES 3.2. 

Graphics: Shader Processing, RadeonSI, and NVIDIA/Nouveau CRC

Filed under
Graphics/Benchmarks

  • Shader Processing

    As I’ve touched upon previously, zink does some work in ntv to perform translations of certain GLSL variables to SPIR-V versions of those variables. Also sometimes we add and remove variables for compatibility reasons.

    The key part of these translations, for some cases, is to ensure that they occur on the right shader. As an example that I’ve talked about several times, Vulkan coordinates are different from GL coordinates, specifically in that the Z axis is compressed and thus values there must be converted to perform as expected in the underlying Vulkan driver. This means that gl_Position needs to be converted before reaching the fragment shader.

  • RadeonSI Lands Bits In Mesa 20.2 For Better Dealing With GPU Virtualization

    Well known open-source AMD graphics driver developer Marek Olšák has landed a set of 15 patches into Mesa 20.2 for improving the RadeonSI driver's handling within virtualized environments.

    The support added is mid-command buffer preemption and when enabled is mirroring registers in memory using a register shadowing technique. This is being done so that the GPU can switch to a different process at any point within command buffers.

  • Open-Source NVIDIA "Nouveau" CRC Support Ready For Linux 5.9

    Stemming from documentation released by NVIDIA last year, the forthcoming Linux 5.9 kernel will feature CRC support on the display side thanks to the development work by Red Hat.

    Nouveau CRC support is coming in Linux 5.9 for Fermi and newer. This is about Cyclic Redundancy Checks (CRC) for error detection in the display handling on NVIDIA graphics cards.

Syndicate content

More in Tux Machines

Android Leftovers

KDE Frameworks 5.73 Released with Many Changes to Breeze Icons, Kirigami and KNewStuff

KDE Frameworks 5.73 is a monthly update to the open-source software suite, but it packs a lot of interesting changes. For example, the Kirigami UI builder received a new FlexColumn component and now supports action visibility in the GlobalDrawer, along with optimizations to the mobile layout and to the accessibility of the Kirigami input fields. The Breeze icon theme saw a lot of changes too during the development cycle of KDE Frameworks 5.73, and it now comes with a bunch of new icons for Kontrast, kirigami-gallery, snap-angle, document-replace, SMART status, task-recurring, appointment-recurring, Overwrite action/button, and applications/pkcs12 mime type. Read more

Redo Rescue Backup and Recovery Live System Gets NFS Share Support, SSH Server

For those not in the know, Redo Rescue is a great, free and easy to use live Linux system based on Debian GNU/Linux that can help you whenever your computer is broken by letting you backup and restore an entire system in just a few minutes. For example, if your computer no longer boots after installing the recent BootHole patches for the GRUB2 bootloader, you can use Redo Rescue to repair the boot. Of course, there are a few other tools that can do the same, but Redo Rescue can also do bare metal restores by replacing the MBR and partition table, re-map original data to a different target partition and even verify the integrity of an existing backup image. Read more

Pocket P.C. design files released as open source (handheld Linux computer)

The Popcorn Computers Pocket P.C. is designed to be a handheld Linux computer with a 4.95 inch full HD display, a built-in keyboard, and a ARM Cortex-A53 quad-core processor. First unveiled in November 2019, the Pocket P.C. hasn’t shipped yet. It’s still up for pre-order for $199 and up. But the developers have already open sourced the hardware by releasing the latest design files. You can find the at the project’s GitHub page. Read more