"waiting for the GPU" performance issues without -advanced-telemetry

itlancer commented 5 years ago

Problem Description

Application (its swf file) that compiled for debug (not release) with -advanced-telemetry option has more steady and stable performance. Visually also it looks better when -advanced-telemetry enabled. It has been tested with different Windows 8.1/10 and Android devices with latests AIR 32.0.0.144 beta and AIR 33.0.1.228 with different applications and scenarious. The same problem in all cases. With Scout you can see that huge amount of time spent for "waiting for the GPU". Better to reproduce this issue with low-end devices with large smooth video/animations playback or text ticker. It's almost not affect high-end devices but very critical for most of "medium" and lower devices.

Steps to Reproduce

Launch any AIR application that use system resources intensively (with large smooth videos, animations etc) that compiled without -advanced-telemetry for its swf. Better to use device with something like Celeren CPU with 2 GB RAM or cheap Android phone/tablet/TV box. Application example with sources attached. I could send compiled apps by request to reproduce that. waiting_for_gpu_telemetry_performance.zip

package {
    import flash.display.Sprite;
    import flash.events.Event;
    import flash.net.NetConnection;
    import flash.net.NetStream;
    import flash.media.StageVideo;
    import flash.geom.Rectangle;
    import flash.events.NetStatusEvent;

    public class WaitingForGPUTelemetryPerformance extends Sprite {
        private var nc:NetConnection;
        private var ns:NetStream;

        public function WaitingForGPUTelemetryPerformance() {
            addEventListener(Event.ADDED_TO_STAGE, init);
        }

        private function init(e:Event):void {
            removeEventListener(Event.ADDED_TO_STAGE, init);

            nc = new NetConnection();
            nc.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
            nc.connect(null);
        }

        private function netStatusHandler(event:NetStatusEvent):void {
            trace(event.info.code);
            switch (event.info.code){
                case "NetConnection.Connect.Success":
                    ns = new NetStream(nc);
                    ns.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
                    ns.client = {onMetaData:getMeta, onPlayStatus:onPlayStatus};
                    var video:StageVideo = stage.stageVideos[0];
                    video.viewPort = new Rectangle(0,0, 1280, 800);

                    video.attachNetStream(ns);
                    ns.play("video.mp4");
                    break;
            }
        }

        private function getMeta(mdata:Object):void { }//Metadata handler

        //Seek video to begin after complete
        private function onPlayStatus(infoObject:Object):void {
            ns.seek(0);
        }

    }
}

Actual Result: Playback will be choppy with oscillations and lags. You can see these lags with Scout with "waiting for the GPU" in Total Frame Time section spent for some frames. Screenshot of difference between Scout sessions with and without -advanced-telemetry. waiting_for_gpu_telemetry_performance

Expected Result: Smooth video playback without lags. Scout log will be steady without peaks and oscillations.

Known Workarounds

Enable -advanced-telemetry but it consumes more system resources.

BMGMobile commented 3 years ago

We are seeing the same thing after upgrading from Flash 19 to Flash 33, especially with users on 144Hz displays. Obviously we can't ship an advanced telemetry build, nor can we ask our users to do the power management hack in the other thread. This is blocking us from finishing the work to upgrade our Flash version.

Here's our frame time graph without advanced telemetry:

And here's the same one with advanced telemetry:

The problem appears to be in Waiting for Next Frame. Some frames it seems to wait for two frame flips instead of the usual one.

Compare this to a usual frame:

We can provide additional information if requested.

BMGMobile commented 3 years ago

It appears that this only happens if the frame rate is set near or lower than the display refresh rate. Doing the following seems to work around the issue: stage.frameRate = 1000.0;

We are evaluating whether the above workaround is viable for us.

ajwfrost commented 1 year ago

Starting to narrow this down a little .. so we know it happens with the Direct3D 11 display rendering but not the Direct3D 9 version; plus with advanced telemetry it's okay. It seems that the "ActionScript sampling" is actually the trigger to whether it's smooth or not -> take out the sampling and the display goes choppy again. So we can try to work out what part of the sampling is causing the smoothness...

I think the risk though is that this is just about timing. The sampler seems to be on a 1ms timer though so perhaps there's something we can glean from that to improve the general timer/callback loops...

ajwfrost commented 1 year ago

So a little more progress -> yes it seems that having the AS sampler running is just keeping the process a little more active which means that the main loop is running more smoothly. Checking some of the timings in that part (without the sampler running) and we can actually see that there are delays from an OS 'wait' call that are significantly longer than we're requesting...

The good news -> it looks like we may be able to improve the accuracy of the calls, albeit at the cost of some CPU load...

Quite how this then changes things for Android, I don't know! We can have a quick check to see if the problem there is a similar cause..

thanks

Mintonist commented 1 year ago

@ajwfrost I have a suggestion. Can you add comment to tickets mention in release notes as closed? I think it is possible to automate this process. For example in this case:

Mention as closed in AIR 33.1.1.935

It can be helpful for us (because of Github 'Watch' function) and you can receive feedback. So author can close ticket. Thx!

itlancer commented 1 year ago

I cannot say that all my issues related to "waiting for the GPU" solved now but this issue fixed with latest AIR 50.0.1.1. So with low-end devices now all works little better. Thanks!

airsdk / Adobe-Runtime-Support