Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Benchmark results on mdds multi_type_vector

Filed under
Graphics/Benchmarks
LibO

One of the data structures included in mdds, called multi_type_vector, stores values of different types in a single logical vector. LibreOffice Calc is one primary user of this. Calc uses this structure as its cell value store, and each instance of this value store represents a single column instance.

Internally, multi_type_vector creates multiple element blocks which are in turn stored in its parent array (primary array). This primary array maps a logical position of a value to the actual block instance that stores it. Up to version 1.5.0, this mapping process involved a linear search that always starts from the first block of the primary array. This was because each element block, though it stores the size of the block, does not store its logical position. So the only way to find the right element block that intersects the logical position of a value is to scan from the first block then keep accumulating the sizes of the encountered blocks.

The reason for not storing the logical positions of the blocks was to avoid having to update them after shifting the blocks after value insertion, which is quite common when editing spreadsheet documents.

Of course, sometimes one has to perform repeated searches to access a number of element values across a number of element blocks, in which case, always starting the search from the first block, or block 0, in every single search can be prohibitively expensive, especially when the vector is heavily fragmented.

To alleviate this, multi_type_vector provides the concept of position hints, which allows the caller to start the search from block N where N > 0. Most of multi_type_vector’s methods return a position hint which can be used for the next search operation. This allows the caller to chain all necessary search operations in such a way to only scan the primary array once for the entire sequence of search operations. The only prerequisite is that access to the elements occur in perfect ascending order. For the most part, this approach worked quite well.

Read more

Also: Phoronix Test Suite 9.2.1 Released

Mesa 19.3.0 Released

Filed under
Graphics/Benchmarks
  • Mesa 19.3.0 Release Notes / 2019-12-12

    Mesa 19.3.0 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 19.3.1.

    Mesa 19.3.0 implements the OpenGL 4.6 API, but the version reported by glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. Some drivers don't support all the features required in OpenGL 4.6. OpenGL 4.6 is only available if requested at context creation. Compatibility contexts may report a lower version depending on each driver.

    Mesa 19.3.0 implements the Vulkan 1.1 API, but the version reported by the apiVersion property of the VkPhysicalDeviceProperties struct depends on the particular driver being used.

  • Mesa 19.3 Released With Big Updates For Intel's Open-Source Drivers, Valve ACO Option

    After a few weeks worth of delays due to blocker bugs the release of Mesa 19.3 is out today as a big end-of-year upgrade to the open-source OpenGL and Vulkan drivers for Linux systems. Intel and AMD Radeon driver changes largely dominate the work as always but there is a growing number of embedded driver changes and other enhancements for this crucial piece to the open-source 3D ecosystem.

Nvidia Linux/BSD Graphics Driver Adds Support for Quadro T2000 with Max-Q Design

Filed under
Graphics/Benchmarks
Linux
BSD

Coming just three weeks after the Nvidia 440.36 driver, which introduced support for the Nvidia GeForce GTX 1650 SUPER graphics card, the Nvidia 440.44 graphics driver is here to add support for the Nvidia Quadro T2000 with Max-Q Design graphics card on Linux, BSD, and Solaris systems, as well as support for the __GL_SYNC_DISPLAY_DEVICE environment variable for Vulkan apps on GNU/Linux systems.

The Nvidia 440.44 proprietary graphics driver also improves installation support on Oracle Linux 7.7 systems where the Nvidia kernel module could fail to build with the "unknown type name 'vm_fault_t'" error, and addresses a bug discovered in an error handling path, which could cause a Linux kernel crash while loading the nvidia.ko module.

Read more

AMD Radeon RX 5500 XT Linux Performance

Filed under
Graphics/Benchmarks

AMD today is shipping the Radeon RX 5500 XT as the new sub-$200 Navi graphics card. This 7nm graphics card offers 22 compute units, 1408 stream processors, up to 5.6 TFLOPS of compute power, 4GB or 8GB GDDR6 video memory options, and built atop their modern RDNA architecture and supporting features in common with the RX 5700 series like PCIe 4.0 support. Here is a look at the initial Linux gaming performance of the AMD Radeon RX 5500 XT with various gaming benchmarks and Steam Play tests as well.

