Releases: pythonlover02/Proton-Sarek
Sarek9-20 Released
Hotfix:
This release is nearly identical to 9-19, but includes a hotfix from GE-Proton9-20 to resolve an issue by reverting the DRI_PRIME auto-setting, which caused compatibility issues with many non-standard setups. For more details on this release, see the 9-19 release notes below, as they apply here as well.
Sarek9-19:
Stable Build:
This release now will be based on GE-Proton9-19, instead of the 9-18 version. Working with DXVK 1.10.3, VKD3D 2.6 and everything added on the prior versions. Tough there are some changes.
Global Prefix Update:
- Restored Global Prefix to Valve’s/GE default configuration.
- Removed outdated customizations initially added to resolve issues that are now addressed in current versions of Wine and Proton.
- Two-week testing confirmed that previous issues are resolved, allowing removal of these customizations to avoid potential conflicts.
- No impact on other customizations: Changes only apply to the Global Prefix. Custom prefixes for specific games, including those from GE-Proton, Wine-GE, and additional Sarek-specific prefixes, remain unaffected.
Need for Speed (2003-2008) Mod Support:
- Added custom prefixes for Need for Speed games from 2003-2008 to improve compatibility with mods.
- Supported games:
- Need for Speed: Underground
- Need for Speed: Underground 2
- Need for Speed: Most Wanted
- Need for Speed: ProStreet
- Need for Speed: Undercover
- Supported games:
- Executable naming requirement: Ensure your game executable matches one of the following for mod compatibility:
speed.exe,speed2.exe,nfs.exe, ornfsc.exe
How to Use Sarek with Non-Steam Games
Recommended and Supported Method (via Steam):
- Add the game as a non-Steam game in your Steam library.
- Go to the game’s properties, enable the "Force the use of a specific Steam Play compatibility tool" option, and select Sarek from the list.
Why add Non-Steam Games Prefixes to Sarek?:
Adding non-Steam prefixes doesn’t interfere with Steam games; it simply offers a custom environment for enjoying Non-Steam games through Proton. This way, even games outside Steam’s library can benefit from Sarek’s enhancements.
Looking forward, expect more custom prefixes to support modding. My friends and I are passionate about creating and enjoying game mods, and these prefixes will help make that experience smoother for people in general.
Stable Async Build:
This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.
Thats all for now GLHF :)
Release:
Sarek9-19 Released
Stable Build:
This release now will be based on GE-Proton9-19, instead of the 9-18 version. Working with DXVK 1.10.3, VKD3D 2.6 and everything added on the prior versions. Tough there are some changes.
Global Prefix Update:
- Restored Global Prefix to Valve’s/GE default configuration.
- Removed outdated customizations initially added to resolve issues that are now addressed in current versions of Wine and Proton.
- Two-week testing confirmed that previous issues are resolved, allowing removal of these customizations to avoid potential conflicts.
- No impact on other customizations: Changes only apply to the Global Prefix. Custom prefixes for specific games, including those from GE-Proton, Wine-GE, and additional Sarek-specific prefixes, remain unaffected.
Need for Speed (2003-2008) Mod Support:
- Added custom prefixes for Need for Speed games from 2003-2008 to improve compatibility with mods.
- Supported games:
- Need for Speed: Underground
- Need for Speed: Underground 2
- Need for Speed: Most Wanted
- Need for Speed: ProStreet
- Need for Speed: Undercover
- Supported games:
- Executable naming requirement: Ensure your game executable matches one of the following for mod compatibility:
speed.exe,speed2.exe,nfs.exe, ornfsc.exe
How to Use Sarek with Non-Steam Games
Recommended and Supported Method (via Steam):
- Add the game as a non-Steam game in your Steam library.
- Go to the game’s properties, enable the "Force the use of a specific Steam Play compatibility tool" option, and select Sarek from the list.
Why add Non-Steam Games Prefixes to Sarek?:
Adding non-Steam prefixes doesn’t interfere with Steam games; it simply offers a custom environment for enjoying Non-Steam games through Proton. This way, even games outside Steam’s library can benefit from Sarek’s enhancements.
Looking forward, expect more custom prefixes to support modding. My friends and I are passionate about creating and enjoying game mods, and these prefixes will help make that experience smoother for people in general.
Stable Async Build:
This build is similar to the stable version but uses DXVK 1.10.3 Async instead of the regular one.
Thats all for now GLHF :)
Release:
Sarek9-18 Released
Hotfix:
This release is nearly identical to 9-17, but includes a crucial hotfix to resolve an issue with prefix creation by adding the missing Python uuid import in the Proton script. For more details on this release, see the 9-17 release notes below, as they apply here as well
Sarek9-17:
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-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.