nine7nine / wine-nspa Goto Github PK

View Code? Open in Web Editor NEW

18.0 5.0 1.0 19.01 MB

Wine-NSPA: Proaudio & RT focused builds of Wine(-TKG)... WARNING: Forced Pushes && Resets..

Shell 100.00%

winehq linux-nspa wine-nspa wine-staging proaudio

wine-nspa's Introduction

Wine-NSPA:

A Real-Time Capable and Proaudio-Centric Build of Wine(-TKG).

Wine-NSPA Wiki; https://github.com/nine7nine/Wine-NSPA/wiki

Preface:

Wine-NSPA focuses on the integration of performance enhancements and RT related features that help proaudio apps run better. Currently, Fsync/futex_waitv is the prefered method for improving synchronization primitives support, which requires kernel-level support (linux-5.16+). I have implemented improved Scheduling and RT support via out-of-tree patchwork, and my own modifications to Wine. This fork also integrates the out-of-tree Wineserver Shared Memory patchset, a Multi-threaded Wineserver implementation (shmem per Thread patch), the Wine Low Fragmentation Heap patchwork, and a number of other out-of-tree patchsets. Some of these other features do require kernel-level support. (but Wine-NSPA will work without them too).

Wine-NSPA has two branches 7x (7.5 based, getting old) and 8x (based on 8.14+). wine-nspa-8x-git is what sould probably be used, as going forward - that is where active development will happen.

Note: 8x buils are still mssing a few bits, but nothing too critical... I currently use my typical setup of NI Komplete, UHE, AAS, etc plugins all running with Kushview Element ~ which works reasonably well with 8x builds. Ableton Live is also running alright too -- although, given that I'm still working on 8x builds (and Wine-8.x has only recently stabilized for my use:), mileage wil vary.

Features (non-exhaustive)

NSPA-Specific Wine-RT Implementation
Improved multi-threading / scheduling support
Various Locking, Atomics & Membarrier Optmizations/Improvements
Kernelbase linux-thread RT hooking for TIME_CRITICAL threads*
Wineserver Shared Memory support
Wineserver SHMEM Per Thread (Server Requests/Replies)
Esync / Fsync Proton 8.0-experimental implementation
Wine Low Fragmentation Heap Patchwork
Keyed Events Linux Futexes Implementation
Numerous Performance Optimizations
Significant backports and Bugfixes
Winserver + Ntdll backports
MSVCRT backports/updates
Hacks to improve Wine for NSPA usage
Loader/vDSO performance Optimizations
Proton's CPU Topology Overrides

note: too many other bits to list here

Linux-NSPA:

As mentioned above, some features in Wine-NSPA do require kernel support. For that reason, I maintain my own Archlinux PKGBUILDs. You can find my archlinux package (sources) and kernel sources repository linked below;

Linux-NSPA PKGBUILD - https://github.com/nine7nine/Linux-NSPA-pkgbuild

note: This is a Customized Realtime Linux kernel.

I HIGHLY suggest that you use Linux-NSPA with Wine-NSPA over any other kernel. Vanilla distribution kernels are often not configured for optimal performance and more often than not: poorly configured for proaudio / realtime workloads. On top of that; I have patchwork that may not only improve performance, but actually resolve issues that may be wine-specific (such as the rwlock/rw_semaphore issues on RT that may crash some wine applications).

Windows DAW / Heavy ProAudio Application Support

Preview: Ableton Live 11 running in Wine-NSPA-7.5 with a number of patches/fixes to better support it.

Currently, I'm working with some experimental patchwork to improve multithreading, scalability and my RT support. This should get heavy applications like Ableton Live 11 working nicely in Wine-NSPA. This work is partially complete, but I'm also tracking Ableton Live support/documentation here: #4 ...

DPC Latency Checker

DPC Latency Checker is used in older versions of Windows to verify if your system is suitable for realtime performance. Assuming you have decent hardware (higher specs, well-designed mobo, interrupts layout, good drivers, etc), AND you've configured your system very well. You can use DPC Latency Checker with Wine-NSPA. ( you can google and find DPC Latency Checker v1.40, if you like )

