Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Graphics: Vulkan, FreeBSD and AMD

Filed under
Graphics/Benchmarks
  • Additional Intel "ANV" Vulkan Driver Performance Numbers For Gen11 Ice Lake Graphics

    Complementing the earlier Intel Ice Lake "Gen11" graphics comparison and the Windows vs. Linux Ice Lake graphics driver numbers, here are some additional Vulkan data points in different Linux and Steam Play games.

  • GPU Passthrough For FreeBSD's Bhyve Can Work But Is Fairly Rudimentary

    FreeBSD's Bhyve hypervisor has had a wild ride over the past half-decade of development for advancing BSD virtualization support. Bhyve is mostly used on the server front but can also fill some desktop use-cases now that there is GPU pass-through support working albeit not yet polished.

  • RADV Lands VK_EXT_subgroup_size_control For Exposing Wave32 On Navi/GFX10

    Valve open-source developer Samuel Pitoiset has landed his work enabling the Vulkan VK_EXT_subgroup_size_control extension that for GFX10/Navi is being used to expose Wave32 capabilities.

    Samuel's work has landed for this Vulkan extension that allows for a varying subgroup size and allows for compute shaders to use Wave32 as supported with GFX10 hardware. Another caveat though is the current implementation only works with the AMDGPU LLVM back-end and not yet the ACO shader back-end.

Xwayland randr resolution change emulation now available in Fedora 31

Filed under
Graphics/Benchmarks
Red Hat

As mentioned in an earlier blogpost, I have been working on fixing many games showing a small image centered on a black background when they are run fullscreen under Wayland. In that blogpost I was moslty looking at how to solve this for native Wayland games. But for various reasons almost all games still use X11, so instead I've ended up focussing on fixing this for games using Xwayland.

Xwayland now has support for emulating resolution changes requested by an app through the randr or vidmode extensions. If a client makes a resolution change requests this is remembered and if the client then creates a window located at the monitor's origin and sized to exactly that resolution, then Xwayland will ask the compositor to scale it to fill the entire monitor.

For apps which use _NET_WM_FULLLSCREEN (e.g. SDL2, SFML or OGRE based apps) to go fullscreen some help from the compositor is necessary. This is currently implemented in mutter. If you are a developer of another compositor and have questions about this, please drop me an email.

Read more

NVIDIA GeForce GTX 1660 SUPER Linux Gaming Performance

Filed under
Graphics/Benchmarks
Gaming

Last week NVIDIA announced the GeForce GTX 1660 SUPER as their newest Turing "SUPER" graphics card coming in at $229+ USD and delivering around 1.5x faster performance than the GeForce GTX 1060. For those wondering about the Linux gaming performance potential for this graphics card, here are our initial tests of this new graphics card using the EVGA GeForce GTX 1660 SUPER.

On launch day I purchased the EVGA GeForce GTX 1660 SUPER for carrying out these Linux benchmarks. The EVGA GeForce GTX 1660 SUPER (06G-P4-1068-KR) was in-stock on launch day and indeed hitting the $229 USD retail price. This graphics card features a dual fan setup and metal backplate. While the GTX 1660 SUPER reference specifications put the boost clock at 1785MHz, the EVGA model does advertise a possible 1830MHz boost clock frequency. The rest of the specs including 14Gbps 6GB GDDR6 video memory are in-line with the GTX 1660 SUPER specifications.

Read more

Nvidia Releases New Linux Graphics Driver with GeForce GTX 1660 SUPER Support

Filed under
Graphics/Benchmarks
Linux

Nvidia 440.31 is now available as the latest long-lived branch of the proprietary graphics driver for Linux, BSD, and Solaris platforms, adding support for the Nvidia GeForce GTX 1660 SUPER graphics card, parallel GLSL shader linking by default, support for HDMI 2.1 variable refresh rate (VRR), as well as support for the GL_NV_gpu_multicast and GLX_NV_multigpu_context extensions.

