Very High GPU usage on windows

[Reaw (Philippe)]

Hello, I’m currently mixing a song with approx. 10 - 15 tracks and using Izotope plugins (VST3) on each track (mainly Neutron 3).

Ardour started to get supper laggy the more tracks I started working on, the DSP stays low so I checked my Task Manager and realized Ardour has an extremely high GPU usage: here 46% but sometimes higher. This should not happen (my GPU is a 3080 TI with latest drivers)

This usage stays even when all plugin windows are closed.

Did anyone have a similar issue, could it be linked to Izotope Plugins? I know they are quite heavy with fancy UI, but still ^^

Also, when restarting Ardour, the program runs smoothly again, until I re-open a few Neutron 3 plugin windows. So it feels like Ardour is still rendering all the windows even though they are closed.

[x42 (Robin Gareus)]

@Reaw

So it feels like Ardour is still rendering all the windows even though they are closed.

That is more or less correct. Ardour unmaps (hides) the windows, but does not destroy the plugin GUI.
It is up to the plugin to not render itself in this case (Ardour does not render the plugin, the plugin does that).

The main idea behind this is to allow to speed up showing plugin windows that were previously visible. Those Plugin UIs do hot have to reload all resources. It is however odd that a plugin renders even if it not mapped on screen, but nothing we can do about (other than destroying the UI).

[Reaw (Philippe)]

Thanks for the info, is there a way for me to force Ardour to “destroy” the plugin’s UI then? Would be even nicer if I could do that for all the plugins at once then

Because currently my only workaround is to restart Ardour all the time which kind of breaks my workflow

[mike3 (mike@overtonedsp)]

That is more or less correct. Ardour unmaps (hides) the windows, but does not destroy the plugin GUI.
It is up to the plugin to not render itself in this case (Ardour does not render the plugin, the plugin does that).

This was the topic of about a three week long ‘discussion’ I had on this forum about whether the close button should close the window (it should) or hide it (leaving all the resources still active) which seemed to be the view of the Ardour devs IIRC.

The key problem is that the plug-in has no way to know (via the plugin API) that ardour has hidden the UI. It is only informed when the UI (the plugin editor in API parlance) is explicitly closed. The result can be that each time you open an instance of the plugin UI a new window / plugin UI instance is created with all the attendant resources, but never destroyed, so you might have 20 instances of a plugin, but only two windows open at any one time. However, as far as the plugin is concerned, all the previous instances you might have opened are still open. So it could be like having 20 plugin windows open.

For CPU driven GUIs this will normally equate to just a lot of memory being used, especially if the UI doesn’t need to be redrawn or / because the user hasn’t interacted with it (logical to assume as its hidden from the user) but for GPU driven GUIs, its normal to render the entire UI every frame, irrespective of whether it has changed or been interacted with - and that will start to burn a lot of GPU cycles (and eat into other GPU resources such as texture memory or vertex buffers)

[x42 (Robin Gareus)]

@Reaw

is there a way for me to force Ardour to “destroy” the plugin’s UI then?

not directly, but you can pick “Edit with generic controls” from the context menu. That will destroy the custom UI and generate a generic view of automatable parameters instead.

[mrskytown (Mrskytown11)]

I have the same issue, as well as other plugins that do the same thing, high usage stuff. I have found a solution, it’s more of a workaround.

What you have to do is after you use the plugin like ozone or whatever, when you right click on plugin from mixer and select edit generic view, it kills the high GPU usage of that plugin, you can even do a test, open a high GPU usage plugin then do the edit generic plugin view or whatever it’s called and it will drop the GPU usage immediately. Another workaround is close the plugin window save and re open session. It should not load the gui automatically unless you open it so that way if you don’t need to see the plugin because you have already processed that track just keep it moving.

This has stopped me from wanting to use izotope plugins, it overheats my Mac all the time, it’s really annoying. At first I thought my GPU was just not good but I heard people with really powerful graphics cards and it’s bringing them to their knees as well. It’s a GPU optimization issue. What

