Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Graphics: Mir, X.Org, Gallium3D, GPUOpen, Mesa, Lima and Libinput

Filed under
Graphics/Benchmarks
Linux
  • Mir 1.6 Released With New Wayland, DispmanX Platform Support

    Mir 1.6 is out today with the latest batch of features for this Ubuntu-focused display server that offers Wayland client compatibility.

    The two big additions to Mir 1.6 are on the graphics platform front. First, there is now a "Wayland platform" for running Mir as a nested compositor on top of a Wayland compositor. Secondly, the rpi-dispmanx platform is for Broadcom's DispmanX API.

  • Before Ending 2019, Vintage SiS X.Org Driver Sees A New Release

    xf86-video-sis 0.12.0 is available this week as a new version of the SiS display driver for X.Org systems in supporting Silicon Integrated Systems' display hardware.

    This X.Org user-space mode-setting driver has seen its first update in four months but prior to that it hadn't seen any update to the open-source code in three years.

  • RadeonSI Lands SDMA Copy Support For Vega/GFX9

    The RadeonSI Gallium3D driver has finally landed SDMA copy support for Vega/GFX9 graphics hardware, which should principally benefit compute shaders and other cases.

  • AMD's GPUOpen Releases Vulkan Memory Allocator 2.3

    AMD's GPUOpen team has released their first official update to the open-source Vulkan Memory Allocator project in nearly one year.

    Vulkan Memory Allocator is an easy-to-use Vulkan memory allocation library that in the two and a half years since being open-sourced has been picked up for use by multiple games/engineers, Vulkan code samples, and other projects.

  • Chromium's Ozone Wayland Back-End Is Now Considered Beta, Aiming To Ship Next Year

    For years there has been work on a Wayland back-end to Ozone, the Google component for abstracting user-interface elements and input/window handling among other tasks across platforms. It looks like in 2020 the Ozone Wayland support will be in good standing and promoted out of beta.

    We were tipped off to a recent presentation by Igalia's Alexander Dunaev on their work contributing to the Ozone Wayland code. From consulting firm Igalia's perspective, they have been focused on bringing up Ozone Wayland support in the embedded Linux context considering the number of consumer devices now shipping that use Wayland and Chromium or CEF. But all their embedded Linux work for Ozone Wayland also benefits the Linux desktop.

  • Mesa Developers Weigh Renaming Gallium "State Tracker" To "API"

    Gallium3D state tracker terminology has been around a decade now in referring to the portions of the architecture that are ultimately implementing various graphics / compute / video APIs. Marek proposed keeping the Mesa OpenGL state tracker term but in renaming the other state trackers to being "API implementations" as that terminology is technically more accurate for the likes of Clover OpenCL, VA-API, VDPAU, and the other state trackers / APIs implemented.

  • Lima Gets Tiling While Vulkan Turnip Lands SSBO + Compute Shaders

    The Lima Gallium3D driver that supports older Mali 400/450 hardware with an open-source OpenGL driver hasn't been seeing too many improvements these days compared to the likes of the Panfrost Gallium3D driver for the newer Arm Mali Bifrost/Midgard architectures. But hitting Mesa 20.0-devel yesterday was tiling support for Lima. This should improve the performance for this open-source Mali driver and also end up working around the driver's broken mipmapping support for linear textures.

  • Libinput 1.15 Is On Approach With Various Improvements/Fixes For Linux Input Handling

    Peter Hutterer has been preparing libinput 1.15 as the next update to this open-source input handling library used by Linux systems both on X.Org and Wayland.

    Compared to past releases that have seen exciting changes on supporting new input devices like the Dell Totem, scrolling enhancements, and other major additions, there isn't too much of that with libinput 1.15.

Latest on Mesa Graphics

