可変リフレッシュレートディスプレイ向けの最適化

可変リフレッシュレートディスプレイ向けの最適化

ダイナミックディスプレイタイミングをサポートしているすべてのAppleプラットフォーム上でスムーズな画面更新を実現する方法を紹介します。macOS上のAdaptive Syncディスプレイでフルスクリーンのゲームの更新頻度を調整するためのテクニックを説明して、低電力モードなどのシステム状態がProMotionディスプレイで使用できるフレームレートに与える影響について明らかにします。また、ディスプレイリンクAPIを使用したカスタム描画のためのベストプラクティスも紹介します。

リソース
関連ビデオ

WWDC22
- 電力の制限：バッテリー消費の改善
WWDC19
- MetalのAppとゲームを最適化する
ダウンロード

私は CPU Software Engineeringチームの Kyle Sannerです同僚のAlex Liと一緒に可変リフレッシュディスプレイにおいてAppで最適なフレームペーシングを取得する方法についてお話します macOSに登場するいくつかの新しいディスプレイテクノロジー Adaptive-Sync および全ての条件下でiPadProにカスタム描画をスムーズに実行する方法に焦点をあてますまず Appleプラットフォームで現在サポートされているディスプレイの種類について簡単に説明します
MacのAdaptive-Sync ディスプレイとこのディスプレイのフルスクリーンAppやゲームでスムーズなフレームレートを実現するのに使えるmacOS Montereyの新ツールを紹介します
次に iPad ProのProMotionについて詳しく説明し Appが異なるフレームレートで正しいフレームペースを維持するための CADisplyLinkのベストプラクティスをいくつか見ていきます
Appleデバイス対応のディスプレイの種類を確認しましょう
ディスプレイは固定のリフレッシュレートで動作しますつまり電源がオンになるたびに一定の速度で更新されます iPadのProMotion ディスプレイや macOSの Adaptive-Sync ディスプレイは例外です MacのAdaptive-Sync ディスプレイの新機能を紹介します
Adaptive-Sync表示とは何かを機能を含め説明しますその前に固定レートの表示の仕組みを説明します 60Hzディスプレイに配信されるフレームを示す図です各フレームはディスプレイに表示されディスプレイが更新するまでの16ms間留まります Macで描かれた新しいフレームがフレームバッファに用意されていればその新しいフレームが表示されますそれ以外の場合は前のフレームが再び表示されます
120Hzのディスプレイを見るとリフレッシュレートが 2倍になり表示される間隔が半分になりましたが同じように動作し速くなっています
一方このAdaptive-Sync ディスプレイを見てください静的期間の代わりに各フレームには画面に表示できる時間枠がありますこの画面は付属のディスプレイによって異なりますこのディスプレイは40～120Hz で動作するため8msと25msの間でフレームを画面に表示することができます
最大時間が経過するとシステムはパネルを更新する必要がありディスプレイは短時間新しい更新に対応できなくなりますのでご注意くださいでは Adaptive-Sync ディスプレイではゲームやAppにどのようなメリットがあるのでしょうか? ほとんどがディスプレイの最大リフレッシュレートで実行されるAppでは Adaptive-Sync表示は無料ご提供まずこのシナリオをご覧ください Appは8ms以下で新フレームを生成することができるため 120Hzでかなり安定して動作していますしかしシーンの複雑さが瞬間的に増加するため完成したフレームは前のフレームが最初に表示されてから 9ms後にフレームバッファに到達します固定フレームレート表示では意図した8msではなく 16msで前のフレームが表示されますその結果 Appに違和感が生じます
Adaptive-Syncディスプレイではフレームが完了直後にディスプレイに表示され発生ペナルティは1msのみですこの小さなヒッチはユーザーには認識されませんディスプレイの最大フレームレートに達しないワークロードでは Appがドローアブルを表示する方法に少し変更を加えればスムーズで均一なフレームを提供できますこのシナリオを考えてみましょう複雑なシーンを実行しているゲームは約90Hzで更新を生成できますただし断続的な効果で複雑さが大幅に増加しますが一貫性がなく 66Hzまでの突然のスパイクが発生します AppのGPUの動作を監視することで複雑さの急増に対応しシーンの複雑さが一貫して低くなるまで意図的にフレームの表示を遅くすることができます続いてAdaptive-Syncのベストプラクティスの説明です固定レートのディスプレイでは AppのGPU動作が常にディスプレイのガラス上の間隔を超えている場合ディスプレイの最速のリフレッシュレートの次の要素に達するようにレンダリングを遅くすることを推奨してきました
通常これはこの例のように 1秒あたりのターゲットフレーム数を 60から30に下げることを意味します
ただし Adaptive-Sync ディスプレイに表示する場合はそのガイダンスを変更しています代わりに Appが均等に表示できる最高のレートでフレームを表示するようにしてくださいフレームを均等に表示することに加えてディスプレイがサポートする最小レート以下でフレームを表示すると新しいフレームでディスプレイが使用できなくなりAppでジャダーが発生する可能性があるので注意してくださいただしサポートされている範囲内にある限り Appに最適なレートを自由に選択できます今年Macに登場する新しいディスプレイサポートの概要を理解したところでゲームでAdaptive Syncを有効にする方法について説明しましょうまずサポートされている Macが必要です Apple Silicon GPUを搭載したMacではどれでも機能し最新のIntelベースのMacの多くもサポートしています次にサポートされたAdaptive-Sync ディスプレイが必要で Adaptive-Syncモードを有効にする必要がありますこれはディスプレイシステム環境設定で利用可能な新しい可変リフレッシュレートを選択することで実行できます Appはfull-screen mode で実行する必要があります AppでAdaptive-Syncスケジューリングを試みるか否かの検出のために呼び出だせる APIを見てみましょうまず実行しているディスプレイが Adaptive-Syncスケジューリングに対応しているかを判断する必要がありますそのため今年はNSScreen minimumRefreshInterval maximumRefreshIntervalに新しいプロパティがありますこれらの値はこのディスプレイに表示されるフレームの有効な画面上の時間の範囲を示します固定フレームディスプレイではこれらの値は同じになるため単純な異なる比較によりこの画面が Adaptive-Syncモードであるかどうかがわかります次にウィンドウがフルスクリーンであるかを見ますウィンドウのstyleMask を見るとわかります
AppのAdaptive-Sync 日程計画の利用にはチェックを組み合わせる必要があることを忘れないでくださいいいでしょうこれでAdaptive-Sync ディスプレイとそれを検出するためにmacOSが提供する新しいAPIを理解できたので既存のメタルプレゼンテーション手法の均等表示方法を Adaptive-Sync ディスプレイで見てみましょう
PresentAfterMinimumDurationや PresentAtTimeなどのフレームスペーシングが組み込まれた MetalDrawable APIを Adaptive-Syncディスプレイで効果的に使用することができますまたは現在の呼び出しと独自のカスタムタイマーを使用して独自のソリューションをロールバックもできますいくつかの異なる実装の機能の仕方を見てみましょう
簡単な例から始めましょうここでは Drawableを取得し GPU作業をセットアップして画面に表示しますフレームレートを設定するために利用できるDrawableの背圧に依存しています固定レートのディスプレイでは GPUの動作がディスプレイのリフレッシュレートに一致するという保証がないためこれは最善の策ではないことがわかっています
Adaptive-Syncの画面で撮影した楽器のキャプチャ画面を見ても一貫していれば正しく機能しているようです問題はここが定期的に障害に遭遇していることですこれはユーザーにわかるスタッターに変換されます一定の均等なレート提示でそれを修正してみましょうこの手法はゲームプレーヤーにユーザーが調整可能な FPSスライダーを実装する場合にも使用できますここでは必要な周波数を 78Hzに設定しました単純な現在の呼び出の代わりにこのDrawableに現在の afterMinimumDurationを使用し前述の間隔を指定しますここで要求レートでスムーズにフレームを見れます前の例ほど迅速に提示していませんがユーザーがスタッターに遭遇する可能性ははるかに低く Appが使用するCPUやGPUの時間はより少なくなりますさてここからが少し面白いところです単一の固定レートを設定せずに等ペースのフレームを生成するアプローチを試してみましょうそのためには各フレームの生成に必要なGPU作業の移動平均を計算しその時間を現在のDrawable呼び出しに送り込む方法があります最初のフレームで平均GPU時間を開始値で読み込みますここでは楽観的に考えてディスプレイが対応できる最速のレートを目標にしますこれは平均値の出発点に過ぎないのでどんな合理的な推測をしても大丈夫です次に CommandBuffer完了ハンドラをアタッチして GPUがこのフレームのレンダリングに費やした時間を測定しその時間を移動平均に組み込みましょうまず GPUが作業完了までに要した時間を取得できます次にその新しい時間を移動平均に組み込み次のフレームを提示する際に使用しますそしてこれが結果ですご覧のように前例同様のレートで表示していますがこの限界は以前に生成したフレームによって決定され Mac GPUの範囲全体で均一なフレームレートを生成しますここでは追加コードを変更せずにやや弱いMacで同じプログラムが48Hzで円滑に動作しているのがわかります
さてこれでAppをAdaptive-Sync ディスプレイに最適化するための新しいツールやテクニックを手に入れました macOSのAdaptive-Syncディスプレイについての詳細は Developerサイトの新しいMetal サンプルプロジェクトをご覧ください Metalでパフォーマンステクノロジーを実現するための詳細については過去のWWDC での講演をご覧くださいここからはAlexに交代して iPad Proでのフレームペーシングについて詳しく説明していきますありがとう Kyle 次は ProMotionについて話しましょう 2017年以降すべてのiPad Proには最大120Hzのリフレッシュレートを実現するProMotion ディスプレイが搭載されていますただし今年のiPadOS 15で iPadに搭載された低電力モードをオンにした場合など状況によっては120Hzが利用できない場合があります適切なフレームペーシングにより表示特性ユーザー設定システム状態に関係なく Appはモーションコンテンツを正確かつスムーズに表示できます ProMotionと固定レートの表示の違いおよび一部のフレームレートが使用できない状況について見ていきます次に表示リンクとは何かおよびAppがそれを使用してカスタム描画を実行する方法について説明しますディスプレイリンクのベストプラクティスを紹介します早速ご紹介しましょう Kyoeが簡単に紹介したように 60Hz固定のディスプレイは 16msごとに更新される一定のリズムを持っていますフレームレートが60倍のコンテンツのスムーズな表示をサポートしますたとえば 60Hz 30Hz 20Hz などですただしコンテンツがディスプレイのリフレッシュレートよりもい場合例えば30Hzでもディスプレイ自体を同じリズムでリフレッシュする必要があるため 1フレームごとに前のフレームを繰り返し電力を消費します一方 ProMotionは最大120Hzのリフレッシュレートで優れた応答性を提供しますまた画面上コンテンツに適応し消費電力を削減しますそれがどのように機能するか見てみましょう 120Hzの最大走査周波数では 8ms毎に表示が更新されます
120は60の倍数 ProMotionは既存の全フレーム値をサポートします 20Hzだけでなく Appの中間フレームレートも提供しますさらに ProMotionはリフレッシュレートを動的に調整可能でスムーズな 60Hzコンテンツでは固定の120Hzディスプレイ繰り返しなしで 16msごとにリフレッシュできますこれは24Hzまでずっと当てはまります
現在このフレームレートは常時利用可とは限りません最大フレームレートを60Hzに制限するアクセシビリティ設定でフレームレートの制限をオンにできますまたデバイスが高温になるとシステムが120Hzの利用制限をかけることがあります iPadOS 15では低電力モードでも 60Hzの上限を適用しますではこのシナリオは Appにどう影響しますか？幸いほとんどのAppは変更なく動作しますただし Appがフレームごとのカスタム描画を実行する場合はこのフレームレートの変更に注意する必要がありその方法を説明しますカスタム描画を駆動する推奨ツールは表示リンクで基本的に画面のリフレッシュレートと同期するタイマーですこれは Appドライブをサポートします 2つの表示リンクがあります 1つはmacOSでCoreVideoが提供するCVDisplayLink もう1つは他のプラットフォームの CoreAnimationが提供する CADisplayLinkと macOSのCatalystでそれぞれ特性や動作が若干異なります今日はCADisplayLinkについてのみ説明しますが大まかに言えばこれらの概念は両方に当てはまります CADisplayLinkは vsyncごとに起動しコールバックを呼び出しますこれでアプリケーションが動作を8msで完了します
NSTimerなどの通常のタイマーではディスプレイと完全に同期することはまずありません位相ずれまたはドリフトする可能性があるためAppの作業完了に時間不足でコマ落ちになることがあります CADisplayLinkがいかに安定したタイミングを提供するかを確認できさらにいくつかの利点をご紹介しますディスプレイのリフレッシュレートよりも遅いレートで実行できるため AppはpreferredFramesPerSecond を介してヒントを提供し利用可能な最も近いフレームレートを選択します前述したようにフレームレートの可用性が変わると CADisplayLinkは内部で自動的にレートを調整しますもちろんカスタム描画がこれらの変更を認識できるように Appに必要なタイミング情報も提供しますカスタムアニメーションやカスタムレンダリングループの作成法には触れませんがカスタム描画を表示時期と同期し落とし穴回避のベストプラクティスを４つ紹介します
まずハードコーディングするのではなく実行時にディスプレイのリフレッシュレートの照会が重要です次に通常 CADisplayLink自体のフレームレートを使用する必要があります次に targetTimestampを使用して描画を準備すると障害を減らせます最後に不測の事態に備えるためにタイムデルタを動的に計算することはいつでも得策ですそれらを一つずつ見ていきましょう最大ディスプレイリフレッシュレートは UIScreenを介して照会でき低電力モードがオンになっている場合でさえ ProMotionディスプレイで常に120Hzを返します一方 CADisplayLinkは実際には期間プロパティを介してフレーム間の最短間隔を提供し現在のデバイス状態に基づいて動的に更新しますただしほとんどの場合ディスプレイリンクはディスプレイの最大リフレッシュレートよりも遅くなる可能性があるためフレーム情報はCADisplayLinkから直接使う必要がありますまたフレームレートの可用性はハードウェアに依存し実際のフレームレートはシステム状態変化に応じディスプレイリンク自体によって動的に変わる場合があります例をみてみましょう 40Hzのディスプレイリンクをリクエストするとします ProMotionディスプレイで 40Hzがサポートされていますただし 60Hzディスプレイや ProMotionが60Hzに制限されるとディスプレイリンクは自動的に30Hzに調整されます各ウェイクアップが可能な Vsyncで行われ各フレームに均等な時間を与える良いリズムが確保されます仮にフレームレートを意識しない 40HzのNSTimerを使うとウェイクアップがvsync間隔のちょうど真ん中になってしまい当然そこではフレームを提示できないのでカスタム描画に不具合が発生してしまいますではコード上ではどうなっているのでしょうか？さてこれが通常表示リンクを設定する方法ですまずターゲットとセレクタを準備し呼び出されるコールバックを指定します次に preferredFramesPerSecondで 40Hzの優先フレームレートを指示しますそして表示リンクを現在のランループに追加しそこからコールバックが呼び出されますしたがってコールバックでは targetTimestampからタイムスタンプを差し引くことでディスプレイリンクのウェイクアップの予想間隔を取得できます表示リンク自体が異なる周波数で実行されている可能性がありこの間隔は必ずしも 1対40であるとは限りません次にこのタイムスタンプについて説明しましょう CADisplayLinkには主に2つのタイムスタンプがあります Timestampはコールバックが呼び出される予定の時刻を示し targetTimestampは次のフレームが CoreAnimationによって合成される時刻を示しますここではなぜtargetTimestampを使って図面を作成する必要があるのか例を挙げて説明します 0から1まで正規化した時間領域でのアニメーションです最高のフレームレートを目指し今120Hzであると仮定 CADisplayLinkが起動しタイムスタンプを使用してフレーム表示を準備するとここで直接サンプリングされ次のvsyncで表示されてからこに表示されます
同じ処理を続けると 120Hzのフレームごとにアニメーションの進行が 0.05ずつ増加する良いリズムありますさて熱状態が変化し 120Hzが使えなくなったとしますこれで表示リンクが再び起動し Appは進行状況0.4でアニメーションを準備し次のvsyncでここに表示されます
同様のパターンが続きますここでの推移は何かが誤っています進行状況は0.05増加しますが 1つは8msを超えもう1つは16msを超えています進捗状況を時間軸でプロットすると移行時に不都合が生じそれがユーザーの目に見える形で反映されることになりますがこれは望ましくありません
ではtargetTimestampを試してみましょう CADisplayLinkはここで起動します進行状況はtargetTimestampでサンプリングされ 0.15になります同じパターンが続きここでも良いリズムが見られますこのフレームレート移行ポイントで表示リンクが起動し targetTimestampでサンプリングし 0.50を取得します同様に続きます同じように進捗対時間のグラフをプロットしてみると直線になっているのでフレームレートが変わってもスムーズにコンテンツを提供できることがわかります描画作成にはタイムスタンプではなく targetTimestampを使用しますコード上ではタイムスタンプの使用をすべて targetTimestampに置き換えるだけで十分です最後に時間デルタの動的な計算法を説明しましょう targetTimestampと timestampの差はディスプレイリンクコールバック間の予想時間はわかりますが実際の時間は保証されません優先度の高いスレッドがCPUでスケジュールされているかランループが他でビジー状態の可能性があります極端な例コールバックが完全に飛ぶ可能性がありこの状況で最高のユーザーエクスペリエンスを得るためにカスタム描画で正しい時期を維持するのが特に重要です CADisplayLinkコールバックの呼び出しでAppは次のフレームに必要な更新やレンダリングを準備します通常コールバックはスケジュールされた起動時間に呼び出されますが違うこともありますここで次のコールバックがあると予想していますただし表示リンクは vsync 間隔の数ミリ秒まで実行される機会がありませんしたがって完全な8msを取得できない場合がありますこの場合 CACurrentMediaTime に照会し targetTimestampと比較して使用可能な時間を把握できます
このフレームで作業に時間がかかりすぎているとします次のコールバックはランループの再解放までありません遅延のため次のコールバックはスキップされるのでこのコールバックでカスタム描画の準備をする際カスタムの描画状態が更新される前のタイムスタンプを追跡する場合使用する時間の差分は 8msではなく16msであることに注意してくださいしたがってアプリケーションがカスタム描画の状態を進めるためにタイムデルタを使用している場合カルバックがスキップされるたびにカスタム描画が 1フレーム遅くなります代わりに以前のtargetTimestamp を追跡することで状態を正しく進めることができますまたカスタム描画の作業量が多い場合は targetTimestampを調べ期限に間に合うように作業量を削減できる可能性もあります
ベストプラクティスではリフレッシュレートの推測なし実行する時には必ず照会を実行してくださいカスタム描画はサポートされているフレームレートや異なるレートにも柔軟に対応できる必要があります targetTimestampを使用して問題のないフレームレート移行を確保し表示リンクのコールバックの欠落など予期しない状況に注意してくださいではまとめましょう前半では macOSのAdaptive-Sync ディスプレイで実行する際 Appのフレームペースを最適化する方法を説明しました後半では iPad Proの ProMotionディスプレイ上で Appがカスタム描画を推進しスムーズなフレームペースを維持するためのベストプラクティスについて説明しましたディスプレイ技術が進化し続ける中本セッションが洞察力だけでなくますます動的になるディスプレイのタイミングをサポートするツールやベストプラクティスを提供できていることを願っていますご参加ありがとうございます残りのWWDC2021をお楽しみください [ミュージック]

