Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Graphics: Monado and Zink

Filed under
Graphics/Benchmarks
  • Monado Open-Source OpenXR Implementation Begins Working On Android - Phoronix

    Monado as the open-source OpenXR implementation has been working on support for Google's Android platform.

    Monado 0.4 adds initial support for Android to the extent that Android-supported OpenXR clients and demo applications are running on Android hardware. This also includes supporting Android orientation/acceleration sensors and other features of modern smartphones. OpenXR applications in VR mode with the likes of Google Cardboard and Daydream have also been tested.

  • Monado update: Passing conformance, Android support & more

    Monado 0.4 passes all of the OpenXR conformance tests with both OpenGL and Vulkan, on desktop with a simulated device.

    Monado is not yet an officially conformant OpenXR implementation because it did not go through Khronos' OpenXR conformance/adopter process, but because the OpenXR Conformance Test Suite is publicly available and Open Source, every user can run it on Monado themselves.

  • Mike Blumenkrantz: Bringing The Heat

    The biggest news of the day is that work is underway to merge some patches from Duncan Hopkins which enable zink to run on Mac OS using MoltenVK. This has significant potential to improve OpenGL support on that platform, so it’s awesome that work has been done to get the ball rolling there.

  • Zink Seeing macOS Support For OpenGL Over Vulkan Then MoltenVK On Top Of Metal - Phoronix

    The Zink Gallium3D driver that implements OpenGL on top of Vulkan has been on quite a roll recently... Beyond reaching OpenGL 4.6 support in yet-to-be-merged patches and passing ~97% of the Piglit OpenGL tests and increasingly good performance compared to Intel's OpenGL driver, the latest interesting milestone is seeing initial work on bringing Zink to macOS.

    Given Apple's been phasing out support for OpenGL (and OpenCL), Zink on macOS holds merit -- arguably even more so than Linux where there still is great OpenGL drivers available for all major hardware. With the forthcoming macOS 11.0 "Big Sur", the OpenGL support will ultimately be either in a poor state or outright removed. For several years now Apple has been pushing for the OpenGL/OpenCL deprecation in their software ecosystem to instead emphasize their in-house Metal API. But with there still being plenty of macOS software out there making use of OpenGL as well as use-cases like running Wine/CrossOver for Windows software on macOS, Zink on macOS is an interesting candidate moving forward.

Raspberry Pi 400 Keyboard PC Review and Benchmarks vs Raspberry Pi 4

Filed under
Graphics/Benchmarks
Reviews

Raspberry Pi 400 keyboard computer with Broadcom BCM2711C0 1.8 GHz processor has just launched, and we already published a teardown of the Raspberry Pi 400 hardware to check out the cooling solution and overall hardware design.

In this review, we’ll mostly focus on Raspberry Pi 400 and Raspberry Pi 4 differences, since both devices mostly rely on the same chips. After checking the different features, we’ll run Thomas Kaiser’s “SBC Bench” script to test thermal cooling and benchmark both RPi hardware platforms.

Read more

Also: Raspberry Pi 400 Teardown – Heat spreader and motherboard

Raspberry Pi 400 with Ubuntu support

Raspberry Pi 400 Keyboard Computer Features 1.8 GHz BCM2711C0 Processor

Benchmarking The Raspberry Pi 400 - A Raspberry Pi Keyboard Computer

Filed under
Graphics/Benchmarks

The Raspberry Pi Foundation is today announcing a new and unexpected single board computer: the Raspberry Pi 400. It's more of a single-keyboard computer that offers slightly higher performance than the Raspberry Pi 4.

The Raspberry Pi 400 is quite a nifty little device: it's a Raspberry Pi entirely within the keyboard. Thanks to the small form factor of the Raspberry Pi SBC, the keyboard isn't overly large either but roughly the size of a standard keyboard. The Raspberry Pi is cooled by a large aluminum block to act as a heatsink within the keyboard.

Read more