It also brings VP9 decode support to the Nvidia VDPAU driver, a new "SidebandSocketPath" X configuration option to control the folder where the X driver creates a pathname UNIX domain socket that's being used to communicate with the Nvidia OpenGL, Vulkan, and VDPAU driver components, and EGL support for PRIME render offload, and optimizes the GPU clock management strategy.

Read more

Also: NVIDIA 440.31 Linux Driver Adds HDMI 2.1 VRR Support, VP9 Decode, DXVK Fixes

Digilent Offers 2 Zynq-Based Linux Development Boards Supporting SYZYGY Expansion

Filed under
Graphics/Benchmarks
Linux

Digilent has announced two new SBCs that are ultra-high-speed and built to be more modular than its other boards. The company, which has a great deal of experience in Pmod lower speed FPGA standards has now entered the open-source, SYZYGY high-speed standards with its Eclypse Z7 and the Genesys ZU development SBCs.

We reported on the Zybo development board FPGA SoC from Digilent and that seems to have lead to the latest format for the Eclypse Z7.

Read more

AMD Navi 22 and Navi 23 Show Up In Linux Driver

Filed under
Graphics/Benchmarks
Linux

References to Navi 22 and Navi 23 silicon have been spotted inside a Linux driver by a 3DCenter forum veteran known as Berniyh (you can find them here and here). Could these be the high-end Navi parts Lisa Su was referring to in August?

Nvidia has been sitting peacefully alone in the premium graphics card market. Although AMD has already launched its Navi-based graphics cards (AMD Radeon RX 5700 and 5700 XT) the chipmaker still doesn't have an answer for Nvidia's high-end offerings, such as the GeForce RTX 2080 Super or RTX 2080 Ti. Berniyh's discovery doesn't mean big Navi is landing tomorrow, but it is coming.

Read more

Kernel and Graphics: Vulkan, NVIDIA Memory Compaction and Intel DRM Driver

