Language Selection

English French German Italian Portuguese Spanish

DXVK 1.1 Released

Filed under
  • DXVK, the Vulkan-based layer for Direct3D 10/11 in Wine has a major 1.1 release out now

    DXVK, the awesome project that has helped push Linux gaming further has a new release out and it sounds pretty huge.

    Firstly, for Unreal Engine 4 titles (and several other unnamed games) DXVK 1.1 has "Queries" re-implemented which should allow for improved GPU utilization. The feature is widely used apparently, so it may help quite a number of games. DXVK also now comes with basic support for Predication based on the new query stuffs.

    Another major difference is that DXVK 1.1 uses "in-memory compression for shader code", which should result in games with a large number of shaders seeing reduced memory utilization. However, it may increase shader compile times "slightly". Games noted to benefit include Overwatch, Quake Champions and Dishonored 2 seeing "several hundred Megabytes of RAM" savings.

  • DXVK 1.1 Released With Vulkan Queries Work, Other Improvements

    DXVK 1.1 is out this weekend in time for some weekend Linux game testing. This library, which is used for implementing Direct3D 10/11 over Vulkan for the benefit of Windows games running on Linux under Wine/Proton (Steam Play), has new abilities and performance enhancements with today's update.

    DXVK 1.1 has performance improvements around Unreal Engine 4 games and other titles thanks to better GPU utilization via Vulkan queries. To benefit, systems need Wine 4.5+ or Proton 4.2+ and be running the NVIDIA 418.49.4 driver or Mesa 19.1-devel Git. There is also initial and basic support for predication via VK_EXT_conditional_rendering.

DXVK 1.1 rereleased

  • DXVK 1.0.3 Released Following The Recalled DXVK 1.1

    While DXVK 1.1 was released earlier this month, it ultimately was recalled due to game crashes and GPU hangs that are still being investigated. For now, DXVK 1.0.3 has been released as the latest and greatest version of this library for translating Direct3D 10/11 calls to make use of the Vulkan graphics API for Windows gaming on Linux with Wine/Proton.

    DXVK 1.0.3 back-ports some of the v1.1 material like exposing version information within the DXVK DLLs. There are also bug fixes in DXVK 1.0.3 around geometric shaders, passing of undefined data causing unexpected shader cache misses, and gracefully handling surface loss.

Comment viewing options

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

More in Tux Machines

today's howtos

Musiko – cross-platform music player

I spend most of the past few months listening to music. My favorite pastime is to see an eclectic range of bands, solo artists, and orchestras live. It’s such a life-changing and exhilarating experience. It’s one thing to be sitting at home listening to a CD or watching music videos on TV or on YouTube, but being in the audience, packed out in a stadium or music hall, takes it to another level. But it’s an expensive pastime, and still on hold given the current coronavirus pandemic. These days, I’m listening to music from my CD collection which I’ve encoded to FLAC, a lossless audio format. Linux is endowed with a plethora of open source music players. And I’ve reviewed the vast majority. But I seem to keep finding interesting music players. Musiko is the latest I’ve stumbled across. Musiko is a free to use, open source and cross platform music player. It supports a good range of audio formats including both lossy and lossless formats. Musiko uses JavaScript, Electron, VueJS, the music-metadata module and a few others. [...] Musiko definitely doesn’t get our recommendation. It’s really slow at loading in a fairly small music folder, it’s poorly designed, and offers only a fairly limited set of features. If it was the only music player available for Linux, it would be bearable to use. But there’s so many vastly better open source music players available. Our recommended GUI music player is Tauon Music Box. And if you prefer console based software, musikcube gets our seal of approval. But it’s really huge memory footprint consigns Musiko to the bin. With a subset of my music folder loaded, the program uses 1.8GB of RAM (as reported by ps_mem). That’s truly ridiculous. Just look how this memory footprint compares with Byte and other music players. Read more

Alan Pope (Canonical/Snap): Stepping Down Gracefully

The Snap Store has been designed to enable upstream developers and enthusiastic community contributors to publish snaps. As with most Linux packaging solutions, the wider community are often responsible for starting and maintaining software packages. This is a double-edged sword, especially for humans with limited life spans and other shiny things to steal their attention. If a community contributor decides to move on from maintaining software packaging, has too many other things on their plate, or life just gets in the way, it’s not necessarily a problem. Users are appreciative that someone packaged up their favourite application, but can get upset quickly if that software is no longer updated. Snap publishers who are overwhelmed or busy doing other things have some options here. [...] When the maintainer of a snap has decided to focus on other things, we can handle that too. Where possible, we recommend snap publishers transition their applications to another individual or organisation rather than let them become outdated. Ideally snaps should be published in the Snap Store by the upstream project. So the first port of call would be to offer to transition the snap upstream. Sometimes this isn’t possible if the developers are unable to take on the additional workload themselves, however small that might be. Alternatively we recommend seeking out another enthusiastic, trustworthy community member to take on the mantle of maintaining the snap package. Often just starting a conversation on the upstream issue tracker, or in their real-time chat of choice will yield good results. Someone keen may even be found within the wider community of the upstream project. If that fails, a further option would be to find someone within the snapcraft community. There are a group of dedicated snapcraft enthusiasts who love the challenge of maintaining new snaps, and taking on existing ones if necessary. They can be found in the snapcraft forums. Start a new thread, looking for a new maintainer, and typically one can be found. Once a new maintainer is found, the transition from one publisher to another can be actioned via the forums. Start a thread in the store-requests category indicating who the snap(s) are moving from, and who to. The store admins team can do the necessary validation checks behind the scenes, and move the snap(s) to their new home. It’s then up to the new maintainer to hook up whatever build or CI system is needed to seamlessly continue publishing of the snap. Note that when a snap is transferred, by default the previous maintainer is kept as a collaborator on the snap. They can continue to be involved but without being named as the publisher, or they can be removed as a collaborator, and no longer maintain the snap. So the take away from this is, if you’re feeling overwhelmed and need to offload maintainership of snaps to others, don’t panic. We can help, and our community can too. Read more

Android Leftovers