Graphics: Zink, Compute-Runtime and LLVMpipe/OpenGL 4.5

Filed under
Graphics/Benchmarks
  • Mike Blumenkrantz: Invalidation

    I’ve got a lot of exciting stuff in the pipe now, but for today I’m just going to talk a bit about resource invalidation: what it is, when it happens, and why it’s important.

    [...]

    Resource invalidation can occur in a number of scenarios, but the most common is when unsetting a buffer’s data, as in the above example. The other main case for it is replacing the data of a buffer that’s in use for another operation. In such a case, the backing buffer can be replaced to avoid forcing a sync in the command stream which will stall the application’s processing. There’s some other cases for this as well, like glInvalidateFramebuffer and glDiscardFramebufferEXT, but the primary usage that I’m interested in is buffers.

    [...]

    Currently, as of today’s mainline zink codebase, we have struct zink_resource to represent a resource for either a buffer or an image. One struct zink_resource represents exactly one VkBuffer or VkImage, and there’s some passable lifetime tracking that I’ve written to guarantee that these Vulkan objects persist through the various command buffers that they’re associated with.

    Each struct zink_resource is, as is the way of Gallium drivers, also a struct pipe_resource, which is tracked by Gallium. Because of this, struct zink_resource objects themselves cannot be invalidated in order to avoid breaking Gallium, and instead only the inner Vulkan objects themselves can be replaced.

  • Intel Compute-Runtime 20.43.18277 Brings Alder Lake Support - Phoronix

    Intel Compute-Runtime 20.43.18277 is out this morning as the latest version of the company's open-source graphics compute stack for HD/UHD/Iris/Xe Graphics on Linux with OpenCL and oneAPI Level Zero support.

    It was the previous Compute-Runtime release two weeks back that brought OpenCL 3.0 for Broadwell through Ice Lake with Gen12/Tigerlake having already seen CL 3.0 support as a new platform. That OpenCL 3.0 support is in good shape with this latest release and the stack remains at a "pre-release" level for its oneAPI Level Zero 1.0 support.

  • llvmpipe is OpenGL 4.5 conformant.

    (I just sent the below email to mesa3d developer list).

    Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
    driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
    is now official[1].

    Thanks to everyone who helped me drive this forward, and to all the
    contributors both to llvmpipe and the general Mesa stack that enabled
    this.

    Big shout out to Roland Scheidegger for helping review the mountain of
    patches I produced in this effort.

    My next plans involved submitting lavapipe for Vulkan 1.0, it's at 99%
    or so CTS, but there are line drawing, sampler accuracy and some snorm
    blending failure I have to work out.
    I also ran the OpenCL 3.0 conformance suite against clover/llvmpipe
    yesterday and have some vague hopes of driving that to some sort of
    completion.

    (for GL 4.6 only texture anisotropy is really missing, I've got
    patches for SPIR-V support, in case someone was feeling adventurous).

    Dave.

  • LLVMpipe Is Now Officially Conformant With OpenGL 4.5

    Beginning with Mesa 20.2 is OpenGL 4.5 support for LLVMpipe, the LLVM-based software rasterizer built as a Gallium3D driver. This succeeded LLVMpipe for years being limited to OpenGL 3.3. While the OpenGL 4.5 support has been enabled for weeks, The Khronos Group has now officially confirmed its implementation.

Graphics: Mesa, RadeonSI, Vulkan

