View Issue Details

IDProjectCategoryView StatusLast Update
0000923OpenMPT[All Projects] Feature Requestpublic2017-10-08 09:39
ReporterMonsterovichAssigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
PlatformLinuxOSLinux Mint (kernel 4.10)OS Version18.1
Product Version 
Target VersionOpenMPT 2.0 (very long term goals)Fixed in Version 
Summary0000923: Performance problems with VST plugins and multi-core support in OpenMPT
Description

We know that a lot of VST plugins are very CPU hungry. It became a problem on modern machines with multiple cores. For example: I can normally play my song with 4-6 VSTs on 13-year-old CPU (only 1 core) and it will work fine without issues but OpenMPT stucks on my modern laptop (with 4 cores!!!).

I described this problem here: https://appdb.winehq.org/objectManager.php?sClass=version&iId=34633)

Despite the fact that the tests show: 1 intel core is almost equal to 1 amd core, these cores on my laptop are very slow by some reason in OpenMPT (probably bad hardware) and I can use only 25% (!) of my processor. Imagine, if I had 8 core processor but the cores are slow.

Allow users to use multiple cores and bind each VST plugin to specific core. (see attachment)
Or just spread VSTs between cores automatically like Renoise does.

Additional Information

I don't have such problems in Renoise. Almost all modern DAWs have this feature.

P.S. I use wine but I have the same thing in Windows on my machine... anyway...

TagsNo tags attached.
Has the bug occurred in previous versions?Yes
Tested code revision (in case you know it)

Activities

Monsterovich

Monsterovich

2017-03-04 14:29

reporter  

mptmulticore.png (94,646 bytes)
mptmulticore.png (94,646 bytes)
manx

manx

2017-03-04 15:03

administrator   ~0002901

Slowness of pattern display in Wine is at least partly due to the work-around I added in r4043 . Otherwise the current row highlight would be jumpy and flickery like crazy. Now, the flickering could be attributed to an incompatibility in Wine because native Windows behaves differently, however, the way OpenMPT does its drawing of the pattern display here is way suboptimal and IMHO also massively contributes to the problem. Correct behaviour for the way OpenMPT does its drawing is also not at all specified by Microsoft. The work-around that gets applied on Wine basically redraws the whole thing on every row change, which can be noticeably slow, especially on very slow CPUs like an Intel Atom ZxxxxF.

LPChip

LPChip

2017-09-18 19:18

manager   ~0003220

Oh, I'd wish this was there! +1

Monsterovich

Monsterovich

2017-09-19 08:53

reporter   ~0003221

Since I have Intel(R) Core(TM) i3-6006U, the most of VSTs work perfectly for me. Anyway, this feature would be very cool for slow-core CPUs (like 4 core Z*** intel processors) or for heavy VSTs that would make audio lag even on i3.

harbinger

harbinger

2017-09-20 22:25

reporter   ~0003222

Yes, I will be upgrading to a multicore computer soon. Will I have to keep my old single-core, XP computer so I can run openMPT as efficiently as I have? Does this mean my new computer will offer me no speed advantage for openMPT?

Saga Musix

Saga Musix

2017-09-20 23:41

administrator   ~0003223

It most likely will because there are tons of other ways OpenMPT can profit from a more modern CPU (e.g. updated instruction sets that OpenMPT can make use of).
In particular, OpenMPT (or any other application) does not have to fight over the resources of a single CPU core. You just currently cannot expect that OpenMPT will render 8 times faster if you have 8 cores, that's all.

Monsterovich

Monsterovich

2017-10-06 08:37

reporter   ~0003293

Well, If I use 11 VSTs in the same time, the sound is starting to crack even on i3. We need this feature.

Saga Musix

Saga Musix

2017-10-06 10:09

administrator   ~0003294

Re-iterating the known facts doesn't make implementation any easier.

manx

manx

2017-10-06 10:15

administrator   ~0003295

I have already stated this otherwhere (possibly on IRC, cant remember right now):
Pushing forward for this feature right now would very likely require more effort in total than what would be required when we delay this feature until after plugin handling gets refactored and restructured and in particular cleaned up.
Implementing this short term could require implementing kind of a hack now, requiring a proper re-implementation later on, and thus wasting a lot of development time in the process.

LPChip

LPChip

2017-10-06 10:44

manager   ~0003296

@Manx: it was indeed on IRC, towards me. :)

