Sarek9-17 Released

Stable Build:

Changed the base of the Build to GE-Proton9-17 instead of GE-Proton9-16, all previous patches applied to Sarek9-16 are now working on Sarek9-17, including the ones for WineD3D, the Global Proton Prefix, and the Custom Parameters. The release as usual comes with DXVK 1.10.3 and VKD3D 2.6.

The only things added to this release are 2 new parameters, those being:

• PROTON_VK_SOFTWARE: Uses Lavapipe to enable CPU-based rendering for Vulkan, supporting API version 1.3.
• PROTON_OGL_SOFTWARE: Uses LLVMpipe to enable CPU-based rendering for OpenGL, supporting API version 4.6.

The software rendering options are more of a fallback, designed for cases when your GPU drivers are broken, really underperforming in OpenGL/Vulkan games, or lack support for specific APIs used by games or translation layers. While performance is predictably slow since the CPU handles rendering instead of the GPU these options can make some simple 3D or 2D games playable. For the best experience, try using the lowest resolution possible, as it helps a loot.

For example, I was able to run the Windows version of Terraria at 15-30 FPS on 800x600 window mode using the following parameters: PROTON_USE_WINED3D=1 PROTON_OGL_SOFTWARE=1 %command%. While the game didn’t launch with DXVK+Lavapipe, it worked with these settings. (I know there's a Linux version, but this was a test.) This was all on an old office PC with an i5-2400 CPU, 4GB of RAM, and a very outdated NVIDIA GPU.

Based on testing, WineD3D with LLVMpipe seems to work with all games that are already compatible with WineD3D on a GPU. In contrast, DXVK with Lavapipe encounters issues, with some games failing to launch, likely due to Lavapipe incomplete support for certain Vulkan extensions. Additionally, the PROTON_TWEAKS parameter is enabled by default to optimize performance as much as possible. Ideally, you won’t have to depend on software rendering, but if you do, I hope this setup will at least make some games playable.

Requirements for Using Lavapipe (Vulkan Software Rendering)

• Mesa Version: 20.3 or newer
• CPU: Multi-core recommended for better performance

Requirements for Using LLVMpipe (OpenGL Software Rendering)

• Mesa Version: Any recent version (LLVMpipe is well-supported in current Mesa releases)
• CPU: Multi-core recommended for better performance

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Release:

Sarek9-16 Released

Stable Build:

Changed the base of the Build to GE-Proton9-16 instead of GE-Proton9-15, all previous patches applied to Sarek9-15-r3 are now working on Sarek9-16, including the ones for WineD3D and the Global Proton Prefix. The release as usual comes with DXVK 1.10.3 and VKD3D 2.6.

This work is primarily to bring the new build in line with the older releases, but 9-16 will also come with new features. Specifically, it introduces some customs Proton parameters designed to squeeze every last bit of performance from your PC. How does it work? It’s simple when you call one of these parameters, it sets multiple environment variables aimed at boosting performance.

So, why aren’t these enabled by default?

Because many of these parameters act as "double-edged swords." While they can improve performance, they may also have trade-offs. For example, __GL_THREADED_OPTIMIZATIONS=1 and mesa_glthread=1 are usually helpful in CPU-bound applications but can reduce performance in games that rely on synchronous OpenGL calls. Other tweaks might affect the visual quality of a game or introduce instability. That’s why we’re offering these optimizations as optional settings instead of making them default, you get better performance, but there might be some compromises.

So far, the parameters added are:

• PROTON_TWEAKS: Enables all other tweaks.
• PROTON_TWEAKS_PROTON: Enables Proton/Wine-specific optimizations.
• PROTON_TWEAKS_NVIDIA: Optimizations specifically for NVIDIA proprietary drivers.
• PROTON_TWEAKS_MESA: Optimizations for Mesa drivers.

One of the reasons why we separate it its because you can perfectly lose performance on for example the NVIDIA part but win on the PROTON part, this its unusual but it can happen, so instead of PROTON_TWEAKS being the only option we decided to brake it down to various other parameters and that PROTON_TWEAKS call them all. Activate them its as simple as add Parameter_Name=1 as a parameter on the Steam Launch parameters, remember to write the %command% on the end :).

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Benchmarks:

Here are 2 benchmarks in witch i compare the performance of having PROTON_TWEAKS on and off:
AMD Benchmark
NVIDIA Benchmark (With Proprietary Drivers)

Release:

Sarek9-15-r3 Released

Stable Build:

The third revision of Sarek9-15, so what has been done?