Filed under
Graphics/Benchmarks
Linux
  • vkBasalt CAS Vulkan Layer Adds FXAA Support

    The open-source vkBasalt project is the independent effort implementing AMD Radeon Image Sharpening / Contrast Adaptive Sharpening technique as a Vulkan post-processing layer that can be used regardless of the (Vulkan-powered) game. With vkBasalt 0.1 also now comes the ability to apply FXAA.

    Fast Approximate Anti-Aliasing (FXAA) is the latest feature of vkBasalt besides the contrast adaptive sharpening. However, for the v0.1 release, CAS and FXAA cannot both be enabled at the same time. It's on the project TODO list for being able to enable both FXAA and CAS in a future release. Like the existing CAS support, the anti-aliasing technique can be used for any Vulkan game thanks to this being implemented as a post-processing layer for this graphics API.

  • mm: Proactive compaction
    For some applications we need to allocate almost all memory as
    hugepages. However, on a running system, higher order allocations can
    fail if the memory is fragmented. Linux kernel currently does on-demand
    compaction as we request more hugepages but this style of compaction
    incurs very high latency. Experiments with one-time full memory
    compaction (followed by hugepage allocations) shows that kernel is able
    to restore a highly fragmented memory state to a fairly compacted memory
    state within <1 sec for a 32G system. Such data suggests that a more
    proactive compaction can help us allocate a large fraction of memory as
    hugepages keeping allocation latencies low.
    
    For a more proactive compaction, the approach taken here is to define
    per page-node tunable called ‘hpage_compaction_effort’ which dictates
    bounds for external fragmentation for HPAGE_PMD_ORDER pages which
    kcompactd should try to maintain.
    
    The tunable is exposed through sysfs:
      /sys/kernel/mm/compaction/node-n/hpage_compaction_effort
    
    The value of this tunable is used to determine low and high thresholds
    for external fragmentation wrt HPAGE_PMD_ORDER order.
    
    Note that previous version of this patch [1] was found to introduce too
    many tunables (per-order, extfrag_{low, high}) but this one reduces them
    to just (per-node, hpage_compaction_effort). Also, the new tunable is an
    opaque value instead of asking for specific bounds of “external
    fragmentation” which would have been difficult to estimate. The internal
    interpretation of this opaque value allows for future fine-tuning.
    
    Currently, we use a simple translation from this tunable to [low, high]
    extfrag thresholds (low=100-hpage_compaction_effort, high=low+10%). To
    periodically check per-node extfrag status, we reuse per-node kcompactd
    threads which are woken up every few milliseconds to check the same. If
    any zone on its corresponding node has extfrag above the high threshold
    for the HPAGE_PMD_ORDER order, the thread starts compaction in
    background till all zones are below the low extfrag level for this
    order. By default. By default, the tunable is set to 0 (=> low=100%,
    high=100%).
    
    This patch is largely based on ideas from Michal Hocko posted here:
    https://lore.kernel.org/linux-mm/20161230131412.GI13301@dhcp22.suse.cz/
    
    * Performance data
    
    System: x64_64, 32G RAM, 12-cores.
    
    I made a small driver that allocates as many hugepages as possible and
    measures allocation latency:
    
    The driver first tries to allocate hugepage using GFP_TRANSHUGE_LIGHT
    and if that fails, tries to allocate with `GFP_TRANSHUGE |
    __GFP_RETRY_MAYFAIL`. The drives stops when both methods fail for a
    hugepage allocation.
    
    Before starting the driver, the system was fragmented from a userspace
    program that allocates all memory and then for each 2M aligned section,
    frees 3/4 of base pages using munmap. The workload is mainly anonymous
    userspace pages which are easy to move around. I intentionally avoided
    unmovable pages in this test to see how much latency we incur just by
    hitting the slow path for most allocations.
    
  • NVIDIA Engineer Continues Working On Proactive Memory Compaction For Linux

    NVIDIA's Nitin Gupta continues working on proactive compaction for the Linux kernel's memory management code.

    This proactive compaction is designed to avoid the high latency introduced right now when the Linux kernel does on-demand compaction when an application needs a lot of hugepages. With this proactive compaction, a large number of hugepages can be requested while avoiding high latencies.

  • Intel Submits Last Bits For Linux 5.5 DRM Driver - Includes More TGL/Gen12, Discrete Bit

    Intel's open-source crew has submitted the last of their feature updates to their "i915" Direct Rendering Manager graphics driver for staging in DRM-Next ahead of the upcoming Linux 5.5 kernel cycle.

    In the previous weeks they've been bringing up a lot of their Tiger Lake / Gen12 graphics code as the dominating theme for the Linux 5.5 kernel. There has also been Jasper Lake support, Xe multi-GPU prepping, and their other routine code clean-ups and driver improvements. Out this morning is the last of their feature work targeting Linux 5.5.

Kernel: Systemd Logo, VirtualBox Guest Shared Folder Support Coming to Mainline Linux Kernel, Intel's ANV Vulkan Driver