The Radeon RX 5500 XT 4GB version is launching at $169 USD while the Radeon RX 5500 XT 8GB version will command $199 USD. These price points put them comparable to the current Radeon RX 580 / 590 retail cards. AMD markets the RX 5500 XT as offering 1.6x the performance-per-Watt of the original Polaris Radeon RX 480 and designed for 1080p gaming to go up against NVIDIA's GeForce GTX 1650 SUPER graphics card.

Read more

Graphics: AMD, Intel, Vulkan/Flycast and NVIDIA

Filed under
Graphics/Benchmarks
  • AMD Publishes Vega 7nm ISA Documentation - 300 More Pages Of GPU Docs

    Beyond AMD's open-source graphics driver stack of the past decade, part of their original open-source plans have also involved providing public (NDA-free) GPU hardware documentation. That has come with time though the documentation drops are not coordinated in-step with code drops. Out today, for example, is the ISA documentation on Vega 7nm.

    Back in 2017 was the timely release of the Vega ISA documentation and earlier this summer was even the RDNA 1.0 ISA documentation but missing out until now was the Vega 7nm ISA documentation.

  • Intel's Iris Gallium3D Driver Continuing To See Performance Optimizations On Mesa 20.0

    With the current Mesa 19.3 there is the Intel Gallium3D driver generally performing much better than their "classic" i965 driver and for Mesa 20.0 it looks to only make more ground as it switches over to this driver by default.

    Beyond the recent build system changes for supporting an Intel Gallium3D default and building it as part of the default x86/x86_64 Gallium3D drivers with hopes of soon flipping the switch for Broadwell and newer, more performance optimizations are still being done.

  • Dreamcast emulator Flycast adds a Vulkan renderer

    There seems to be quite a lot of interest in Vulkan lately, as more projects begin using it. Now we have the Dreamcast emulator Flycast adding Vulkan support.

    In the technical blog post announcing it on the Libretro site, it gives a bit of brief history of the Dreamcast GPU and mentions the usual "less overhead, more reliability and better performance in many cases" when it comes to using Vulkan although it's a lot more complicated to use.

  • NVIDIA have two new Linux drivers available, one stable and one Vulkan Beta

    NVIDIA continue pushing their drivers forwards with two new Linux driver updates available. Let's take a quick look.

    First, the stable 440.44 driver release as part of their long-lived branch. This adds support for the Quadro T2000 with Max-Q Design, you can now use the "__GL_SYNC_DISPLAY_DEVICE" environment variable for Vulkan applications and it fixes a few bugs like tearing with a G-SYNC or G-SYNC Compatible monitor when you've got something running directly on a display (like VR).

Graphics: NVIDIA 440.44 Linux Driver, Microsoft Code, and WSL Performs Very Poorly

Filed under
Graphics/Benchmarks
  • NVIDIA 440.44 Linux Driver Brings Fixes, __GL_SYNC_DISPLAY_DEVICE Honored With Vulkan

    Out today is NVIDIA 440.44 as the latest stable Linux driver update in their new long-lived driver series. 

    Succeeding the 440.36 and 440.31 stable drivers, the 440.44 release isn't too exciting but at least NVIDIA should be introducing a new beta series shortly. 

  • Intel's OpenSWR OpenGL Software Rasterizer Pulls In Tessellator From Microsoft Direct3D Code

    OpenSWR is Intel's performance-minded software rasterizer for purposes like workstation visualizations and is where it outperforms the likes of LLVMpipe. This CPU-based OpenGL implementation can make use of not only AVX/AVX2 but also AVX-512 and other optimizations to support speedy CPU-based GL operations from laptops to Xeon Scalable hardware. Like LLVMpipe, OpenSWR does leverage LLVM in part. Those unfamiliar with this long-standing Intel open-source project can learn more at OpenSWR.org.

  • Windows Subsystem For Linux Performance At The End Of 2019

    Recently I wrapped up some benchmarks looking at the performance of Ubuntu on Microsoft's Windows Subsystem for Linux comparing WSL on Windows 10 Build 18362 (May 2019 Update) and then both WSL and WSL2 performance using the Windows 10 Build 19008 Insider's Preview (what will come as Windows 10 20H1 update) for looking at where the WSL performance is heading. Additionally, looking at the bare metal performance of Ubuntu 18.04 LTS for which the WSL instances were based plus Ubuntu 19.10. As well, for the Windows-compatible tests also looking at how the Windows performance itself was outside of WSL/WSL2.

