Language Selection

English French German Italian Portuguese Spanish

DXVK 1.2

Filed under
  • DXVK 1.2 is out, possible performance increase for CPU-bound scenarios and D3D11 extensions support

    Developer Philip Rebohle is continuing to advance DXVK, with another major release now available today.

    DXVK 1.2 includes a slight rework of command buffer submissions, to make them run on a separate thread. This should hopefully increase performance in times where you're CPU-bound. Additionally, command buffers are submitted more frequently, which should avoid some stalling and also increase GPU utilization.

  • DXVK 1.2 Released With Support For Direct3D 11 Vendor-Specific Extensions

    Just two weeks after the corrected DXVK 1.1 re-release debuted and DXVK 1.2 is now available.

    Philip Rebohle continues working on new features for this Direct3D 11 over Vulkan translation layer that's used by the likes of Wine and most notable Valve's Steam Play / Proton.

More in Tux Machines

today's howtos

KDE Frameworks 5.61, Applications 19.08 in FreeBSD

Recent releases were KDE Frameworks 5.61 and KDE Applications 19.08. These have both landed in the official FreeBSD ports tree, after Tobias did most of the work and I pushed the big red button. Your FreeBSD machine will need to be following current ports – not the quarterly release branches, since we don’t backport to those. All the modern bits have arrived, maintaining the KDE-FreeBSD team’s commitment to up-to-date software for the FreeBSD desktop. The one thing we’re currently lagging on is Qt 5.13. There’s a FreeBSD problem report tracking that update. Read more

Dev branch moving towards Qt 6

As you know, Qt 5.14 will be branched pretty soon. After that I would expect that most new development work would start to be aimed towards Qt 6. As it looks right now, 5.15 will be a smaller release where we polish what we have in 5.14, and prepare some things for Qt 6. To reflect that and help us all understand that the development focus is now towards Qt 6, I would like to propose that dev becomes the Qt 6 branch after we branched away 5.14 (and we merge wip/qt6 back into dev). We can then either create a 5.15 branch at the same time, or slightly later, once 5.14 has stabilised a bit more (e.g. after the beta or RC). Read more Also: Qt's Development Branch To Begin Forming Qt 6

Today in Techrights