Filed under
Graphics/Benchmarks
  • Mesa 20.3 Lands Rewritten AMD Zen L3 Cache Optimization - Phoronix

    You may recall going back to 2018 that well known open-source AMD Mesa driver developer Marek Olsak was working on Mesa optimizations around the AMD Zen architecture. In particular, better handling of Mesa for Zen's L3 cache design. A rewritten implementation of that has now landed along with some other improvements.

    Marek discovered his L3 cache topology code was incorrect and ended up rewriting it to "make Mesa on my AMD CPU faster." The code is catering to AMD Ryzen processors but it's also possible Xeon / multi-CPU systems could employ a similar optimization should anyone be interested in pursuing it.

  • RadeonSI Lands Optimization For Uber Shaders - Phoronix

    On top of the AMD Zen L3 cache optimizations hitting Mesa 20.3 today, Marek Olšák has also landed his RadeonSI Gallium3D driver code for optimizing OpenGL uber shaders.

    Marek added a "inline_uniforms" DriConf option to the RadeonSI driver that implements inlinable uniforms.

  • Intel starts publishing Vulkan Linux driver

    Intel's open-source developers have begun publishing their patches enabling their "ANC" Vulkan Linux driver to support Vulkan ray-tracing.

    [...]

    Intel’s other big-ticket items still to come in the near-term include extending the ANV driver to support compiling and dispatching OpenCL kernels, new SPIR-V capabilities, and generic pointer support.

    Also needed is the actual support for compiling ray-tracing pipelines, managing acceleration structures, dispatching rays, and the platform support.

    Intel is not going to go much further until the Khronos Group has firmed up their VK_KHR_ray_tracing extension. However some of this Intel-specific Vulkan ray-tracing code may prove useful to Mesa's Radeon Vulkan "RADV" driver as well.

Kernel: Linux 5.11, Linux 5.10, RCU...

Filed under
Graphics/Benchmarks
Linux
  • Linux 5.11 To Land Optimization That Helps IO_uring Performance - Phoronix

    At the start of October we mentioned a kernel optimization that can help IO_uring performance. Now as we approach the end of the month, Linux 5.11 is poised to land the optimization that especially helps out with threaded workloads.

    The change to task_work to use TIF_NOTIFY_SIGNAL when available is queued as part of the tip.git core/entry code ahead of the Linux 5.11 merge window opening in December. Currently TIF_NOTIFY_SIGNAL is wired up for x86/x86_64 while Jens is working on adding this support to other CPU architectures as well. We'll see how many architectures get supported in time for Linux 5.11 as once completing that work he'll be able to move on with a set of clean-ups.

  • Stupid RCU Tricks: Torturing RCU Fundamentally, Part III - Paul E. McKenney's Journal — LiveJournal

    Even more reading of the Linux-kernel Documentation/RCU/Design/Requirements/Requirements.rst file encounters RCU's memory-barrier guarantees. These guarantees are a bit ornate, but roughly speaking guarantee that RCU read-side critical sections lapping over one end of a given grace period are fully ordered with anything past the other end of that same grace period. RCU's overall approach towards this guarantee is shown in the Linux-kernel Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst file, so one approach would be to argue that these guarantees are proven by a combination of this documentation along with periodic code inspection. Although this approach works well for some properties, the periodic code inspections require great attention to detail spanning a large quantity of intricate code. As such, these inspections are all too vulnerable to human error.

    Another approach is formal verification, and in fact RCU's guarantees have been formally verified. Unfortunately, these formal-verification efforts, groundbreaking though they are, must be considered to be one-off tours de force. In contrast, RCU needs regular regression testing.

  • Stupid RCU Tricks: Torturing RCU Fundamentally, Parts IV and V - Paul E. McKenney's Journal — LiveJournal

    The first guarantee is trivially verified by inspection of the RCU API. The type of rcu_read_lock(), rcu_read_unlock(), synchronize_rcu(), call_rcu(), and rcu_assign_pointer() are all void. These API members therefore have no way to indicate failure. Even primitives like rcu_dereference(), which do have non-void return types, will succeed any time a load of their pointer argument would succeed. That is, if you do rcu_dereference(*foop), where foop is a NULL pointer, then yes, you will get a segmentation fault. But this segmentation fault will be unconditional, as advertised!

  • AMD Navi "Blockchain" Card Support Being Added To Linux 5.10

    Last week we were first to report on a PCI ID being added for a Navi 1 "Blockchain" graphics card without display outputs and seemingly focused on cryptocurrency mining. This card wasn't talked about at yesterday's Radeon RX 6000 series launch but that support is now on the way to the Linux 5.10 kernel.

    The code sent out last week added the new Navi 10 PCI ID and disabled DCN/VCN support for that ID with this card not having video acceleration or display functionality. Aside from that patch, AMD hasn't officially acknowledged this new part that is RDNA (1) and not to be confused with the forthcoming RDNA2 / RX 6000 series products.