Graphics: GraphicsFuzz, RadeonSI, Mesa, Corruption Issues and Unisoc

Filed under
Graphics/Benchmarks
  • Google Releases GraphicsFuzz 1.3 For Continuing To Fuzz GPU Drivers

    GraphicsFuzz is the project born out of academia a few years ago for fuzzing GPU drivers to find OpenGL / OpenGL ES (WebGL) driver issues. This work was ultimately acquired by Google and then open-sourced just over one year ago. Today marks the release of GraphicsFuzz 1.3.

    GraphicsFuzz these days is no longer about just OpenGL / GLES and GLSL shaders but also operating on SPIR-V shaders for consumption by Vulkan drivers. There are also GLSL/SPIR-V shader reducers in addition to the fuzzer that relies upon randomized metamorphic testing.

  • RadeonSI Driver Switches To NIR, Thereby Enabling OpenGL 4.6 By Default For AMD GPUs

    Mesa 20.0 due out in Q1'2020 is now the magical release that is set to switch on RadeonSI NIR usage by default in place of the TGSI intermediate representation. What makes this IR switch-over prominent is that OpenGL 4.6 is then enabled by default on this open-source Gallium3D driver supporting Radeon HD 7000 series GPUs and newer.

    Recently in Mesa 20.0-devel, RadeonSI plumbed in OpenGL 4.6 support but it was contingent upon enabling NIR due to sharing some code-paths with the NIR-built RADV Vulkan driver around the SPIR-V code. NIR is the intermediate representation that most Mesa OpenGL/Vulkan drivers are focusing on and is more versatile than the likes of TGSI, the traditional IR of Gallium3D that has been around a decade.

  • Mesa 19.3 Is Introducing A Lot Of Open-Source OpenGL + Vulkan Driver Improvements

    Mesa 19.3 could be released as soon as this week after being challenged by several delays over blocker bugs. This release should be making it out in the days ahead and is a fantastic Christmas gift to Linux desktop users and a big step-up for these OpenGL / Vulkan driver implementations as we end out 2019.
    Among the many changes to find with this quarterly Mesa3D update are finally having OpenGL 4.6 for Intel, initial Intel Gen12/Tigerlake support, Zink was merged for OpenGL on top of Vulkan, Radeon Vulkan ACO back-end added for better Linux gaming performance, many new Vulkan extensions supported on both the Intel and Radeon drivers, the Intel Gallium3D driver is now in excellent shape, there are more Intel performance optimizations, and a lot of other changes throughout.

  • Radeon OpenGL Linux Driver Gets Fix For Corruption Issues

    An issue affecting some Linux users with Radeon graphics for at least the last four months around graphics corruption problems when switching to newer versions of the Linux kernel have been resolved.

    On Linux 5.2+ have been reports of some graphics corruption issues in cases like web browsers. While the issue manifested with a kernel upgrade, the resolution is a change to the RadeonSI OpenGL driver. Besides the aforelinked DRM bug report, there has also been other similar bug reports like garbled graphics.

  • Unisoc Looking To Introduce A New DRM Display Driver For Mainline Linux

    Unisoc, the Chinese SoC provider for smartphones that is part of the Tsinghua Unigroup, has published a new open-source DRM display driver that ultimately they are looking to get into the mainline kernel.

    Out today is just the "request for comments" patches for this Unisoc "SPRD" Direct Rendering Manager display driver. The twelve thousand lines of driver code wire up their display controller, MIPI DSI, MIPI DPHY, and the Unisoc display subsystem. The patches were worked on by Unisoc with cooperation from Linaro. All of this driver work is on the display front as their SoCs for 3D/GPU capabilities rely upon Arm Mali and Imagination PowerVR IP.

Upstream Graphics: Too Little, Too Late

Filed under
Graphics/Benchmarks

Unlike the tradition of my past few talks at Linux Plumbers or Kernel conferences, this time around in Lisboa I did not start out with a rant proposing to change everything. Instead I celebrated roughly 10 years of upstream graphics progress and finally achieving paradise. But that was all just prelude to a few bait-and-switches later fulfill expectations on what’s broken this time around in upstream, totally, and what needs to be fixed and changed, maybe.