VKD3D has been downgraded from version 2.8 to 2.6, for compatibility with the NVIDIA 470 Drivers. Other than this VKD3D downgrade, the 9-15-r3 release remains the same as 9-15-r2 in all other aspects.

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Why DXVK Async?
The main reason is performance. DXVK Async enables asynchronous shader compilation, while the regular DXVK uses synchronous compilation. In regular DXVK, when a game encounters new shaders, they are compiled synchronously, causing brief stutters or freezes as the game waits for the compilation to finish. In contrast, DXVK Async compiles shaders in the background, allowing the game to continue running, though there may be minor graphical artifacts until compilation is complete.

So why isn't it in the normal version?
While DXVK Async significantly improves performance by reducing stuttering, it poses a potential risk of triggering client-side anti-cheat systems in multiplayer games. This risk arises because the tool alters shader handling, which might be viewed as cheating by some anti-cheat software. Although there haven’t been confirmed bans for using DXVK Async, the possibility remains, and I personally wouldn’t risk my Steam account for it.

What its being tested now:

We are currently testing a feature that could be ideal for users looking to squeeze every bit of performance from their PCs. We're making a new Proton parameter for Sarek, which, when enabled, will apply a set of optimizations through environment variables. Instead of having to manually add parameters like parameter1 parameter2 ... parameterx %command%, you’ll just need to use PROTON_TWEAKS=1 %command%. This will apply all the relevant tweaks at once, removing the need to search multiple sources like the Arch Wiki, Mesa, Nvidia, and Wine documentation for performance boosting parameters. Also please note that the parameter name may change in the future.

Why it will not be enabled by default?
Because many of these parameters act as "double-edged swords," it’s important to approach them carefully. For instance, __GL_THREADED_OPTIMIZATIONS=1 and mesa_glthread=1 are typically beneficial for CPU-intensive applications but can lead to performance drops in games that depend on synchronous OpenGL calls. Other tweaks might impact the artistic style of the game or introduce instability. That's why it's better to offer these optimizations as an option rather than making them a standard, as achieving better performance often involves some sacrifices.

Release:

Sarek9-15-r2 Released

Stable Build:

The second revision of Sarek9-15, so what has been done?

Now VKD3D its officially supported, all future Sarek builds will utilize VKD3D 2.8, as it's the last version that doesn't have Vulkan 1.3 as a requirement. The Proton configuration has been updated to correctly reference the VKD3D 2.8 DLL. Because newer versions typically include two dlls, d3d12.dll and d3d12_core.dll while VKD3D 2.8 and earlier versions only include d3d12.dll.

For that reason the next line had been changed from:

vkd3d_protonfiles = ["d3d12", "d3d12_core"] to vkd3d_protonfiles = ["d3d12"]

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Why DXVK Async?
The main reason is performance. DXVK Async enables asynchronous shader compilation, while the regular DXVK uses synchronous compilation. In regular DXVK, when a game encounters new shaders, they are compiled synchronously, causing brief stutters or freezes as the game waits for the compilation to finish. In contrast, DXVK Async compiles shaders in the background, allowing the game to continue running, though there may be minor graphical artifacts until compilation is complete.

So why isn't it in the normal version?
While DXVK Async significantly improves performance by reducing stuttering, it poses a potential risk of triggering client-side anti-cheat systems in multiplayer games. This risk arises because the tool alters shader handling, which might be viewed as cheating by some anti-cheat software. Although there haven’t been confirmed bans for using DXVK Async, the possibility remains, and I personally wouldn’t risk my Steam account for it.

What its being tested now:

We are currently testing a feature that could be ideal for users looking to squeeze every bit of performance from their PCs. We're making a new Proton parameter for Sarek, which, when enabled, will apply a set of optimizations through environment variables. Instead of having to manually add parameters like parameter1 parameter2 ... parameterx %command%, you’ll just need to use PROTON_TWEAKS=1 %command%. This will apply all the relevant tweaks at once, removing the need to search multiple sources like the Arch Wiki, Mesa, Nvidia, and Wine documentation for performance boosting parameters. Also please note that the parameter name may change in the future.

Why it will not be enabled by default?
Because many of these parameters act as "double-edged swords," it’s important to approach them carefully. For instance, __GL_THREADED_OPTIMIZATIONS=1 and mesa_glthread=1 are typically beneficial for CPU-intensive applications but can lead to performance drops in games that depend on synchronous OpenGL calls. Other tweaks might impact the artistic style of the game or introduce instability. That's why it's better to offer these optimizations as an option rather than making them a standard, as achieving better performance often involves some sacrifices.