manx

manx

2017-10-08 09:39

administrator   ~0003298

quoting IRC EsperNET #modplug 2017-09-18 for future reference (I shortened the log to the relevant parts):

20:58 <@LPChip> Saga_Musix: question. I know we talked about this in the past, but how much can OpenMPT utilize multiple cores?
20:59 <@Saga_Musix> the renderer is single-threaded. plugins may make use of more cores if they want to
20:59 <@LPChip> so it is up to the plugin to use mutiple cores?
21:00 <@manx> openmpt will basically use 1 for audio, 1 for the gui
21:00 <@Saga_Musix> yes
21:00 <@LPChip> I see... okay, that explains why my idea didn't work.
21:00 <@Saga_Musix> but only very few plugins are multi-threaded, because most of the time there is no opportunity to really take advantage of multiple cores for a single plugin
21:01 <@LPChip> I was hoping if I had many plugins all loaded directly into OpenMPT, that they would magically use all my cores. Instead they all load in the same core, so I reach 1 of my 8 cores full and stutter begins
21:03 <@LPChip> in theory, would it actually be possible to create multiple threads of OpenMPT so different VST effects and instruments get loaded in different threads to spread out the load over the entire processor?
21:03 <@manx> yes, that would be possible in theory
21:04 <@LPChip> is there such feature request already? :P
21:15 <@manx> LPChip: yes: https://bugs.openmpt.org/view.php?id=923
21:17 <@manx> it's also not quite as simple as it seems
21:18 <@manx> in particular, i'm rather hesitent to include more kind-of-hacks around plugins at the moment, i'd rather see a cleaner re-implementation of all plugin handling
21:19 <@LPChip> manx: I see... I'm in for that. can you make it ready by tomorrow?
21:20 <@manx> there are a couple of things worth implementing in that area: more flexible routing, plugin delay compensation, suppor tfor foreign plugins (i.e. linux plugins when running on wine)

[...]

21:38 <@LPChip> the plugin bridge doesn't do this, correct?
21:38 <@LPChip> or does that run in its own thread?
21:39 <@manx> the plugin bridge runs in its own process and thus thread
21:39 <@LPChip> oh okay
21:39 <@LPChip> that is worth investigating
21:39 <@manx> however, i think it runs in lock-step with the main audio thread, so it does not actually parallize anything
21:39 <@LPChip> ah. okay
21:39 <@manx> we would need to ad explicit support for that, which would be, in its most simple form, at the expense of additional latency for the bridged plugin
21:40 <@LPChip> yeah
21:40 <@manx> but, i'm not sure if it is actually worth going that route from a development effort point of view, given the other things that need to be adressed in that area
21:40 <@LPChip> I guess the simplest form would be to send midi notes to an instance that runs in its own thread, and let that threat work whatever it wants

Issue History

Date Modified Username Field Change
2017-03-04 14:29 Monsterovich New Issue
2017-03-04 14:29 Monsterovich File Added: mptmulticore.png
2017-03-04 14:30 Monsterovich Description Updated View Revisions
2017-03-04 14:37 Monsterovich Description Updated View Revisions
2017-03-04 14:37 Monsterovich Steps to Reproduce Updated View Revisions
2017-03-04 14:47 Monsterovich Reproducibility have not tried => always
2017-03-04 14:51 Monsterovich Description Updated View Revisions
2017-03-04 15:03 manx Note Added: 0002901
2017-09-18 19:16 manx Product Version OpenMPT 1.27.00.* (old testing) => OpenMPT 2.0 (very long term goals)
2017-09-18 19:17 manx Product Version OpenMPT 2.0 (very long term goals) =>
2017-09-18 19:17 manx Target Version => OpenMPT 2.0 (very long term goals)
2017-09-18 19:18 LPChip Note Added: 0003220
2017-09-18 20:15 Saga Musix Priority high => normal
2017-09-19 08:53 Monsterovich Note Added: 0003221
2017-09-20 22:25 harbinger Note Added: 0003222
2017-09-20 23:41 Saga Musix Note Added: 0003223
2017-10-06 08:37 Monsterovich Note Added: 0003293
2017-10-06 10:09 Saga Musix Note Added: 0003294
2017-10-06 10:15 manx Note Added: 0003295
2017-10-06 10:44 LPChip Note Added: 0003296
2017-10-08 09:39 manx Note Added: 0003298