The LPC video recording is now released, slides are uploaded. If neither of that is to your taste, read below the break for the written summary.

Mission Accomplished

10 or so years ago upstream graphics was essentially a proof of concept for the promised to come. Kernel display modeset just landed, finally bringing a somewhat modern display driver userspace API to linux. And GEM, the graphics execution manager landed, bringing proper GPU memory management and multi client rendering. Realistically a lot needed to be done still, from rendering drivers for all the various SoC, to an atomic display API that can expose all the features, not just what was needed to light up a linux desktop back in the days. And lots of work to improve the codebase and make it much easier and quicker to write drivers.

There’s obviously still a lot to do, but I think we’ve achieved that - for full details, check out my ELCE talk about everything great for upstream graphics.

[...]

Also, there just isn’t a single LTS kernel. Even upstream has multiple, plus every distro has their own flavour, plus customers love to grow their own variety trees too. Often they’re not even coordinated on the same upstream release. Cheapest way to support this entire madness is to completely ignore upstream and just write your own subsystem. Or at least not use any of the helper libraries provided by kernel subsystems, completely defeating the supposed benefit of upstreaming code.

No matter the strategy, they all boil down to paying twice - if you want to upstream your code. And there’s no added return for the doubled bill. In conclusion, upstream first needs a business case, like the open source graphics stack in general. And that business case is very much real, except for upstreaming, it’s only real in userspace.

In the kernel, “upstream first” is a sham, at least for graphics drivers.

Thanks to Alex Deucher for reading and commenting on drafts of this text.

Read more

Graphics: Mesa, Vulkan and PipeWire

Filed under
Graphics/Benchmarks
  • ADriConf GUI Control Panel Support For Mesa Vulkan Drivers Is Brought Up

    One of the most frequent complaints we hear from Linux gamers running open-source GPU drivers is over the lack of the hardware vendors supporting any feature-rich control panels like they do on Windows. There are many Linux driver tunables exposed by these open-source graphics drivers, but often they can only be manipulated via command-line options, environment variables, boot parameters, and other less than straight-forward means especially for recent converts from Windows and other novice Linux users. ADriConf has been doing a fairly decent job as a third-party means of helping to improve the situation and now there is talk of it supporting Vulkan driver settings.

  • Vulkan 1.1.130 Released With New Tooling Extension

    The new extension with Vulkan 1.1.130 is VK_EXT_tooling_info. The VK_EXT_tooling_info extension is for letting the Vulkan application/game/engine query what development tools are running right now. In particular, this is for tools like RenderDoc and other Vulkan profilers/debuggers. This extension will offer some uniformity and assistance to developers in debugging potential compatibility issues between Vulkan tools and other problems.

  • New graphing tool for PipeWire debugging

    PipeWire, the new and emerging open source framework that aims to greatly improve the exchange and management of audio and video streams inside a Linux system, has seen a number of improvements and bug fixes over the past year. With many developers now actively contributing to it, PipeWire is maturing quickly and is well on its way to becoming the new standard.

    At Collabora, we have been busy helping clients work with PipeWire, notably Automotive Grade Linux who have chosen to adopt PipeWire for its implementation of the low-level platform audio service, replacing previous solutions like 4A, PulseAudio and AudioManager. Assisting early adopters such as AGL has brought us to design and implement new elements within PipeWire, such as the session & policy management component WirePlumber, which George Kiagiadakis presented in October at the GStreamer Conference in Lyon.

Clear Linux On The OnLogic Karbon 700 Boosted Performance By 13% Over Ubuntu With 141 Benchmarks

Filed under
Graphics/Benchmarks

Last month we reviewed the OnLogic Karbon 700 as a passively-cooled, industrial-grade PC powered by an eight-core / sixteen-thread Intel Xeon, 16GB of RAM, 512GB NVMe storage, and a plethora of connectivity options in suiting to industrial use-cases. The performance was great and even the thermal performance was very good for being a fan-less PC. In seeing how well other Linux distributions were panning out on the Karbon 700, I tested five popular Linux distributions on the Xeon Coffee Lake system and once again Intel's performance-optimized Clear Linux squeezed out much more performance potential.

Read more

Syndicate content