Release:

Sarek9-15-r1 Released

Stable Build:

The first revision of Sarek9-15, so what has been done?

First of all big thanks to Artewar67 for the fix to this bug:

Sometimes, when using WineD3D, the maximum supported OpenGL version is capped at 4.4 instead of the expected 4.6.

This was fixed by changing the following line in the wine.inf file:

HKCU,Software\Wine\Direct3D,"MaxVersionGL",0x10001,"460" to HKCU,Software\Wine\Direct3D,"MaxVersionGL",0x10001,"0x40006"

Additionally, i have make some changes to the Proton file, mainly related to DXVK. Specifically, line 936 has been updated from:

dxvkfiles = ["d3d11", "d3d10core", "d3d9"] to dxvkfiles = ["d3d11", "d3d10", "d3d10core", "d3d10_1", "d3d9"]

This ensures all DX10 files from the older DXVK versions are correctly called. The latest DXVK versions only include "d3d11", "d3d10core", and "d3d9", while the older ones also contain "d3d10" and "d3d10_1".

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Why DXVK Async?
The main reason is performance. DXVK Async enables asynchronous shader compilation, while the regular DXVK uses synchronous compilation. In regular DXVK, when a game encounters new shaders, they are compiled synchronously, causing brief stutters or freezes as the game waits for the compilation to finish. In contrast, DXVK Async compiles shaders in the background, allowing the game to continue running, though there may be minor graphical artifacts until compilation is complete.

So why isn't it in the normal version?
While DXVK Async significantly improves performance by reducing stuttering, it poses a potential risk of triggering client-side anti-cheat systems in multiplayer games. This risk arises because the tool alters shader handling, which might be viewed as cheating by some anti-cheat software. Although there haven’t been confirmed bans for using DXVK Async, the possibility remains, and I personally wouldn’t risk my Steam account for it.

Testing Build:

Once again, there's no need for a public testing build. We currently have a private build with experimental configurations that might provide a slight performance boost, but it's still very unstable.

Release:

Sarek9-15 Released

Stable Build:

Changed the base of the Build to GE-Proton9-15 instead of GE-Proton9-14, all previous patches applied to Sarek9-14 are now working on Sarek9-15, including the ones for WineD3D and the Global Proton Prefix.

It had been added the Custom Prefix for Test Drive Unlimited Solar Crown adding the next line to the wine.inf file:

HKCU,Software\Wine\AppDefaults\TDUSC.exe\DllOverrides,"xinput1_3",,"native,builtin"

And other minor configurations to the wine.inf

Stable Async Build:

This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.

Why DXVK Async?
The main reason is performance. DXVK Async enables asynchronous shader compilation, while the regular DXVK uses synchronous compilation. In regular DXVK, when a game encounters new shaders, they are compiled synchronously, causing brief stutters or freezes as the game waits for the compilation to finish. In contrast, DXVK Async compiles shaders in the background, allowing the game to continue running, though there may be minor graphical artifacts until compilation is complete.

So why isn't it in the normal version?
While DXVK Async significantly improves performance by reducing stuttering, it poses a potential risk of triggering client-side anti-cheat systems in multiplayer games. This risk arises because the tool alters shader handling, which might be viewed as cheating by some anti-cheat software. Although there haven’t been confirmed bans for using DXVK Async, the possibility remains, and I personally wouldn’t risk my Steam account for it.

Testing Build:

Once again, there's no need for a public testing build. We currently have a private build with experimental configurations that might provide a slight performance boost, but it's still very unstable.

News:

Now that Proton-Sarek is working well for low-end PCs, my team and I are focusing a little more on the next part of our project, Wine-Sarek. The goal is to offer the same patches to users who use launchers other than Steam (Lutris, Heroic, Bottles, etc). If you want to know more click me

Re-Release:

I updated the 9-15 release, because i didn't update the compatibilitytool.vdf file

Sarek9-14 Released

Stable Build:

Based on Proton-GE-9-14, now working with DXVK 1.10.3 and more

WineD3D:
Now just like the Testing Build, Sarek-Stable will use by default OpenGL 4.6 while using WineD3D, with command stream and command serialization, the stability with this configuration its the same of the prior build.

Note: Proton and Wine typically support a maximum version of OpenGL 4.4 when using WineD3D. While using OpenGL 4.6 may not provide a significant or even decent performance boost, it helps reduce stuttering on older or low-end hardware.