AMD ROCm 3.9 and AMDVLK 2020.Q4.2 Vulkan Driver

Filed under
Graphics/Benchmarks
Hardware
  • AMD ROCm 3.9 Released With AOMP OpenMP Offloading Integrated - Phoronix

    A new version of the AMD Radeon Open eCosystem (ROCm) has been released on the same day as the company announcing the Radeon RX 6800/6900 series. Meet ROCm 3.9.

    While announced on the same day as the Big Navi RX 6800/6900 reveal, ROCm 3.9 has no mention of supporting these GPUs starting to ship in November. In fact, the Radeon RX 5000 "Navi 1" graphics cards are still not listed as supported with ROCm 3.9 with Vega/GFX9 still being listed as the latest hardware support.

  • AMDVLK 2020.Q4.2 Vulkan Driver Released - Phoronix

    As we hit the end of October AMD has issued their second open-source Vulkan driver code drop of the quarter with the AMDVLK 2020.Q4.2 availability.

    Listed with this morning's AMDVLK 2020.Q4.2 update is just updating against Vulkan API 1.2.157 and fixing a GPU hang that can occur with DOOM Eternal running under Steam Play. That's it as far as the listed changes go for today's update.

Graphics: Wayland, Radeon, and Mesa

Filed under
Graphics/Benchmarks
  • Sony Engineer Talks Up Using Flutter + Wayland For Their Embedded Interfaces - Phoronix

    A Sony engineer confirmed at this week's Embedded Linux Conference Europe that the company has begun using the Flutter toolkit atop Wayland as their means of developing user-interfaces on embedded systems.

    Hidenori Matsubayashi of Sony talked at ELCE 2020 about their evaluation of different GUI toolkits for embedded use and ultimately how they fell for Flutter and Wayland. They came to that decision when evaluating the likes of Electron, Qt, GTK, WebKit/Chromium with WebView, and the many other options out there.

    Their design requirements were needing to be able to make "beautiful" user interfaces, support easy development, exhibit low CPU and RAM requirements, work across display servers and software stacks, and the toolkit must allow use within proprietary software.

  • Linux Support Expectations For The AMD Radeon RX 6000 Series

    Lisa Su is about to begin the presentation unveiling the much anticipated Radeon RX 6000 "Big Navi" (RDNA 2) graphics cards. This article will be updated live as the event progresses but first up let's recap the current Linux open-source driver state for these forthcoming graphics cards.

    Under the codename Sienna Cichlid, the Linux support for the next-generation Navi graphics cards have been underway going back to the middle of the year. There is initial support for the next-gen hardware within the recent released Linux 5.9 kernel and Mesa 20.2. This still puts it just out-of-reach for seeing out-of-the-box support in the likes of Ubuntu 20.10 given the 5.8 kernel so the user must manually move to the newer kernel. At least with the likes of Fedora Workstation 33 there will be Linux 5.9 as a stable release update. Also important to the driver equation is needing to be using LLVM 11.0+ for the GFX10.3 back-end target and also ensuring to have the latest linux-firmware for the binary microcode files needed for GPU initialization.

    So at least going into this launch it's great there is at least open-source driver support available but not necessarily easy reach for all users right now. By the time of the spring 2021 Linux distributions like Ubuntu 21.04 there should be nice out-of-the-box support for those wanting good support without any hassles. Or if you are on an enterprise distribution like RHEL/CentOS or SUSE Linux Enterprise or Ubuntu 20.04 LTS, AMD should be providing their usual Radeon Software for Linux packaged driver that ships updated user and kernel-space components for deploying their driver that way.

  • Mesa 20.3 Supports Intel Alder Lake Gen12 Graphics - Phoronix

    Last week Intel open-source engineers began publishing Linux kernel patches for the "Alder Lake S" graphics support. That work should be found in the Linux 5.11 cycle being christened as stable in early 2021. In user-space, Alder Lake graphics patches also appeared for their OpenCL / oneAPI Level Zero compute stack and now merged into Mesa 20.3 as well for OpenGL / Vulkan support.

    Given that Alder Lake is using Intel Xe "Gen12" graphics as found already for Tiger Lake and Rocket Lake, the actual driver-side enablement is quite minimal thanks to employing the existing code paths. The Alder Lake "ADL-S" support was merged into Mesa on Tuesday and is just 20 lines of new code. That consists of just adding the new PCI IDs and then the family bits for the Alder Lake family and indicating they make use of Gen12 features.

