15.4.1 another big step backwards on my system OSX

[Jim Curtis]

Without OpenCL support, and relying on Metal or Software Only rendering, I get no real-time playback whatsoever with .mxf clips with one instance of Red Giant Colorista applied - even at quarter resolution.   A massive number of frames are being dropped, with only occasional bursts of real-time performance.

This is with 4K source footage in an HD Sequence, both at the same frame rate of 23.976.

This renders this version of Pr completely unusable to me.  For reference, Pr 14.9 is still working like a champ, which I infer is because of the OpenCL support that Adobe chose to discontinue for Pr 2021.

I have a powerful MacPro7,1.  System Compatibility Report finds "No Conflicts to Report."

MacPro7,1 - 2.7 GHz 24-Core Intel Xeon W - 256G RAM - AMD Radeon Pro Vega II 32 GB

ATTO R680 PCIe SAS SCSI RAID6 (8 drives)

OSX 10.15.7

I wonder if anybody with a similar computer gets acceptable results on Big Sur, or has any other idea for the reason for my thread title.

[Jim Curtis]

I did that this afternoon, Kevin.  I don't have faith in User Voice, but we'll see.  Thanks for your input.

[Kevin-Monahan]

Use the force. Put the link here to interested folks can upvote the bug. 🙂

[R Neil Haugen]

Adobe is a large corporation, and as such they have their "little ways". UserVoice is more important than most users realize for two reasons.

First, everything posted there now goes to their engineer's Slack channel ... so any engineer can see & track what's coming in for requests and bugs at any time. This is good of course.

But I think the bigger one is a very different thing. Half of" product" Adobe is creating software for other mega-corps to evaluate user experiences. Half of "product" is creating the Creative Cloud apps that end users work with.

And over all of it are the M&E folks ... marketing & experience ... who tend to be the upper people who's decisions matter. And all their decisions are based on metrics ... numbers ... and the one metric we users can actually influence directly is that UserVoice.

The data from requests/bugs per program are evaluated by the M&E types to "inform" the ... suggestions ... that they make to program supervisors regarding budgets, features/bug work, and staffing levels.

So the more we users file U-V requests and bugs, the more effect we can have actually getting something useful done. It ain't perfect, but ... it does work over the long haul.

Neil

[Kyle Plumadore]

Hey Jim,

Are the above numbers consistent with multiple runs? I see that the Prefetch time is significantly different between the two cases. The Prefetch time is generally dependent only on the time taken to decompress your input files - which should be no different between Metal and OpenCL. If you want the most accurate comparisons you can either run the same test multiple times with both Metal and OpenCL, or run the test with Metal, change the renderer to OpenCL then save the project - then importantly - restart Premiere to make sure no frames are cached in memory - then rerun the test to see whether the numbers are similar to the above.

In any case if you have a project and media that you can share that shows a descrepency between Metal and OpenCL, I'd be happy to take a look. If you need a place to upload it to, I can provide one as well.

Thanks,

Kyle

[Jim Curtis]

Thanks, Kyle.  I'll run more experiments tomorrow.  

[Jim Curtis]

Kyle, here are the results of another test.  Pr 14.9, a four minute sequence of mostly .mxf footage, ProRes 4444+, PNG stills with alpha, and some nested sequences with Warp Stabilizing.  This is typical for the work I do.  I cannot share my media with you due to NDA, but I can test on some other footage.

I let the sequence play in its entirety, and quit Premiere between using the two renderers.  So, the number of frames played is the same.

As you can see, OpenCL is exponentially superior to Metal.  TEN TIMES more frames were dropped under Metal than with OpenCL, and the effective frame rate under OpenCL is near real-time, whereas under Metal it’s around half the sequence frame rate (23.976).

Open CL:

<123145403363328> <Dump Playback Queue> <0> =============================== Queue Dump (5768) ===============================

<123145403363328> <UpdatePlaybackStatusInfo> <0>  Frames dropped during playback: 192 / 5769, Preroll(ms): 369.23

<123145403363328> <UpdatePlaybackStatusInfo> <0> Avg Prefetch(ms): 0.0110666, Avg Render(ms): 41.8212, Avg Display FPS: 23.1798

<4439006656> <MZ.MainThreadHangMonitor> <5> Main Thread Blocked for 1.83305 seconds.

Metal:

<123145409617920> <Dump Playback Queue> <0> =============================== Queue Dump (5768) ===============================

<123145409617920> <UpdatePlaybackStatusInfo> <0>  Frames dropped during playback: 2694 / 5769, Preroll(ms): 600.985

<123145409617920> <UpdatePlaybackStatusInfo> <0> Avg Prefetch(ms): 3530.33, Avg Render(ms): 76.5987, Avg Display FPS: 12.9387

[Kyle Plumadore]

Thanks for validating that our memory caching is not coming into play here.

We will try to construct a similar sequence on our end to reproduce this issue. In general, we do not see any significant performance differences between OpenCL and Metal so I suspect that there is something special about either your sequence or hardware that is exposing this issue. If there's anything you can do to help isolate the issue further - e.g. by adding/removing certain formats/effects in your sequence (such as the PNG, Warp stabilized subsequence, mxf files, etc.) it would likely help us reproduce the issue on our end.

[Jim Curtis]

Kyle, I'll be happy to run another test with footage alone, and report what the result is, but that's not very "real world" for my use of Pr.  Adding those variables are common with the kind of work I do most.  Also, I'm snowed with paying work until Oct. 1 (and will be using 14.9 with trusty old OpenCL), so my time is at a premium now.   But, I will get to it, and report back here when I do.  Thanks for your interest helping figure this out.

[David Simonton, DVA]

Jim, I'm trying to create something to simulate your workflow, and I have a question for you that I don't think has been asked yet:

Are there certain parts of your sequence that drop frames, while other segments play back without dropping frames?  If so, I'd be curious to know what all is happening in the parts of the sequence that reliably drop frames.

I've got some 4k media that I'm scaling to fit a 1080 sequence (that's correct, yes?).  Some MXF Op1a, some ProRes4444, some PNG stills with alpha, and I'm applying Colorista (V).  I also have a 1080 source that I've stabilized in its own sequence.  Any other variables I need to throw in?  

[Jim Curtis]

Hi, DS.  Yes, certain sections play without frames dropping, such as when there's one instance of Colorista IV.  But, as soon as the CTI hits a spot with a PNG super, or an additional effect, it starts dropping frames and keeps dropping them.  Once the Dropped Frame light turns yellow, it stays yellow, unless I hit the spacebar twice.  Then, depending on what the section I stopped on has going on, it may stay green for a few seconds before turning yellow again.

I've been given mostly 4K .mxf footage recently, shot at 23.976 that I'm using in 23.976 HD Sequences.  But, I'm seeing the same poor Metal performance with 4K ProRes 422 captured on an Atomos Ninja, and that codec is eaven easier on the GPU than .mxf, IINM.

What kind of computer are you using?

[David Simonton, DVA]

Thanks for getting back to me, Jim.  These tips may be helpful in getting a repro here, and I'll keep you posted.  I've got a 2017 model iMacPro, 3.2GHz, 8-core Xeon, with a Vega64 (16GB).  I suspect it's especially relevant that once you hit a bottleneck, the frames keep dropping and don't recover.  I'll spend some time nosing around in that direction.