Note: The errors on S.T.A.L.K.E.R Call Of The Zone when using WineD3D with OpenGL 4.6, command stream and command serialization had been fixed.

Stable Async Build:

A new build :). Its just like the Stable build but will use DXVK 1.10.3 Async instead of the normal one.

Why DXVK Async?
Why? Simple, performance. The key difference in DXVK Async is that it enables asynchronous shader compilation, whereas the regular DXVK uses synchronous compilation.

In regular DXVK, when a game encounters new shaders, they are compiled synchronously, causing the game to stutter or freeze briefly while the shader is being processed. This is because the game must wait for the compilation to finish before continuing.

In DXVK Async, the shaders are compiled in the background while the game continues running. Instead of freezing or stuttering, the game proceeds, though there might be minor graphical artifacts until the shaders are fully compiled.

Then why isn't on the normal version?
While DXVK Async offers significant performance improvements by reducing stuttering through asynchronous shader compilation, it carries a potential risk of triggering client-side anti-cheat systems in multiplayer games. This risk exists because the tool modifies how shaders are handled, which might be interpreted as a cheat or manipulation by some anti-cheat software.

Although there haven't been any confirmed cases of players getting banned for using DXVK Async, the possibility remains. Given this, I personally wouldn’t take the chance with something as valuable as a Steam account.

Testing Build:

At the moment, there’s no need for a separate Testing Build, since the Stable Build has caught up in terms of features and performance. That being said, I am working on new configurations that show promise, but they are still in the early stages and too unstable to release, even as part of a Testing build. Once further refinement is done, I'll share them for broader testing.

Thats all for now :P, hope that you enjoy your gaming.

Release:

Sarek9-13-r1 Released

Stable Build:

The first revision of Sarek9-13. So whats new?

WineD3D:
Now just like the Testing Build Sarek-Stable will use by default OpenGL 4.6 while using WineD3D, but only with command stream, not with command serialization, the stability with this configuration its the same of the prior build.

Note: Proton and Wine typically support a maximum version of OpenGL 4.4 when using WineD3D. While using OpenGL 4.6 may not provide a significant or even decent performance boost, it helps reduce stuttering on older or low-end hardware.

Why it dont have the command serialization by default?
Again, it's a problem with stability. I am currently checking out the WineHQ wiki and more to see if it can be fixed in any way (Maybe changing the Windows version? Or making a new prefix from scratch?).
The only game affected so far is S.T.A.L.K.E.R: Call of the Zone. But I don't want to ship it when it can break games. It may be a problem for other games that I don't play/didn't test. So I will keep it in the Testing build for now, and use my friends PCs as a testing ground ;).

Testing Build:

The Testing Build its the same of the prior release, it will use by default OpenGL 4.6 while using WineD3d with command stream and command serialization.

Thats all for now :P, hope that you enjoy your gaming.

Release:

Sarek9-13 Released

Stable Build:

1. The base has been changed from Proton 9.0-2 to Proton-GE-9-13.

2. Patched to work with DXVK 1.10.3.

3. General prefix configuration and specific prefixes for some games have been modified.

4. Download and enjoy!

Testing Build:

I have been dedicating considerable time to the testing build, primarily to improve performance for DXVK v1.10.3 and WineD3D. Here’s what I have achieved so far:

WineD3D:

By default, this build will use OpenGL 4.6 if detected; if not, it will utilize the highest OpenGL version available on the user's system. Unmodified Wine or Proton typically supports a maximum of OpenGL 4.4. While this change may not bring a significant performance boost, it does help reduce stuttering in certain games, such as Red Orchestra 2, where the improvement is quite notable.

Why is this build in testing?:
The testing build is still a work in progress. While it does help reduce stuttering, it is not perfect and does have bugs, as is common with all software. For instance, while Sarek-Stable runs without issues, the testing version may experience stability problems with certain games such as S.T.A.L.K.E.R: Call of the Zone. This has resulted in hard crashes, often requiring me to terminate the application using xKill.

Gallium Nine:

I understand that many people have been requesting to add Gallium Nine in future builds. I am actively working on this, and I appreciate the interest. However, it is worth noting that Gallium Nine may be removed from Mesa in the near future, which could impact its implementation. Consequently, I will prioritize this feature lower for now, and it will not be included in any builds until a complete implementation is confirmed.

DXVK

As for DXVK, I haven't touched anything yet; I'm just doing some testing comparing the performance of different builds. Once I get WineD3D in a good state, I will dedicate more time to this.

Release: