Comments (8)
Initial Steps and Tests:
- Manually build LibRTPI on my system
- Rebuild Wine-NSPA-8.19 (Verify build, Scripts && Patchwork)
- Write (a script and) create a patch to convert pthread_mutex/cond and friends
- Make sure to link against LibRTPI on my system
- Try to build; fix any issues that come up
- Successful Build???
- Test. Test. Test.
A bit more tinkering and the above will be complete, more or less.
Decisions???
a. Include instructions on building LibRTPI in the repo?
b. Create a librtpi PKGBUILD for Arch Linux?
c. Figure out how to add it to Wine's build system directly, instead of a && b ??
At that point, I could publish a new 8.19-nspa-pi build -- before moving onto 9.x builds... That would also give me better testing, initially - As 9.x builds will likely be a whole new can of worms (I've seen breakage for people on r/linuxaudio for plugins, apps, etc... One of the reasons I've been slow to move onto it).
from wine-nspa.
Well, this is still WIP but I have initial LibRTPI-based Priority Inheritance support wired up in Wine-NSPA.
As you can see above Wineserver IS using FUTEX_LOCK(/UNLOCK)_PI_PRIVATE for locking (for regular mutexes/locks). Fsync stuff is still using futex_waitv, as expected (Futex2 doesn't support PI).... And a quick grep:
$ grep -R "pi_mutex" '/home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr'
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/winebus.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/ntdll.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/wineusb.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/lib/wine/x86_64-unix/win32u.so: binary file matches
grep: /home/ninez/pkgbuilds/Wine-NSPA/wine-nspa-8x-git/pkg/wine-nspa-staging-fsync-git/usr/bin/wineserver: binary file matches
ATM, it's not complete support:
- Wine64 only ATM (but it should be easy to fix/add 32bit support)
- I still need to deal with condvars
- I'll need to do a slight rework of my RT patch for Ntdll
- There are a few other quirks to clean up / fix up!
- A lot of testing
But this looks to be a good endeavor. AFAIK, this is going to be the first Wine Implementation with support for Priority Inheritance. ~ There's been multiple RT implementations, multiple implementations of using pipes for synchronization objects, etc -- but again, AFAIK; there's never been PI support.
Initial testing shows promise, but I'll need to finish some of the above + enable 32bit support to run some older binaries that I use (in part) for testing / measurements.
from wine-nspa.
I basically have most of it working now. Well, the big parts:
32bit / 64bit support
Mutex converstions (98%)
Condvars conversions (100%)
So I backed up my current librtpi hacking stuff: https://github.com/nine7nine/Wine-NSPA/tree/main/librpti-stuff ... WIP, not for general use though (although it does compile).
Next, I need to resolve librtpi -- and how to handle it (?). Currently, I just manually compile it. building both 64bit and 32bit/lib32 versions (which wine picks up). But it might be better to have it in tree.
Lastly, I'll need to decide on scope of usage; as It's unlikely I want to use the big hammer approach in my script/patch.
from wine-nspa.
Got 99.9% of this sorted out, aside from how to package it...
Integrating into Wine seems to be a bit of a pain, but I may be able to integrate it into Wine-TKG build scripts. However, If I am to do that -- I might as well wait until I finish rebasing on Wine-9.x ... which I plan to start working on again, especially now; with Wine-Proton 9.0 being released... Additionally, it sounds like it may be possible to get Native Access 2 working, but I think that requires a slightly newer version of Wine (and obviously, it's important to me to get that working).
All testing so far using pi_mutex/condvars in Wine-NSPA seem to be working out well... I had planned on trimming / scoping the PI support just within ntddl, server, winealsa and a few places: But as it turns out -- that seems to cause some friction/issue that negatively affected DPC Latency tests... Converting the entire source tree yields more expected results.
That said: this is still going to require a lot of testing, before being enabled by default.
from wine-nspa.
updated patchwork: https://github.com/nine7nine/Wine-NSPA/blob/main/librpti-stuff/librtpi-PI_Support.mypatch
Properly handles pi_mutex_init/destroy() ... it's getting there!
This is pretty damn stable on my machine too. That is; after fixing a few issues (some unrelated to the PI support itself).
from wine-nspa.
So, as mentioned here: #4 (comment)
I'm looking at implementing a Monitor synchronization mechanism, in the hopes of replacing the FUTEX_WAIT/WAKE + epoll_wait busy-waiting in Wineserver (part of the SHMem Threads patch -- but also a problem on vanilla Wine)...
from wine-nspa.
Okay, so it's been around 2 months since I started using librtpi. Overall, it has been a success - So i am going to provide an update, and lay out a path forward.
- Replacing Wine's pthread_mutex implementation with librtpi's pi_mutex implementation works fine and is very stable. It works very well.
- I had to drop trying to implement a Monitor synchronization mechanism, and instead went with a more straight-forward mutex + condvar setup in a couple of places (very similar to the other pthread cond var usage in Wine).
- librtpi simplifies Wine's pthread_mutex implementation and provides robust PI support. It also seems to reduce lock contention / CPU usage in a few cases.
- Building librtpi in Wine's tree is problematic, due to differences between Linux distributions AND librtpi isn't really shipped by many distributions.
All around this is very positive / good news... The big hiccup is how to handle librtpi and building that support... To outline this;
- Manually build librpti for 32/64 bit. This is easy, so i can provide instructions
- Keep librtpi support in Wine-NSPA as optional. This is technically how things are now.
- To build librtpi support in Wine-NSPA: all that is required is building the libs, then moving 2 patches into ../wine-tkg-userpatches before building wine-NSPA
Soooo... I think what i will do is add a proper Installation page to the wiki with generic building instructions (for Arch Linux anyway), then also provide librtpi + Wine-NSPA build instructions.). While it would be nice to simply automate all of this: that seems to have some pain points. Plus, it's really not that hard to build librtpi and Wine-NSPA with that support.
TODO: Add the relevant Wiki entry
from wine-nspa.
I'm going to close this issue for a couple of reasons:
- I've updated the Wiki / README about enabling this support.
- The patchwork (and related code in Wine) has evolved and matured.
- I've been using this for months now, it's been fairly stable.
- PI Mutexes are still an optional feature
Next, while I do still want to integrate this into Wine-NSPA, it's probably not going to happen for a while. Thus, I feel since it is optionally available, with instructions - I can close this issue.
Later, I can open a new issue, specifically about statically building it in by default.
from wine-nspa.
Related Issues (12)
- Rebase: Wine-8.0-NSPA HOT 4
- Rewrite Wine-NSPA Scheduler Support HOT 5
- Rebase Wine-NSPA RT patchwork HOT 1
- Ableton Live 11/12 Support / Notes-Docs HOT 33
- Wine-NSPA-8.x Rebase - TODO / Priority HOT 6
- Upstream Wine-8.x is borked / Modern Wine builds are NOT suitable for my use. HOT 4
- Fresh build fails to launch on EndeavourOS HOT 3
- Rebase on Wine-9.6+ (Lots breakage / rework to do) HOT 3
- no luck so far with 7x and 8x wine-nspa branch HOT 4
- How to install? HOT 21
- Fix Kontakt 6 regression (Periodic CPU spike) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wine-nspa.