5:51 - Is Adaptive-Sync scheduling enabled

// Detecting an Adaptive-Sync display

- (BOOL) isAdaptiveSyncSupported:(NSScreen *)screen {
    NSTimeInterval minInterval = screen.minimumRefreshInterval;  
    NSTimeInterval maxInterval = screen.maximumRefreshInterval;  
    return minInterval != maxInterval;
}

// Detecting full-screen

- (BOOL) isWindowFullscreen:(NSWindow *)window {
    return ([window styleMask] &= NSFullScreenWindowMask) == NSFullScreenWindowMask;
}

// Tying it all together

- (BOOL) isAdaptiveSyncSchedulingEnabled:(NSScreen *)window {
    NSScreen* windowScreen = [window screen];
    return [self isWindowFullscreen:window] && [self isAdaptiveSyncSupported:windowScreen];
}

6:49 - Leverage Drawable present calls

// Drawable present APIs with frame-pacing

[commandBuffer presentDrawable:drawable afterMinimumDuration:interval];
[commandBuffer presentDrawable:drawable atTime:t];

// Drawable present API without frame-pacing

[commandBuffer presentDrawable:drawable];

7:11 - A simple example

id<CAMetalDrawable> currentDrawable = [metalLayer nextDrawable];

// Your encoder and command buffers here

