Rack v1 unusable, return to 0.6 rcomian

[sinnerencia]

Anyone with a LOT of performance issues with Rack v1?

I wonder why rcomian can do this fork that works amazing in comparison with original branch.

In my MBP, Rack v1 is unusable equal that 0.6 version. Glitch audio, fan cpu at top speed…

I saw this same topic in github…seems that a lot of users have the same problem with performance with some GPU. Rcomian has the solution, can you applied to the v1 branch?

Any other solutions?

Regards

EDIT:

Test these patch.

A multithread performance experiment with Rack v1dev & the 0.6.2c rcomian fork experiment2

I’m sure many of us are interested in how Rack v1 will improve performance. As everyone is by now aware there are two main factors in this, CPU & GPU. Andrew (@vortico) has recently made some changes that affect CPU performance and I was interested to test these. I will hereafter refer to the v1 development commit I have used as v1dev and it was locally compiled on commit 510f7b2179dcffcd8f2fafaae66f7c0070ee6215. Locally compiled v1dev Fundamental modules were used for patching. As you are als…

The v1 crash my MBP after 30 seconds and put the fans at top speed…seems that the MBP starts to melt…meanwhile Rcomian version works at 90%

[sinnerencia]

I just improve the performance changing the rateframe in settings.json

So, again, GPU performance problems, nothing related to audio or CPU.

[sinnerencia]

So, the thing is…

I can play a lot of Steam games, edit video in 4k and even modeling in 3D, but my MBP can’t render with a normal performance this software

Strange

[JimT]

the multithreading in v1 is far better than my proof of concept hack.

Frame rate limits are definitely need on macs, no idea why.

[roomofwires (Andrew Turner)]

I set my frame rate to 15 in the settings file, performance is good and visuals are fine for my liking (MacBook Pro i5, integrated graphics).

[Vortico (VCV - Andrew)]

Here’s the source, figure it out! https://github.com/VCVRack/Rack

[Skrylar]

@JimT

Frame rate limits are definitely need on macs, no idea why.

Way back when I ran sysprof and friends on linux, I think something like 20-40% of the system load disappeared in to the aether and some of it could be found in pieces that sent off draw calls to the Intel driver. This is on a Cinnamon environment where the GPU is being used to composite windows and do some minor effects, but many applications are still CPU rendering as-needed.

Now keep in mind on macOS you are sharing that same intel driver not with one or two light loads, but all draw calls on every window are being routed through Quartz or similar. It makes most of the UI slick and pretty but there is a lot more contention for draw calls on the mac. (It’s the same user story as the filesystem; file handles on macOS are more expensive than Linux, but they’re also being heavily hooked to run Spotlight and Time Machine indexing.)

Tertiary, Apple doesn’t like OpenGL. They stopped maintaining it some time ago, and its officially deprecated these days. So you’re fighting other apps for the same chip and you’re doing it through an API thats driver is sabotaged/undermaintained.

[JimT]

well yes, that would explain it

[JimT]

somebody sounds demob happy

[Nik (Nik Jewell)]

Best summary of Mac problems that I’ve read. Cheers!