Filed under
Graphics/Benchmarks
Linux
  • Systemd Has A New Logo As Other Features Build Up For The Next Release

    The newest feature of systemd is... a new logo.

    At the end of September the quiet FreeDesktop.org Wiki was updated pointing to a new logo. As of Wednesday, the GitHub README was also updated with this new logo as well.

  • VirtualBox Guest Shared Folder Support Coming To The Mainline Linux Kernel

    The mainline Linux kernel continues to see better support for Oracle VM VirtualBox with more of the guest drivers reaching the mainline kernel to provide a vastly better out-of-the-box experience.

    Red Hat's Hans de Goede has been working to nurse many of the open-source VirtualBox drivers into the mainline kernel. The most recent is getting the "VBOXSF" driver queued into Greg KH's staging-linus branch. With it hitting the staging-linus branch overnight rather than staging-next, it's likely this VirtualBox VBOXSF driver is going to be sent in shortly as a fix/addition for the Linux 5.4 kernel cycle since there is little risk of regression.

  • Intel's ANV Vulkan Driver Overhauls Its Buffer Allocation Code

    With Mesa 19.3 having been branched yesterday, hitting Git master today as an early change for Mesa 20.0 is an overhaul to the Intel "ANV" open-source Vulkan driver's buffer object (BO) allocation code.

    The set of patches by Jason Ekstrand, one of Intel's original ANV Vulkan driver developers, changes their allocation code around so that now everything is allocated from the buffer object cache. With this fundamental change all allocations are within a single sparse array struct. This change ensures relocation updates can't crash, moving from a hash set to sparse array for buffer object tracking should be much faster ("this will be much more performant," says Jason), allows a lock in their softpin code to be removed, and is a code clean-up itself. With this change the Intel Vulkan driver is also zeroing out buffers on release to ensure the memory is cleared.

Vulkan Releases Unified Samples Repository

Filed under
Graphics/Benchmarks
  • Vulkan Releases Unified Samples Repository

    Today, The Khronos® Group releases the Vulkan ® Unified Samples Repository, a new central location where anyone can access Khronos-reviewed, high-quality Vulkan code samples in order to make development easier and more streamlined for all abilities. Khronos and its members, in collaboration with external contributors, created the Vulkan Unified Samples Project in response to user demand for more accessible resources and best practices for developing with Vulkan. Within Khronos, the Vulkan Working Group discovered that there were many useful and high-quality samples available already (both from members and external contributors), but they were not all in one central location. Additionally, there was no top-level review of all the samples for interoperability or compatibility. This new repository project was created to solve this challenge by putting resources in one place, ensuring samples are reviewed and maintained by Khronos. They are then organized into a central library available for developers of all abilities to use, learn from, and gain ideas.

  • The Khronos Group has launched a unified samples repository for Vulkan learning

    Today, The Khronos Group announced their newest Vulkan initiative with the Unified Samples Repository. A new place to find what they say are high-quality Vulkan code samples reviewed by their team.

    Made in response to user demand, to have an accessible place to learn Vulkan with working samples hopefully this might help increase adoption of the open graphics API. It's a big collaboration between Khronos, AMD, Arm, NVIDIA, Samsung, Sascha Willems and more.

  • Khronos Launches An Official Collection Of Vulkan Samples

    The Khronos Group has launched the Vulkan Unified Samples Repository, a Git repository on GitHub for Khronos-reviewed, high-quality Vulkan code samples.

    The Vulkan Unified Samples Repository aims to make it easier for new and existing Vulkan developers to dive into quality, open-source code samples.

Fedora 31 Performance Is Still Sliding In The Wrong Direction - Benchmarks Against Ubuntu 19.10 + Clear Linux

Filed under
Graphics/Benchmarks

The performance of Fedora 30 on multiple systems has generally been coming up short compared to the likes of Ubuntu, Clear Linux, and openSUSE Tumbleweed. With this week's release of Fedora 31 I was hopeful that the performance would be more competitive to other prominent Linux distributions, but sadly that doesn't appear to be the case. Here are some initial benchmarks of Fedora Workstation 31 compared to Fedora Workstation 30, Clear Linux 31450, and Ubuntu 19.10.

The performance of Fedora on recent releases has frankly not been too impressive. While Red Hat has been doing a lot to add more features to the Linux desktop and other new functionality throughout the stack, performance has seemingly not been a major focus for them in recent times. On many different AMD and Intel systems, the performance of Fedora has generally lagged behind the likes of Ubuntu, openSUSE Tumbleweed, and Debian Buster. Of course, also behind Intel's Clear Linux that tends to be the gold standard for x86_64 Linux performance.

Read more

Syndicate content