Language Selection

English French German Italian Portuguese Spanish

Graphics: Second RC of Mesa 19.1.0, NVIDIA 430.14 Driver for Linux

Filed under
Graphics/Benchmarks
  • mesa 19.1.0-rc2
    Hello, list.
    
    The second release candidate for Mesa 19.1.0 is now available.
    
    Remind that right now there are two bugs blocking the final release:
    
    #110302 - [bisected][regression] piglit egl-create-pbuffer-surface and egl-gl-colorspace regressions
    #110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
    
    
    Bas Nieuwenhuizen (1):
          radv: Do not use extra descriptor space for the 3rd plane.
    
    Caio Marcelo de Oliveira Filho (1):
          anv: Fix limits when VK_EXT_descriptor_indexing is used
    
    Dave Airlie (1):
          kmsro: add _dri.so to two of the kmsro drivers.
    
    Dylan Baker (1):
          meson: Force the use of config-tool for llvm
    
    Eric Engestrom (1):
          travis: fix syntax, and drop unused stuff
    
    Gert Wollny (1):
          softpipe/buffer: load only as many components as the the buffer resource type provides
    
    Juan A. Suarez Romero (1):
          Update version to 19.1.0-rc2
    
    Józef Kucia (1):
          radv: clear vertex bindings while resetting command buffer
    
    Kenneth Graunke (5):
          i965: Fix BRW_MEMZONE_LOW_4G heap size.
          i965: Force VMA alignment to be a multiple of the page size.
          i965: leave the top 4Gb of the high heap VMA unused
          i965: Fix memory leaks in brw_upload_cs_work_groups_surface().
          iris: Use full ways for L3 cache setup on Icelake.
    
    Leo Liu (1):
          winsys/amdgpu: add VCN JPEG to no user fence group
    
    Lionel Landwerlin (4):
          anv: rework queries writes to ensure ordering memory writes
          anv: fix use after free
          anv: Use corresponding type from the vector allocation
          vulkan/overlay: keep allocating draw data until it can be reused
    
    Marek Olšák (1):
          st/mesa: fix 2 crashes in st_tgsi_lower_yuv
    
    Rob Clark (1):
          freedreno/ir3: fix rasterflat/glxgears
    
    Samuel Pitoiset (1):
          radv: fix setting the number of rectangles when it's dyanmic
    
    Timothy Arceri (1):
          Revert "glx: Fix synthetic error generation in __glXSendError"
    
    Tomeu Vizoso (2):
          panfrost: Fix two uninitialized accesses in compiler
          panfrost: Only take the fast paths on buffers aligned to block size
    
    git tag: mesa-19.1.0-rc2
  • Mesa 19.1-RC2 Released For Testing With The Latest Intel & Radeon Driver Fixes

    We are coming up on the Mesa 19.1 quarterly feature release hopefully by the end of the month while out today is the second release candidate for evaluating this next big update to these OpenGL and Vulkan driver implementations.

  • NVIDIA 430.14 driver released, DiRT 4 and Wolfenstein II: The New Colossus (Steam Play) get improvements

    NVIDIA today pushed out the 430.14 stable driver, it comes with a few notable improvements but it's quite a small release overall.

    This time around they named two titles specifically seeing driver improvements. They noted that DiRT 4 with Vulkan, a more recent Linux port from Feral Interactive should see improvements with Vulkan. Additionally, Wolfenstein II: The New Colossus when played in Steam Play should see performance improvements thanks to "support for presentation from queue families which only expose VK_QUEUE_COMPUTE_BIT" and it also adds support for the Quadro P2200.

  • NVIDIA 430.14 Linux Driver Improves Vulkan Performance For DiRT 4, Steam Play Games

    NVIDIA released the 430.14 Linux driver today as their first non-beta driver build in this 430 branch.

    This new driver builds on the earlier 430.09 beta driver like better VDPAU interoperability while now having some performance optimizations around DiRT 4 that is powered on Linux by Vulkan. There are also various other Vulkan driver improvements to help Steam Play games like Wolfenstein II: The New Colossus.