The above is from my Microsoft Surface 7. It's a decently designed PC, running Linux-NSPA on a well-configured Arch Linux system. NOTE: this isn't a substitute replacement for rt-tests (cyclictest, hackbench) for testing a linux system: but will help indicate if your Wine-NSPA / linux system setup is actually usable for ProAudio.

Credits/Shoutouts:

WineHQ: https://www.winehq.org/
Wine-Staging: https://github.com/wine-staging/wine-staging
Wine-TKG: https://github.com/Frogging-Family/wine-tkg-git
RBernon's Wine Repo: https://github.com/rbernon/wine
Openglfreak Repo: https://github.com/openglfreak/wine-tkg-userpatches
Valve's Proton: https://github.com/ValveSoftware/Proton
Realtime Linux: https://wiki.linuxfoundation.org/realtime/start
Jack Audio Connection Kit: https://jackaudio.org/
Pipewire: https://gitlab.freedesktop.org/pipewire/pipewire
WineASIO: https://github.com/wineasio/wineasio
FalkTX: https://github.com/falkTX/Carla
Robbert-vdh: https://github.com/robbert-vdh/yabridge
Arch Linux: https://archlinux.org/
Linuxaudio: https://linuxaudio.org/

Other people of note: Jack Winter, Paul Davis and the whole Linuxaudio community.

wine-nspa's People

Contributors

Stargazers

Watchers

Forkers

loaykhalifa

wine-nspa's Issues

no luck so far with 7x and 8x wine-nspa branch

I managed to compile 8x,
but it fails to launch currently:

export WINEDLLOVERRIDES="mscoree,mshtml=" 
export WINEDLLOVERRIDES=winemenubuilder.exe=d   
export WINEFSYNC=1 
WINEPREFIX=/home/mero/wine-base winecfg 
wine: created the configuration directory '/home/hero/wine-base' 
fsync: up and running. 
Fatal glibc error: allocatestack.c:333 (allocate_stack): assertion failed: size != 0 
^CTerminated

and with 7x, a patch is sadly not merging:


  -> Applying josh-flat-theme.patch
  -> ## Applying hotfix for plain-wine: Return_nt_filename_and_resolve_DOS_drive_path.mypatch
  -> ## Applying hotfix for plain-wine: ef6e33f.mypatch
  -> ## Applying hotfix for plain-wine: 0001-proton-bcrypt_rdr2_fixes4.mypatch
==> ERROR: Patch application has failed. The error was logged to /home/hero/Wine-NSPA2/Wine-NSPA/Wine-NSPA/wine-nspa-7x-git/prepare.log for your convenience.
  -> Removed BIG_UGLY_FROGMINER - Ribbit
  -> Removed Proton-tkg token - Valve Ribbit
  -> exit cleanup done

this is with linux-nspa kernel running, but no optimization otherwise done to the os - running in virtualbox

Rewrite Wine-NSPA Scheduler Support

Rewrite the RT support for Wineserver

This is partially complete, as of commit: 1614c65

