Running 120Hz with low latency on M1 Max

In fact, I get the same behaviour if I modify the LearnMetalCPP texturing example to allow the window to be resizeable, set the preferred framerate to 120 and make the num frames in flight in two places to be 2 rather than 3

void MyAppDelegate::applicationDidFinishLaunching( NS::Notification* pNotification )
{
    CGRect frame = (CGRect){ {100.0, 100.0}, {1024.0, 1024.0} };

    _pWindow = NS::Window::alloc()->init(
        frame,
        NS::WindowStyleMaskClosable|NS::WindowStyleMaskTitled | NS::WindowStyleMaskResizable,
        NS::BackingStoreBuffered,
        false );

    _pDevice = MTL::CreateSystemDefaultDevice();

    _pMtkView = MTK::View::alloc()->init( frame, _pDevice );
    _pMtkView->setColorPixelFormat( MTL::PixelFormat::PixelFormatBGRA8Unorm_sRGB );
    _pMtkView->setClearColor( MTL::ClearColor::Make( 0.1, 0.1, 0.1, 1.0 ) );
    _pMtkView->setDepthStencilPixelFormat( MTL::PixelFormat::PixelFormatDepth16Unorm );
    _pMtkView->setClearDepth( 1.0f );
    _pMtkView->setPreferredFramesPerSecond(120);

    _pViewDelegate = new MyMTKViewDelegate( _pDevice );
    _pMtkView->setDelegate( _pViewDelegate );

    _pWindow->setContentView( _pMtkView );
    _pWindow->setTitle( NS::String::string( "07 - Texture Mapping", NS::StringEncoding::UTF8StringEncoding ) );

    _pWindow->makeKeyAndOrderFront( nullptr );

    NS::Application* pApp = reinterpret_cast< NS::Application* >( pNotification->object() );
    pApp->activateIgnoringOtherApps( true );
}

static constexpr size_t kMaxFramesInFlight = 2;

const int Renderer::kMaxFramesInFlight = 2;

I get 80Hz on average rather than reliably 120Hz when I switch into fullscreen

You use multiple command buffers, and request the drawable as late as humanly possible. You enqueue them, so they can be filled out in threads and sequenced properly.

It's lame but nextDrawable is how the compositor throttles the app.

Also make sure you have the MTKView set to framebuffer only. This will keep it linear for video scan out.

Finally, don't run x64 through Rosetta 2, or Apple has some bug since macOS 11 that limits the top framerate to 60Hz. So you'll never hit 120Hz.

Also don't use 2 drawables. You need to triple buffer. 2 drawables is basically impossible to make work with the macOS and iOS compositor.

Hi,

Alecazam is partially correct about using 2 drawables i.e. not recommended for iOS or iPadOS; however, 2 drawables is ok on macOS assuming you're within frame budget.

Overall we recommend Improving your game’s graphics performance and settings for guidance.

Other than adjusting the number of drawables you may want to reconsider:

swap_chain->setDisplaySyncEnabled(true);

because "that determines whether the layer synchronizes its updates to the display’s refresh rate." i.e. attempts to lock display updates to vsync.

For frame pacing in particular we strongly advise using CAMetalDisplayLink over CADisplayLink (as shown in combination with MTKView in many of our samples). If it isn't meeting your needs for some reason then let's discuss in a new thread. Note that SDL3 is out of scope.

Lastly, you may find Optimizing ProMotion refresh rates for iPhone 13 Pro and iPad Pro helpful.

I would use the CAMetalDisplayLink, but when I adapt the example code for it I get similar issues - it seems like the fullscreen mode management of the drawables is not doing what I would expect.

I suspect that the bugs come from setting the display sync which is somehow using up one of the drawables (through not releasing at the right time) interacting with whatever code decides how long to display the current frame.

The two things seem to influence each other in bad ways. For example, I would have expected that if I pack both CPU and GPU time added together down to sub 8ms, then the very next vsync, it should show and release the drawable for the next frame. But that is not happening and the drawable is being held on to and then the timer which is trying to manage the ProMotion thinks things have gone on too long and hold the frame time too.

I suspect that the display sync enabled code path just has not been tested for 120hz properly when there is more than nothing going on, but way less than 8ms worth.

The CAMetalDisplayLink also does not seem to like the Sync being enabled especially if you have an external monitor attached - it can't seem to tell which monitor has which Vsync

Just if it wasn't clear - I want to lock to VSync because that is optimal from a latency point of view - it should be a guarantee of the smallest time from input to screen because you are synchronising the update code to it.

I am not running decoupled deliberately to have the smallest latency possible

This is an example where everything is complete well before vsync and yet everything just decides to wait for another 8ms. The encoder and the GPU work is completing on the verge of 8 ms. This happens regularly.

In the examples given, the encoder is running and the frame starts / ends when the command buffer is committed, but if you have the vsync enabled but the sync is to get the drawable, then the encoder has to eat up GPU time to be done by the next vsync.

If I go to three drawables to "fix" this timing issue, then it holds back a frame rather than going as early as possible.

I am currently call presentDrawableAfterMinimumDuration with a 4ms duration to try and trick it to release early, but it doesn't seem to make much of a difference