[mike3 (mike@overtonedsp)]

@mrskytown

I have the same issue, as well as other plugins that do the same thing, high usage stuff. I have found a solution, it’s more of a workaround.

Ardour just needs to stop making excuses and do what literally every other DAW (and waveform editor or general host application) in the world does, and call effEditClose (or its equivalent) on the plugin when the user clicks the close button. Otherwise the plugin cannot know what Ardour is doing to its window (without some hacky workarounds intercepting window events / messages - and there is no reason a plugin would expect to need to do this because, literally every other DAW / host application ever made properly tells the plugin to close its editor - via the plugin API provided for the purpose - when the user clicks the close button)

(As an aside, the new CLAP plugin format actually provides separate API calls to explicitly close or to hide the plugin UI as these are distinctly different operations which the plugin would need to handle appropriately)

[John_E]

@mike3

Ardour just needs to stop making excuses […] and call effEditClose (or its equivalent) on the plugin when the user clicks the close button.

Or if effEditClose is problematic for some reason, maybe Ardour could switch the plugin to text mode temporarily (each time its GUI gets closed) and then restore the original setting, next time the user wants to show the plugin again?

[mike3 (mike@overtonedsp)]

@John_E

Or if effEditClose is problematic for some reason, maybe Ardour could switch the plugin to text mode temporarily (each time its GUI gets closed) and then restore the original setting, next time the user wants to show the plugin again?

That’s horrible, really horrible But the process of setting it to text mode surely calls effEditClose as part of switching the UI? And that (I assume) is why it works as a hack to stop Ardour leaking plug-in UI resources. So why would it be problematic just to do the right thing when the user closes the UI?

Its been a while since I’ve been into VST2 UI code, but IIRC the process is supposed to go something like:

1. When the user opens a plugin, the host creates a window, which is destined to contain the plugin UI. Having done this, it passes a reference to this ‘parent’ window to the plugin as part of the call to open the plugin’s editor (GUI).

2. The plugin creates its own editor (GUI) window, and other resources. This window then becomes a ‘child’ of the parent window supplied by the host. So now the plugin’s window is embedded in the host GUI

…

3. When the user closes the plugin UI, the sequence is effectively reversed. First the host calls effEditClose (or equivalent) on the plugin, and the plugin destroys its UI resources, and its own UI window. This removes the plugin’s window from the window hierarchy effectively unmapping it and removing it from the parent (host) window.

4. The host can now (safely) destroy the ‘parent’ window which it was using to contain the plugin.

And this would be similar for other plug-in formats.

[John_E]

Could you submit a patch Mike? Then maybe @Reaw and @mrskytown could test it and see if it fixes their problems.

[x42 (Robin Gareus)]

@mike3

Its been a while since I’ve been into VST2 UI code

OP uses a VST3 plugin.

[mike3 (mike@overtonedsp)]

The principle is the same. You just need to fix it. Why don’t you just fix it?

[x42 (Robin Gareus)]

@mike3

Why don’t you just fix it?

From my perspective is is not a host bug that needs fixing, it is a feature to keep active resources in memory.

The problem is rather resource hungry plugin UIs, perhaps ask them to fix it.

@John_E

Could you submit a patch

It’d be one-liner.

diff --git a/gtk2_ardour/processor_box.cc b/gtk2_ardour/processor_box.cc
index 5ebed34abd..bf671fe71a 100644
--- a/gtk2_ardour/processor_box.cc
+++ b/gtk2_ardour/processor_box.cc
@@ -4676,2 +4676,4 @@ ProcessorWindowProxy::ProcessorWindowProxy (string const & name, ProcessorBox* b
        p->HideUI.connect (gui_connections, invalidator (*this), boost::bind (&ProcessorWindowProxy::hide, this), gui_context());
+
+       signal_unmap.connect (sigc::bind ([](ProxyBase* self) { Glib::signal_idle().connect (sigc::bind ( [] (ProxyBase* s) { s->drop_window (); return false;}, self)); }, this));
 }

[mike3 (mike@overtonedsp)]

@x42

From my perspective is is not a host bug that needs fixing, it is a feature to keep active resources in memory.

I don’t mean to be rude but - seriously?

[John_E]

@x42

diff --git a/gtk2_ardour/processor_box.cc b/gtk2_ardour/processor_box.cc
index 5ebed34abd..bf671fe71a 100644
--- a/gtk2_ardour/processor_box.cc
+++ b/gtk2_ardour/processor_box.cc
@@ -4676,2 +4676,4 @@ ProcessorWindowProxy::ProcessorWindowProxy (string const & name, ProcessorBox* b
        p->HideUI.connect (gui_connections, invalidator (*this), boost::bind (&ProcessorWindowProxy::hide, this), gui_context());
+
+       signal_unmap.connect (sigc::bind ([](ProxyBase* self) { Glib::signal_idle().connect (sigc::bind ( [] (ProxyBase* s) { s->drop_window (); return false;}, self)); }, this));
 }

So hopefully if either @Reaw or @mrskytown is building from source, they could try your patch and report back…

[x42 (Robin Gareus)]

@mike3

As an aside, the new CLAP plugin format actually provides separate API

Yep. Thanks to YT. LV2 also has an API for this. For Audio Units, Apple provides an event listener. I suppose we should ask Steinberg to add a VST3 extension: Issues · steinbergmedia/vst3sdk · GitHub

[mike3 (mike@overtonedsp)]

@x42

Yep. Thanks to YT.

Weird, so you implicitly acknowledge that the two behaviours are different - by virtue of defining the necessity for the different behaviours of hiding vs closing the UI in the API, yet you deliberately do the wrong behaviour when then user closes the UI (despite that being the one action that is already supported in every plug-in API - and which every other DAW uses) and then consistently argue that this is a feature not a bug. This is seriously messing with my head. Its like arguing with someone who has decided 1 + 1 = 3 because ‘it’s better like that’. Perhaps arguing is too stronger word, but no rational logical debate makes sense anymore.

If the suggested patch works - and I would suggest rigorous testing - particularly on Linux, as that is where any nasty ‘who owns the window’ clashes will be evident when you close the UI - hence the reason I (tried) to explain the importance of creating and destructing the host vs plugin editor windows in the appropriate manner.

Its consistently odd (and disappointing) to me that I experience such pushback at almost every interaction I have. I have a wealth of (over 30 years) professional experience, and insight, which should be a useful asset to any project. I’ve developed one of the few ranges of professional audio plug-ins specifically for Linux - which should be an asset too - maybe not to Windows users but, particularly a Linux-centric DAW - and yet I am routinely dismissed here - by virtue of unfathomable reasoning. Can we just try to make things work better for the users - if nothing else?

[x42 (Robin Gareus)]

The idea is that the plugin can decide what to do when a user closes (and re-opens) the window. The host does not know what a plugin UI may or may do, so this is best left to the plugin.

The problem is also likely related to Microsoft’s convention that the Window bar “X” is associated with quit or terminate; an operation which releases resources. While on all other OS/WM the it simply closes the Window.

[mike3 (mike@overtonedsp)]

@x42

The idea is that the plugin can decide what to do when a user closes (and re-opens) the window. The host does not know what a plugin UI may or may do, so this is best left to the plugin.

In this case it can’t decide what to do, because you don’t call the API function so it doesn’t know anything has actually happened. That is the whole crux of the issue.

Sort it out amongst yourselves. I’ve given you the best insight I can into what should be happening. I have plenty of plug-ins available if you want something to test with, but I have better things to do with my time than drive myself insane trying to convince you or anyone else here that when you click what is commonly accepted as the close button on a window, the expected behaviour should be to close the window. If that’s not obvious I have nothing more to add.

[Sojuzstudio (Mika Kilpi)]

Do I understand correctly? All the plugin windows that I opened during the session remain somewhere in the background, consuming valuable resources, even though I thought I had closed them?

It doesn’t make any sense, at least from the user’s point of view.