Nvidia 430.14 Linux Driver Improves Performance for DiRT 4

  • Nvidia 430.14 Linux Driver Improves Performance for DiRT 4 and Wolfenstein II

    Nvidia has released today new long-lived stable graphics drivers for Linux, BSD, and Solaris systems to add a bunch of various enhancements, bug fixes, and performance improvements for some games.
    The Nvidia 430.14 display driver is now available for Linux-based operating system with performance improvements for the DiRT 4 video game, which was ported last month by UK-based video games publisher Feral Interactive to Linux and Mac platforms, as well as for the Wolfenstein II: The New Colossus first-person shooter video game, which is available as a Steam Play title.

    The Nvidia 430.14 display driver also adds new functionality to the Nvidia VDPAU driver, including support for decoding HEVC YUV 4:4:4 streams, new per-decoder profile capability, support for accessing YUV 4:4:4 surfaces, support for creating YUV 4:4:4 video surfaces, and support for allocating VDPAU video surfaces with explicit frame or field picture structure.

Nvidia 430.14 Linux Driver Improves Performance for DiRT 4

  • Nvidia 430.14 Linux Driver Improves Performance for DiRT 4 and Wolfenstein II

    The Nvidia 430.14 display driver is now available for Linux-based operating system with performance improvements for the DiRT 4 video game, which was ported last month by UK-based video games publisher Feral Interactive to Linux and Mac platforms, as well as for the Wolfenstein II: The New Colossus first-person shooter video game, which is available as a Steam Play title.

    The Nvidia 430.14 display driver also adds new functionality to the Nvidia VDPAU driver, including support for decoding HEVC YUV 4:4:4 streams, new per-decoder profile capability, support for accessing YUV 4:4:4 surfaces, support for creating YUV 4:4:4 video surfaces, and support for allocating VDPAU video surfaces with explicit frame or field picture structure.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Linux Foundation Statement on Huawei Entity List Ruling

Thank you for your inquiry regarding concerns with a member subject to an Entity List Ruling.[1] While statements in the Executive Order prompting the listing used language granting a broader scope of authority, the Huawei Entity List ruling was specifically scoped to activities and transactions subject to the Export Administration Regulation (EAR). Open source encryption software source code was reclassified by the US Department of Commerce, Bureau of Industry and Security (BIS) effective September 20, 2016 as “publicly available” and no longer “subject to the EAR.”[2] Each open source project is still required to send a notice of the URL to BIS and NSA to satisfy the “publicly available” notice requirement in the EAR at 15 CFR § 742.15( b ). Read more

Android Leftovers

Huawei Linux Laptop Driver Improvements On The Way

Huawei laptops have already worked well on Linux like the MateBook while further improvements are forthcoming, as is commonly the case for x86 laptops with various quirks and other non-standard support bits. A patch was sent out today for improving the Linux kernel's existing Huawei laptop driver and extending it from being just a WMI hot-keys driver to now being a platform driver with extra functionality. The added functionality to this Huawei-WMI Linux driver includes controlling the mic/mute LED, controlling battery charging thresholds, adjusting the Fn-lock state, and related functionality. Read more Also: Huawei laptop extras driver