The above commits replaces the sched_setscheduler() code with pthread functions, it also extends wineserver to support scheduling policy changes at runtime, and finally implement support for adjusting nice values (I'm sitting on code to adjust it at runtime).

Fully implement scheduling support for adjusting nice values for Windows scheduling/priority classes.
investigate implementing supporting sched_rr_timeslice_ms quantum interval stuff for SCHED_RR threads

the above will also require performance analysis within Wine. it would be interesting to see if this could help improve performance and/or reduce overhead, depending on how it's implemented.

Investigate adding ionice support within wine (I currently do this manually / scripted).
investigate adding cgroups support within wine. (I currently do this manually / scripted).

NOTES:

By switching everything over to pthread-based RT support; it opens up a lot of opportunity in fine-tuning thread behaviour within Wineserver, Ntdll and user/application threads.

Likewise, as Linux-NSPA supports latency.nice I can fine-tune non-RT and RT thread latency tuning alike.

the hope is that I can do the same with ionice, cgroups, etc too => My manual scripts cover most of this now - and it makes a big difference, especially with things like Ableton Live 11. It's the difference between issues with xruns or almost zero xruns.

Rebase Wine-NSPA RT patchwork

Rebase all RT related code
Consolidate into a single clean patch
Must apply cleanly after 2 reverts from Staging / Wine-TKG

0000-ntdll-Store_fsync_APC_futex_in_the_thread_data_directly.myrevert
0000-wineserver-Draft-to-implement-priority-levels-throug.myrevert

Note: First revert is for fsync, so i can hook the threads correctly. Second revert is removing the wine-rt patch from staging ~ which i integrate into my patch set, but have rewritten parts of.

fix up any patches that don't apply cleanly after. (matters for 7.5 builds, obviously. lol)

This will make it easier to not only rebase on Wine.80 (when the time comes), but also for my current efforts to rewrite my RT implementation to not use sched_setscheduler(), and simply use pthread functions, instead. Along with adding/refactoring the CFS/nice support, and so on.

Wine-NSPA-8.x Rebase - TODO / Priority

Valve has pushed a Proton-8.0 branch, as their main/default branch

https://github.com/ValveSoftware/wine

Given that much of the patchwork that I use loosely depends on some of Valve's patchwork, it's not time to actually look at rebasing Wine-NSPA on Wine-devel / Wine-Proton 8.x

Valve is using 8.0 (plus a bunch of extra patches
Wine-TKG is following Wine-Devel

So i will rebase to latest Wine-TKG and merge any needed/wanted changes from Proton-8.0 branch.

then pickup any patchwork from Torge's github (which also tracks wine-devel loosely.

https://github.com/openglfreak/wine-tkg-userpatches

all of my core patchwork has already been rebased on Wine-8.0, so mostly trivial changes will be required. However, there are a number of patches that i want to pick up (out of tree), so that's going to be a bit more work...

Fresh build fails to launch on EndeavourOS

Hello!

Been using Wine-NSPA for quite a while, but as of now on EndeavourOS (arch-based distro) it fails to run with following error:

Fatal glibc error: allocatestack.c:333 (allocate_stack): assertion failed: size != 0

Recompiling didn't help. Would appreciate any advice and thank you for your work!

Upstream Wine-8.x is borked / Modern Wine builds are NOT suitable for my use.

Wine-8.x is junk.

Not suitable for my use case of proaudio, in general. why?

significantly higher CPU usage vs. Wine-7.5 (and below) like a solid 10-15% higher in most cases.
Periodic Stalling. ~ I've ruled out my patches and also Fsync. It looks like it is caused somewhere in the heap / memory code. (not something i can resolve or fix).

I am going to continue to rebase and periodically test, but atm, upstream Wine is just awful for performance. Definitely not suitable to be using for my own use-case (ie: using Ableton Live, or even NI Komplete 13 on it's own)... it's sad that after 15 years I can't seem to use my software on the latest / a modern version of wine...

For now, I'm using Windows... When i'm not as busy with work: I'm going to go back and do a clean rebase / build of Wine-NSPA-7.5, basically from scratch to clean out some cruft and re-organize patchwork. (solely for use with Yabridge and/or Element)

The future of using Wine doesn't look bright though - I've waited months for Wine-8.x to deliver and it's still utter crap, all around. (if you actually care about getting relatively decent performance, anyway).

Rebase: Wine-8.0-NSPA

Feature freeze is approaching fast, leading up to Wine-8.0 release.
I believe Valve will also be planning to rebase Proton on wine-8.0 (soonish / experimental branch)
The changes between 7.22 - 8.0 should be relatively minimal, no big overhauls
In the last few months, Wine has had some non-trivial (perf-related) changes that are tricky to backport to Wine-7.5.

Given the above, it is time to start thinking about rebasing and reworking all of my patchwork for a Wine-8.0-NSPA release... all of my own patches should be relatively easy to rebase AND I should be able to drop a ton of patches that have been merged already...

I should just start with a clean / up-to-date Wine-TKG-git package
Rebase all of my changes to Wine-TKG build scripts
Drop anything that has been merged into Wine
Rebase/Rework all userpatches
look at desired patchwork that I haven't touched due to using 7.5-base
Switch to PE builds (because I probably don't have a choice)

Anyway, this is the roadmap / end of year stuff.

Rebase on Wine-9.6+ (Lots breakage / rework to do)

There are a lot of breaking changes for Wine-8.20+, due to the DECSPECL changes
There are also a lot of other changes, causing a dozen or so patches to fail to apply

This is all manageable to fix and sort out, and the vast majority is somewhat trivial to fix -- However, it is time-consuming.

Given the scope ~ I'm going to hold off for now

Ableton Live 11 Support / Notes-Docs

In playing around with Live 11 with Wine-NSPA-7.5, I've been able to identify some issues (and fixed some).

Slow load of ableton instruments fixed by using -DontCombineAPCs option
High CPU overhead on idle is fixed by using -DontCombineAPCs option (read below)
dll / VST loading/unloading crashing was solved by some upstream fixes: 5aaf7ae
Slow load on (most) VSTs was fixed by several commits from wine-7.6+: 5aaf7ae
Closing of some plugin windows crashing wine was solved by an MR: 1614c65 (deadlock issue)
Blank/black popup menus bug in Ableton Live 11 is fixed now, as of commit: a987f3f
Any stalling is fixed my RT patchwork && multi-threaded RT Wineserver. (Wine-NSPA only)
TIME_CRITICAL threads are fixed by using my kernelbase RT hook: 846bcdf (gcc-builds only, no mingw support)
Switching to SCHED_RR improves performance, reducing lock contention.
Eliminate Jackd xruns issue via: https://github.com/nine7nine/Wine-NSPA/blob/main/examples/system/cgprio
setup mscv runtimes, winetricks && add dll overrides: #4 (comment)
workaround Live 11 failing to launch via custom .desktop launcher: #4 (comment)

That covers the basics and beyond. Ableton Live 11 is actually usable now.

What does "usable" mean?

I have no encountered any crashes, since resolving initial issues. (it's been very stable)
Performance is reasonably good with some caveats: eg: heavy plugins/presets won't magically use less CPU.

TODOs:

Resolve wake-up bug, where I get xruns (in jackd) until I run cgrprio (rt/cgroups/nice/ionice script)
Improve/troubleshoot Startup time (it's definitely slow).
Figure out any other options.txt flags that may be useful.
Further optimize performance

DontCombineAPCs

Live 11's two main threads use an excessive amount of CPU. As it turns out, Ableton Live has a configuration file that can be modified and has a number of hidden settings. ref: https://github.com/ibekso/medium/blob/main/article_ressources/options_txt/lists/options_available_live_11.txt ... One stuck out to me as being a possible cause of the high CPU usage, so I did some more digging, we have a option relating to APCs;

DontCombineAPCs

Line to add to Options.txt file: -DontCombineAPCs

Deactivates the APC combination mode: won't align and sync the session rings of multiple APCs 
so they can be moved independently.

ref: https://help.ableton.com/hc/en-us/articles/6003224107292-Options-txt-file

Turning on this option eliminates one of the high CPU threads (that causes 30-40% CPU usage on all CPUs). ~ That said, I have observed higher CPU usage one a given specific thread (at a time), but all of the rest consume much less CPU. Overall CPU usage on idle is waaaay down...!! This should improve performance, while being far more energy efficient.

The "APC combination mode" isn't very good for Wine... APCs are still handled by Wineserver's main thread, AFAIK (regardless of fsync or the shm multi-threaded bits), and I believe this mode expects to synchronize APCs across multiple threads (natively) -> that might explain why when it is enabled every core is 'stuck', so to speak. (they are stuck on waits).