Live 11.3.X; macOS Intel GUI Freeze still unfixed; GPU error; Metal GPU Timeout Error; CommandQueue, CommandBuffer

[nicobi]

Hi.

I would like to put forward that although Live 11 is at 11.3.41 now it still exhibits fatal Metal GPU errors concerning the Metal command buffer on Intel systems which make Live 11 basically unusable as the GUI will freeze very fast. When running Live 11.3.41 or 11.3.35 and viewing the Console log entries while navigating some freshly dropped 26 Audiotracks in the arranger of a fresh session it will very soon (less than 1 minute) start with

Code: Select all

error	16:04:12.536558 +0200	Live	Execution of the command buffer was aborted due to an error during execution. Caused GPU Timeout Error (IOAF code 2)

problem	16:04:40.608144 +0200	kernel	virtual void IOAccelCommandQueue::retireCommandBuffer(IOAccelEventFence *): Clean slate for app[Live] with 1 GPURestarts in 0 submissions.

and then become indefinitely - and thats the point where the GUI is frozen

Code: Select all

error	16:10:26.495061 +0200	Live	Execution of the command buffer was aborted due to an error during execution. Caused GPU Timeout Error (IOAF code 2)

error	16:10:26.505363 +0200	Live	Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (IOAF code 4)

error	16:10:26.505421 +0200	Live	Execution of the command buffer was aborted due to an error during execution. Ignored (for causing prior/excessive GPU errors) (IOAF code 4)

Interestingly the user can still open a second window which at first behaves normal, but then also starts to exhibit glitches with spinning beachball and then a total freeze.

This is independent of buffersizes, session sample rate. To crosscheck the same tracks were dropped into an empty session in Reaper 7.35 and Logic Pro 10.5.1 (latest compatible version) with zero errors relating to Metal GPU rendering. Although Bitwig Studio is available the last compatible version is 5.1.9 for this system which does not provide Metal rendering. This was introduced in version 5.2. Thus Logic and Reaper show that the used system is more than capable of runnning a session like this. In fact I had sessions in Reaper with more than 70 audio tracks being handled without a hiccup.

The knowledgebase notes for Live > = 11.2 to optionally disable GPU acceleration. Doing this will mitigate the described behavior. But I am asking myself what the cause is for such a fundamentally flawed Metal-based GPU hardware acceleration implementation in Live 11. Honestly speeking it is not acceptable considering that other DAW developers obviously get these things right.

So of course it would be welcomed if that problem could be fixed in the Live 11 - train (some time this year ?) and give users a more performant system. Yet I doubt that some development capacity will be directed to the issue and it leaves mixed feelings concerning the code quality in the Live 12 train.

Notice: This report has been sent to Ableton support.

Mac Pro 5.1 2x6 Core Intel Xeon 5690 3,46 GHz
128 GB RAM
GPU SAPPHIRE Radeon RX 580 Pulse 8GB
macOS 10.14.6
Boot / System: Samsung SSD 840Pro, APFS
Production: WD Black 2TB SATA HDD, HFS+

Focusrite Rednet PCIeR PCIe-Dante-Card

[[jur]]

Did you ever talk about this to Support?

[nicobi]

Notice: This report has been sent to Ableton support.

[benmuetsch]

Good luck with support — I wouldn’t expect any truly helpful advice from them, though.

First off: Avoid using a mixed hard drive setup with both APFS and HFS volumes.

Until about two years ago, I was still running a Mac Pro 5,1 myself, and I managed to avoid those GUI freezes by making sure no HFS-formatted drives were connected. That workaround was something I figured out on my own — support was friendly, but unfortunately not very helpful.

@nicobi: You seem to know your stuff — let’s get in touch!

[[jur]]

Notice: This report has been sent to Ableton support.

My bad!

[nicobi]

Good luck with support — I wouldn’t expect any truly helpful advice from them, though.

Well, I wouldn't be that negative. If we look at the development of (bigger) software companies the last 20 - 30 years - and this appears to be true for other businesses too - support today isn't support anymore as we appreciated a long time ago where you could call up an engineer directly and discuss problems on that level [Of course there are companies where you can - but then you get what you pay for]. So Ableton is no different here I think. It would need direct engineering talk when discussing GPU API stuff - nothing the first line of support would be able to accomplish. You'll probably never get to that anyway because a workaround already has been published for this case: disable GPU rendering. And workarounds are cheaper than fixing it once.

First off: Avoid using a mixed hard drive setup with both APFS and HFS volumes.
Until about two years ago, I was still running a Mac Pro 5,1 myself, and I managed to avoid those GUI freezes by making sure no HFS-formatted drives were connected. That workaround was something I figured out on my own — support was friendly, but unfortunately not very helpful.

This is an advice I came across too. But in fact it does not make sense. Although I do not exclude a slight chance that there could be a dependency between GPU API calls and reading data from disk - really speaking this advice is not applicable. Currently there is proof that the volume format clearly is not the problem here. Otherwise Reaper and Logic Pro X would throw the same errors on the identical system. Yet they run smooth without even a tiny hiccup.

If we take the Console entries simply as they are they state clearly that there is a problem with the GPU command buffer and Event fencing. If you look up these messages in the web you come across some information that will talk about proper „fencing” and execution when populating the command buffers. It appears from what I understand that like buffer overruns a faulty execution leads to a crash on the GPU for those events.

It has also to be taken into account the following: The system in use here supports the Metal API Version 2 introduced June 5, 2017, at WWDC. At the 2022 WWDC, Apple announced the Metal API Version 3 with macOS Ventura. Now Live 12 probably implements Metal V3 (yet I don't know) and on Apple Silicon (macOS Sequoia) currently I do not see any problems with the GPU rendering regarding the observed GPU command errors. If I suppose that Live 11 implements Metal V2 and when I run it on the same AppleSilicon machine I too do not see these errors in console.

Thus to what extend changes where made regarding the CommandBuffer, CommandQueue and event fencing between the two API versions relating to the underlying GPU implementation I do not know. But maybe the solution and fix in the end is pretty simple - some corrected lines of code - who knows.

Of course you are right - especially today it is clearly advantageous to not use conventional HDDs for production volumes but SSDs or flashdrives with APFS - even on „older ” systems. I have already sceduled to replace the HDDs with SSDs which reduces bandwidth dependencies dramatically and offers some other goodies like FS snapshots and alike..

@nicobi: You seem to know your stuff — let’s get in touch!

I am working on getting to know the stuff better - never ending story. You can pm me here ?

[[nil]]

The GPU acceleration in Live 11 and Live 12 both target Metal V2 to be as widely compatible as possible.

As each application is programmed differently, I can't really say if testing with Logic Pro or Reaper gives you an adequate comparison point. Are you sure they do GPU rendering to the extent that Live >= 11.2 does?

[nicobi]

The GPU acceleration in Live 11 and Live 12 both target Metal V2 to be as widely compatible as possible.

Ok, if that is the case that's fine as a DAW like Live probably very likely does not need the features introduced in Metal V3.

As each application is programmed differently, I can't really say if testing with Logic Pro or Reaper gives you an adequate comparison point. Are you sure they do GPU rendering to the extent that Live >= 11.2 does?

Evaluating the current data points I have - yes. It doesn't matter if apps like these are coded differently (going out on a limb here ) . If the developers want to utilize Metal GUI rendering then obviously they all have to use the exact same API and roll with the punches. If they do not roll with the punches the app will exhibit problems in the graphics department. Furthermore the Console Log is the strongest argument here. Live 11.2.x exhibits severe errors as described while the others don't. The frequency of error entries correlate nearly 100 % to the severity of the GUI stuttering and freezes I observe while both Live and Console are running side by side on screen.

There is still another option to check - yet I would have to find time for it. That is to run something like macOS Ventura with OpenCore on the MacPro 5.1 and see what the GUI rendering does there. I looked into the concept but would have to do a thorough evaluation of implementing the OpenCore bootloader. That would also enable to run Bitwig > 5.2 on the machine because Bitwig introduced Metal GPU rendering from 5.2 onwards. Yet maybe macOS 10.15 Catalina would already be sufficient.