Kernel: Wayland, NVIDIA and Linux Development (LWN)

  • Problems Being Investigated Under Wayland Itches Program, Including Gaming Performance
    Last week we wrote about a "Wayland Itches" program being devised by prolific open-source contributor Hans de Goede of Red Hat. The goal of this program is to address itches/paper-cuts/problems in using GNOME Shell atop Wayland. He's received a fair amount of feedback so far and has some early indications to share. Hans de Goede wrote two blog posts today outlining the early feedback to his Wayland Itches project. Two items he is going to look into initially are middle-click on title/header bar to lower the Window not working for native applications and sudo/pfexec not working on Wayland. For the sudo/pfexec support, Hans is planning to optionally support the ability for GUI apps to connect when running as root. That was rejected upstream before but his plan is for this to be an optional feature for enabling the xauth file for allowing XWayland as root by GNOME-Shell/Mutter.
  • NVIDIA 418.52.07 Linux Driver Wires In Two More Extensions
    NVIDIA today released the 418.52.07 Linux driver as an updated build intended for Vulkan developers with it introducing support for two more extensions.
  • BPF: what's good, what's coming, and what's needed
    The 2019 Linux Storage, Filesystem, and Memory-Management Summit differed somewhat from its predecessors in that it contained a fourth track dedicated to the BPF virtual machine. LWN was unable to attend most of those sessions, but a couple of BPF-related talks were a part of the broader program. Among those was a plenary talk by Dave Miller, described as "a wholistic view" of why BPF is successful, its current state, and where things are going. Years ago, Miller began, Alexei Starovoitov showed up at a netfilter conference promoting his ideas for extending BPF. He described how it could be used to efficiently implement various types of switching fabric — any type, in fact. Miller said that he didn't understand the power of this idea until quite a bit later.
  • The first half of the 5.2 merge window
    When he released the 5.1 kernel, Linus Torvalds noted that he had a family event happening in the middle of the 5.2 merge window and that he would be offline for a few days in the middle. He appears to be trying to make up for lost time before it happens: over 8,300 non-merge changesets have found their way into the mainline in the first four days. As always, there is a wide variety of work happening all over the kernel tree.
  • DAX semantics
    In the filesystems track at the 2019 Linux Storage, Filesystem, and Memory-Management Summit, Ted Ts'o led a discussion about an inode flag to indicate DAX files, which is meant to be applied to files that should be directly accessed without going through the page cache. XFS has such a flag, but ext4 and other filesystems do not. The semantics of what the flag would mean are not clear to Ts'o (and probably others), so the intent of the discussion was to try to nail those down. Dan Williams said that the XFS DAX flag is silently ignored if the device is not DAX capable. Otherwise, the file must be accessed with DAX. Ts'o said there are lots of questions about what turning on or off a DAX flag might mean; does it matter whether there are already pages in the page cache, for example. He said that he did not have any strong preference but thought that all filesystems should stick with one interpretation. While Christoph Hellwig described things as "all broken", Ts'o was hoping that some agreement could be reached among the disparate ideas of what a DAX flag would mean. A few people think there should be no flag and that it should all be determined automatically, but most think the flag is useful. He suggested starting with something "super conservative", such as only being able to set the flag for zero-length files or only empty directories where the files in it would inherit the flag. Those constraints could be relaxed later if there was a need.
  • A filesystem for virtualization
    A new filesystem aimed at sharing host filesystems with KVM guests, virtio-fs, was the topic of a session led by Miklos Szeredi at the 2019 Linux Storage, Filesystem, and Memory-Management Summit. The existing solution, which is based on the 9P filesystem from Plan 9, has some shortcomings, he said. Virtio-fs is a prototype that uses the Filesystem in Userspace (FUSE) interface. The existing 9P-based filesystem does not provide local filesystem semantics and is "pretty slow", Szeredi said. The FUSE-based virtio-fs (RFC patches) is performing "much better". One of the ideas behind the new filesystem is to share the page cache between the host and guests, so there would be no data duplication for multiple guests accessing the same files from the host filesystem. There are still some areas that need work, however. Metadata and the directory entry cache (dcache) cannot be shared, because data structures cannot be shared between the host and guests. There are two ways to handle that. Either there can be a round trip from the guest to the host for each operation to ensure the coherence of the metadata cache and dcache, or the guest can cache that information and somehow revalidate the cache on each operation without going to the host kernel.
  • Common needs for Samba and NFS
    Amir Goldstein led a discussion on things that the two major network filesystems for Linux, Samba and NFS, could cooperate on at the end of day one of the 2019 Linux Storage, Filesystem, and Memory-Management Summit. In particular, are there needs that both filesystems have that the kernel is not currently providing? He had some ideas of areas that might be tackled, but was looking for feedback from the assembled filesystem developers. He has recently just started looking at the kernel NFS daemon (knfsd) as it is a lesser use case for the customers of his company's NAS device. Most use Samba (i.e. SMB). He would like to see both interoperate better with other operating systems, though.
  • NFS topics
    Trond Myklebust and Bruce Fields led a session on some topics of interest in the NFS world at the 2019 Linux Storage, Filesystem, and Memory-Management Summit. Myklebust discussed the intersection of NFS and containers, as well adding TLS support to NFS. Fields also had some container changes to discuss, along with a grab bag of other areas that need attention. Myklebust began with TLS support for the RPC layer that underlies NFS. One of the main issues is how to do the upcall from the RPC layer to a user-space daemon that would handle the TLS handshake. There is kernel support for doing TLS once the handshake is complete; hardware acceleration of TLS was added in the last year based on code from Intel and Mellanox, he said. RPC will use that code, but there is still the question of handling the handshake.