A Look At The Performance Improvements With System76 Pop!_OS 20.10

Filed under
Graphics/Benchmarks

At the end of last week System76 released Pop!_OS 20.10 as their customized distribution built atop Ubuntu 20.10 Groovy Gorilla. For those curious here are some benchmarks of System76's Pop!_OS 20.10 versus 20.04 using the Thelio Major with AMD Ryzen Threadripper 3990X and Radeon RX 5700 XT graphics.

Pop!_OS 20.10 has similar key package versions to Ubuntu 20.10 for which it is based: the Linux 5.8 kernel is at play, GNOME Shell 3.38.1, X.Org Server 1.20.8 by default, Mesa 20.2.1, GCC 10.2, Python 3.8.6, and numerous other package updates.

Read more

Samsung 980 PRO PCIe 4.0 NVMe SSD Linux Performance

Filed under
Graphics/Benchmarks

The Samsung 980 PRO PCIe 4.0 NVMe solid-state drives are now available from Internet retailers. For those wondering how these SSDs compare with EXT4 under Linux against other PCIe 4.0/3.0 drives, here are a variety of benchmarks.

While Samsung hasn't sent out NVMe SSDs for Linux testing at Phoronix, we continue purchasing the new models due to their high performance state and needing some additional drives for various systems in the lab. When the Samsung 980 PRO reached retail channels this month I picked up the Samsung 980 PRO 500GB and 1TB drives and ran a series of benchmarks on them prior to commissioning.

Read more

Syndicate content

More in Tux Machines

Connect to WiFi Using Terminal in Arch Linux and Other Distros

This quick guide explains the steps you need to set up and connect to WiFi using terminal in Arch Linux and other distros. Read more

Android Leftovers

New Systemd 247 Is Out For Linux Operating System As Major Release

Systemd, a controversial system and service manager for Linux operating systems, has a major version release as Systemd 247. Speaking of new changes, systemd 247 has added a new service called systemd-oomd to monitor and take action on processes when memory or swap goes above the configured limits. Systemd, a controversial system and service manager for Linux operating systems, has a major version release as Systemd 247. Speaking of new changes, systemd 247 has added a new service called systemd-oomd to monitor and take action on processes when memory or swap goes above the configured limits. Read more

Comparing the similarities and differences between inner source and open source

Open source software (OSS) has been around since the 1990s and has thrived, quickly growing to become mainstream. It is now more well understood around the world than it has ever been before. Some refer to it as FOSS to highlight the Freedom part of open source (Free and Open Source Software). And in 2014, at OSCON, the term "inner source" was debuted, and people started talking about how to use the principles of open source, but inside of a company. It raised several questions for those unfamiliar with the term, which I hope to answer with this article. For example, what is similar about the two, what is different, the company roles involved in the two, is inner source taking the energy away from open source, etc. These are all fair questions, and as my organization practices both and is involved in both movements, I want to take some time to share insight with this audience as a developer, as a company, and as an open source enthusiast. Read more