nine7nine / wine-nspa Goto Github PK

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

• 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

• 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.

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).

LibRTPI - Library for implementing Mutex PI Support in RT applications.

https://github.com/gratian/librtpi

I've been implementing PI support in Wine-NSPA using the above Library. Pretty much all mutex / condvar conversions are complete. It is working well on my machine...

This support will require using an RT kernel && building the 64bit and 32bit/lib32 versions of this library... Therefore I am likely to make it optional / disabled by default. For now, it's completely disabled, and I don't even give an option to build it, or add the needed patch into my userpatches.

but this will change, once I've tested it more.

• 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.

• 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...

• 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.

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!

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).