[commandBuffer presentDrawable:currentDrawable];

7:55 - Adaptive-Sync in your app 1

id<CAMetalDrawable> currentDrawable = [metalLayer nextDrawable];

NSTimeInterval userFramerateCap = 78.0;
NSTimeInterval userInterval     =  1.0 / userFramerateCap;

// Your encoders and command buffers are still here
[commandBuffer presentDrawable:currentDrawable afterMinimumDuration:userInterval];

8:43 - Adaptive-Sync in your app 2

id<CAMetalDrawable> currentDrawable = [metalLayer nextDrawable];

// Your encoders and command buffers are still available!

NSTimeInterval averageGPUTime = screen.minimumRefreshInterval;

[commandBuffer presentDrawable:currentDrawable afterMinimumDuration:averageGPUTime];

[commandBuffer addCompletedHandler:^(id<MTLCommandBuffer> buffer) {
  const NSTimeInterval GPUTime = buffer.GPUEndTime - buffer.GPUStartTime;

  // Use an exponential moving average
  const double alpha = .25;

  averageGPUTime = (GPUTime * alpha) + (averageGPUTime * (1.0 - alpha));
}];

15:36 - Query the display refresh rate at runtime

// Maximum frame rate from UIKit

NSInteger maxRate = [[UIScreen mainScreen] maximumFramesPerSecond];