Filed under
Graphics/Benchmarks
  • mesa 19.3.0-rc6
    Hi list,
    
    Available today is mesa 19.3.0-rc6. Things are starting to slow down, and there
    are now only two open issues in the 19.3 milestone, so I'm hopeful that next
    week will bring 19.3.0 final, and not an rc7, but I can always be surprised.
    
    By far radv + aco dominate the list of changes, but there's also changes to anv,
    panfrost, core gallium, fixes for OpenBSD, iris, and nir.
    
    Dylan
    
    Shortlog
    ========
    
    Bas Nieuwenhuizen (2):
          radv: Unify max_descriptor_set_size.
          radv: Fix timeline semaphore refcounting.
    
    Boris Brezillon (2):
          gallium: Fix the ->set_damage_region() implementation
          panfrost: Make sure we reset the damage region of RTs at flush time
    
    Christian Gmeiner (1):
          etnaviv: remove dead code
    
    Daniel Schürmann (2):
          aco: don't split live-ranges of linear VGPRs
          aco: fix a couple of value numbering issues
    
    Dylan Baker (1):
          VERSION: bump version for 19.3-rc6
    
    Jason Ekstrand (1):
          anv: Set up SBE_SWIZ properly for gl_Viewport
    
    Jonathan Gray (2):
          winsys/amdgpu: avoid double simple_mtx_unlock()
          i965: update Makefile.sources for perf changes
    
    Jordan Justen (1):
          iris: Allow max dynamic pool size of 2GB for gen12
    
    Kenneth Graunke (2):
          driconf, glsl: Add a vs_position_always_invariant option
          drirc: Set vs_position_always_invariant for Shadow of Mordor on Intel
    
    Rhys Perry (5):
          aco: propagate p_wqm on an image_sample's coordinate p_create_vector
          aco: fix i2i64
          aco: add v_nop inbetween exec write and VMEM/DS/FLAT
          radv: set writes_memory for global memory stores/atomics
          nir/lower_io_to_vector: don't create arrays when not needed
    
    Samuel Pitoiset (2):
          radv: fix enabling sample shading with SampleID/SamplePosition
          radv/gfx10: fix implementation of exclusive scans
    
    
    git tag: mesa-19.3.0-rc6
    
  • Mesa 19.3 Might Release Next Week But For Now There's RC6 With Several ACO+RADV Fixes

    Mesa 19.3 continues running behind schedule but stands chances for releasing next week if the lingering blocker bugs are closed.

    Mesa 19.3-RC6 was released today as the newest weekly release candidate and it brought with it several random RADV fixes, a number of ACO compiler back-end fixes that also benefit RADV, a few Gallium3D fixes, an Intel Iris Gen12 fix, and a workaround for Shadow of Mordor on Intel graphics.

  • Mesa Devs Discuss Potentially Dropping Non-Gallium Drivers Or Forking Code For Gallium

    Longtime open-source AMD graphics driver developer Marek Olšák has kicked off a discussion over the possibility in the not too distant future of either dropping non-Gallium3D drivers from Mesa (and moving them off to a maintenance branch or the like) or forking some of Mesa's existing code to allow it to be better optimized for Gallium3D use-cases. Due to raised concerns, other possibilities are also being expressed like simply moving ahead with optimizing the Mesa code-base for Gallium3D at a cost of potentially hitting dead code more often with the classic drivers.

    As it stands now, the only relevant non-Gallium3D driver in the Mesa code-base is Intel i965. While that's currently the default Intel driver, for Broadwell "Gen8" graphics and newer they will be transitioning to their new Iris Gallium3D driver by default expected to happen for Mesa 20.0. The i965 driver will still be around for Haswell and older generations to come -- either within mainline Mesa or some maintenance branch. As part of this new Mesa discussion was a hypothetical comment about creating a new Intel Gallium3D driver for Haswell and older, but that's extremely unlikely to happen and was just brought up as a matter of being thorough. There aren't the extra resources available to create an Intel Gallium3D driver for aging Haswell and older hardware plus that it would likely take around a year to develop and even longer before reaching performance parity to i965.

  • Remove classic drivers or fork src/mesa for gallium?
    Hi,
    
    Here are 2 proposals to simplify and better optimize the GL->Gallium
    translation.
    
    1) Move classic drivers to a fork of Mesa, and remove them from master.
    Classic drivers won't share any code with master. glvnd will load them, but
    glvnd is not ready for this yet.
    
    2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main,
    mesa/vbo, mesa/program, and drivers/dri/common need to be forked and
    mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target
    location.
    
    Option 2 is more acceptable to people who want to keep classic drivers in
    the tree and it can be done right now.
    
    Opinions?
    
    Thanks,
    Marek
    

NVIDIA GeForce GTX 1650 SUPER Linux Performance

Filed under
Graphics/Benchmarks

For those looking to spend less than $200 USD on a graphics card, the recently launched NVIDIA GeForce GTX 1650 SUPER offers great value starting at $159 USD and working well with the NVIDIA Linux driver for providing decent 1080p Linux gaming performance as well as OpenCL / CUDA support. Here are benchmarks of the GTX 1650 SUPER alongside a total of 18 lower-end/mid-range AMD Radeon and NVIDIA GeForce graphics cards on Ubuntu Linux.

The NVIDIA GeForce GTX 1650 SUPER features 1280 CUDA cores, a reference 1530MHz base clock, 1725MHz boost clock, 4GB of GDDR6 video memory on a 128-bit bus, and other common NVIDIA Turing GPU features sans this being a GTX part and not RTX thus no RT cores.

Read more

Linux Graphics: RISC-V/Think Silicon, ELC Europe and Mesa

Filed under
Graphics/Benchmarks
  • Think Silicon® demonstrates early preview of Industry’s first RISC-V ISA based 3D GPU at the RISC-V Summit

    Think Silicon, recognized for the successful ultra-low power NEMA® GPU-Series for MCU driven SoCs, announced the demonstration of the industry’s first RISC-V ISA based 3D GPU -- the NEOX|V™. Attendees at the RISC-V Summit, in San Jose, California, will have the first opportunity to witness this new GPU innovation designed for the rapid deployment of Computer Graphics, Machine Learning and open GPGPU compute framework applications.

    Offering a myriad of flexible possibilities, NEOX|V ™ IP is designed to be easily configured for applications such as computer graphics, machine learning, vision/video processing and general-purpose compute. The new offering provides a platform for implementation in multiple embedded and external devices across many consumer and industrial vertical markets including Graphics, Compute, and AI for IoT/Edge/Compute.

  • NEOX V Announced By Think Silicon As First RISC-V 3D GPU

    While there has been the Libre RISC-V community-driven effort to create a RISC-V graphics processor that basically amounts to a RISC-V core with vector extensions/improvements and running a Vulkan software implementation (though they are now reportedly eyeing POWER instead of RISC-V), Think Silicon has announced the first actual RISC-V ISA based 3D graphics processor.

  • ELCE Lyon: Everything Great About Upstream Graphics

    At ELC Europe in Lyon I held a nice little presentation about the state of upstream graphics drivers, and how absolutely awesome it all is. Of course with a big focus on SoC and embedded drivers. Slides and the video recording

  • Mesa Adds Option For Changing Intel's OpenGL Driver Default

    While originally Intel planned to transition their OpenGL driver default to the modern "Iris" Gallium3D driver rather than the longstanding "i965" DRI driver for Mesa 19.3, that was pushed back to Mesa 20.0 for introduction in Q1'2020. In aiming to make that revised milestone a reality, a new option has been added to Mesa 20.0 with the Meson build system for being able to indicate the Intel OpenGL driver preference.

    The plan is for Mesa 20.0 to default to their new Gallium3D driver with Broadwell "Gen8" graphics and newer, including Icelake "Gen11". It's with Tiger Lake "Gen12" graphics where there is only support being implemented anyhow on this Gallium3D driver and not the older i965 OpenGL driver. As it stands right now when building Mesa, the i965 driver is used by default and then an environment variable allows overriding the driver to load in order to use Iris Gallium3D.

FreeBSD 12.1 Runs Refreshingly Well With AMD Ryzen Threadripper 3970X - Benchmarks Against Windows + Linux

Filed under
Graphics/Benchmarks

For those of you interested in AMD's new Ryzen Threadripper 3960X/3970X processors with TRX40 motherboards for running FreeBSD, the experience in our initial testing has been surprisingly pleasant. In fact, it works out-of-the-box which one could argue is better than the current Linux support that needs the MCE workaround for booting. Here are some benchmarks of FreeBSD 12.1 on the Threadripper 3970X compared to Linux and Windows for this new HEDT platform.

It was refreshing to see FreeBSD 12.1 booting and running just fine with the Ryzen Threadripper 3970X 32-core/64-thread processor from the ASUS ROG ZENITH II EXTREME motherboard and all core functionality working including the PCIe 4.0 NVMe SSD storage, onboard networking, etc. The system was running with 4 x 16GB DDR4-3600 memory, 1TB Corsair Force MP600 NVMe SSD, and Radeon RX 580 graphics. It was refreshing to see FreeBSD 12.1 running well with this high-end AMD Threadripper system considering Linux even needed a boot workaround.

Read more

Graphics: VirtIO-GPU and vkBasalt

Filed under
Graphics/Benchmarks
  • virtio gpu status and plans

    Time for a status update for virtio-gpu development, so lets go ...

    Before we begin: If you want follow development and discussions more closely head over to the virgl project at freedesktop gitlab. Git repos are there, most discussions are happening in gitlab issues.

    [...]

    Little change to reduce image data copying. Currently resources have a guest and a host buffer, and there are transfer commands to copy data between the two. Shared mappings allow the host to use the guest buffer directly.

    On the guest side this is pretty simple, the guest only needs to inform the host that a shared mapping for the given resource -- so the host might see changes without explicit transfer commands -- is fine.

    On the host side this is a bit more involved. Qemu will create a dma-buf for the resource, using the udmabuf driver. Which in turn allows qemu create a linear mapping of the resource, even if it is scattered in guest memory. That way the resource can be used directly (i.e. a pixman image created for it, ...)

    Status: Almost ready to be submitted upstream.

  • VirtIO-GPU Working Towards Vulkan Support, Other Features For Graphics In VMs

    Linux virtualization developer Gerd Hoffmann laid out some of the VirtIO-GPU happenings. Among the features being pursued are shared mappings to reduce image data copying, blob resources, metadata query for querying host render capabilities/requirements, host memory support to implement coherent memory and other features, and then lastly is the Vulkan support. But it's still likely to be some time until the Vulkan VirtIO-GPU/Virgl support is ready for any end-user usage.

  • vkBasalt, the Vulkan post-processing layer has another new release with new effects

    Adding a little extra visual enhancement to games on Linux is getting more interesting, with the help of the Vulkan post-processing layer vkBasalt which has a new build up.

    Recently, they put up a new build enabling SMAA support and yesterday another new version was released to expand it even further.

    Available in version 0.2.1 is a new "Deband/Dithering" effect and you can now also change SMAA settings in the configuration file. You might also see it having less of a performance impact, as the settings are now "applied at pipeline creation". There's also been some changes to the Shader Directory and Config File, with both having multiple possible locations where they can rest to help with distribution specific packages.

Windows 10 vs. Linux Performance On The AMD Ryzen Threadripper 3970X

Filed under
Graphics/Benchmarks

The new AMD Ryzen Threadripper 3970X is performing faster on Linux than Microsoft Windows 10. When carrying out more than 80 different tests on Windows 10 compared to five Linux distributions, Windows 10 was beat out by the open-source competition. However, the performance loss for Windows isn't as dramatic as we have seen out of earlier generations of Ryzen Threadripper HEDT workstations. Here are those benchmarks of Windows 10 compared to Ubuntu 19.10, CentOS 8, Clear Linux, Fedora Workstation 31, and openSUSE Tumbleweed.

This is our first cross-operating-system look at the Threadripper 3970X since it was released last week. All five tested Linux distributions installed fine when using the MCE workaround to boot. There were no other problems to report for hardware compatibility with this Zen 2 HEDT system on the different Linux distributions. The hardware used for all of this Windows/Linux testing was the AMD Ryzen Threadripper 3970X at stock speeds, ASUS ROG ZENITH II EXTREME TRX40 motherboard, 4 x 16GB Corsair DDR4-3600MHz memory, 1TB Corsair Force MP600 NVMe SSD, Radeon RX 580 graphics, NZXT Kraken water cooling, and a Thermaltake Toughpower 1250 Watt power supply.

Read more

Compiz Sees New Update Ahead Of The Holidays - But It's Mainly Bug Fixing

Filed under
Graphics/Benchmarks

Over a decade ago all the Linux desktop rage was over the likes of Compiz, Beryl, Compiz Fusion, and the like... Ah the memories. But to much surprise, Compiz saw a new release today. Compiz 0.9.14.1 isn't the most exciting update, but the project is still alive.

Back in February marked the release of Compiz 0.9.14 as the first upstream release to the project in two years. Meanwhile today is a point release on top of that providing various fixes.

Read more

Original message:

  • Compiz 0.9.14.1 released
    Yesterday I released Compiz 0.9.14.1.
    
    This is mostly a bug-fix release. The changes from 0.9.14.0 are:
    
    - Several bugs in CCSM have been fixed, including a crash when plugin
      descriptions contain non-ASCII characters.
    - Fixed build failure with GCC 9 because of format-truncation warning.
    - CCSM is now compatible with Python 3.8.
    - Fixed gtk-window-decorator crash with Cairo theme.
    - Removed MATE configuration. See the merge proposal [1] for details.
    
    Also, compiz is now translatable on Launchpad. Feel free to contribute on [2].
    The imported translation files are based on the previous work from Ubuntu.
    
    The tarball for the new release can be downloaded at [3].
    Please report any bugs you have found to our bug tracker [4].
    
    I want to thank Alberts Muktupāvels for his work on this release.
    
    [1]: https://code.launchpad.net/~muktupavels/compiz/+git/compiz/+merge/374783
    [2]: https://translations.launchpad.net/compiz
    [3]: https://launchpad.net/compiz/0.9.14/0.9.14.1
    [4]: https://bugs.launchpad.net/compiz/
    
    --
    Dmitry Shachnev
    

mesa 19.3.0-rc5

Filed under
Graphics/Benchmarks
Linux

Hi list,

Mesa 19.3.0-rc5 is now available as the latest release in the 19.3 series. This
is a pretty small release, likely due to tomorrow being a major US holiday. The
majority of the changes are for radv, but there's a few other bits and pieces
here too: v3d, r600, freedreno, and old intel, just to name a few.

Dylan

Shortlog
========


Alejandro Piñeiro (1):
      v3d: adds an extra MOV for any sig.ld*

Bas Nieuwenhuizen (2):
      radv: Do not change scratch settings while shaders are active.
      radv: Allocate cmdbuffer space for buffer marker write.

Dave Airlie (1):
      llvmpipe/ppc: fix if/ifdef confusion in backport.

Dylan Baker (1):
      VERSION: Bump version for -rc5

Eric Engestrom (1):
      vulkan: delete typo'd header

Gert Wollny (1):
      r600: Disable eight bit three channel formats

Hyunjun Ko (1):
      freedreno/ir3: fix printing output registers of FS.

Ian Romanick (1):
      intel/fs: Disable conditional discard optimization on Gen4 and Gen5

Jose Maria Casanova Crespo (1):
      v3d: Fix predication with atomic image operations

Timothy Arceri (3):
      radv: add some infrastructure for fresh forks for each secure compile
      radv: add a secure_compile_open_fifo_fds() helper
      radv: create a fresh fork for each pipeline compile

Yevhenii Kolesnikov (2):
      glsl: Enable textureSize for samplerExternalOES
      meson: Fix linkage of libgallium_nine with libgalliumvl

Zebediah Figura (1):
      Revert "draw: revert using correct order for prim decomposition."


git tag: mesa-19.3.0-rc5

Read more

Also: Mesa 19.3-RC5 Brings RADV Secure Compile Update, Other Fixes

Linux (Kernel) and Graphics Leftovers

Filed under
Graphics/Benchmarks
Linux
  • Linux 5.5 Staging Changes Land With New WiFi Driver To Improved exFAT Support

    Greg Kroah-Hartman mailed in the staging area changes today for the Linux 5.5 kernel and they have already been pulled into mainline.

    Among the staging activity work this cycle for Linux 5.5 includes:

    - The new WFX WiFi driver for Silicon Labs WF200 ASICs that are focused on low-power IoT hardware use-cases.

  • AMD's RadeonSI Driver Finally Enables OpenGL 4.6 But You Need To First Enable NIR

    The OpenGL 4.6 extension is nearly two and a half years old while finally the open-source Mesa OpenGL drivers are catching up to this latest OpenGL revision that offers Vulkan/SPIR-V interoperability and other additions.

    Last quarter's Mesa 19.2 release brought OpenGL 4.6 for core Mesa and Intel's i965/Iris drivers while tonight in Mesa 20.0-devel Git is support for RadeonSI! The AMD open-source OpenGL Linux driver can finally have GL 4.6!

  • AMDVLK 2019.Q4.3 Released With New Extensions + Navi 14 Support

    AMD's Vulkan driver team has today volleyed their third open-source "AMDVLK" code drop of the quarter. This AMDVLK 2019.Q4.3 driver comes with new extensions as well as Navi 14 enablement.

    Supported by AMDVLK 2019.Q4.3 is VK_EXT_pipeline_creation_feedback and VK_EXT_shader_demote_to_helper_invocation. EXT_pipeline_creation_feedback provides a feedback loop to the application/engine for use with pipeline caching as the principal benefit while the EXT_shader_demote_to_helper_invocation extension is for allowing behavior similar to Direct3D's HLSL discard instruction.

Syndicate content