// Current maximum frame rate from CoreAnimation

NSInteger currentMaxRate = round(1 / link.duration);

17:06 - Use the actual frame rate of the CADisplayLink

CADisplayLink *link = [CADisplayLink displayLinkWithTarget:self 
                                                  selector:@selector(displayLinkCallback:)];

[link setPreferredFramesPerSecond:40];
[link addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

- (void)displayLinkCallback:(CADisplayLink *)link {
    CFTimeInterval interval = link.targetTimestamp - link.timestamp;

    //...
}

21:47 - Dynamically compute the time delta 1

- (void)displayLinkCallback:(CADisplayLink *)link {
    progress += link.targetTimestamp - link.timestamp;
    [self renderAnimationWithProgress:progress];
}

21:57 - Dynamically compute the time delta 2

- (void)displayLinkCallback:(CADisplayLink *)link {
    progress += link.targetTimestamp - previousTargetTimestamp;
    previousTargetTimestamp = link.targetTimestamp;

    [self renderAnimationWithProgress:progress];
}

22:08 - Dynamically compute the time delta 3

- (void)displayLinkCallback:(CADisplayLink *)link {
    progress += link.targetTimestamp - previousTargetTimestamp;
    previousTargetTimestamp = link.targetTimestamp;

    [self renderAnimationWithProgress:progress withDeadline:link.targetTimestamp];
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC19