アカウント名:
パスワード:
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
Graphics workstations, and OpenGL applications may benefit from this, since it gives the lowest framerate-jitter
(グラフィックワークステーションはOpenGLアプリケーションにおいて、フレームレートのジッタを軽減するという利点がある)
ということだそうで。実際に秒2000回も表示しなければならないとか言ってるわけでなく、表示間隔のぶれ(ジッタ)を問題にしているのでしょう。
たとえば、割り込み周期が1000Hz だとすると、60Hz のリフレッシュレートの画面表示1回あたり、16.67回の割り
このパッチを作られた方が投稿されたメーリングリスト内にある別記事を読んでみたのですが、この方は、DOOM3などのゲーム(OpenGLアプリケーション)のパフォーマンスを最適化しようとされているようですね。今回のチューニングの結果、wine上で動かしたHalf-Life:Sourceまでもが "quite a different experience" になったらしいです。ゲームがサクサク動くのならグラフィックワークステーションにも恩恵があるだろう、ということでしょうか。
デフォルトで1000Hzだった割り込み頻度を3956Hzも選択できるようにした、と言うことですが、この割り込み頻度が何を指してるのかわかりません。(ソースが上がってましたが60MBくらいあったので私には読むの無理ですw)勘ですけど(おい!)ハードウェア(ビデオカード、マウス、キーボード)から上がってきた割り込みをカーネルが受けて、それを各アプリケーションに通知する頻度を1000Hzに制限してる、ってことなんですかね?
そうだとすると、最悪1msec遅れる可能性があるわけで、(マウスorキーボード入力→ビデオカードで反映、ならさらに倍)60Hz(16.68ms)や72Hz(13.90ms)で次フレームの処理に入りたいアプリにとってはそれなりの損失かもしれません。
Linuxでゲームやったことないのでなんとも言えないのですが、現状でWindowsと比べて反応の鈍さとか感じられるんですかねぇ?(Windowsの実装がどうなってるかも知りませんけど)
元ネタを読むと「心理視覚最適化」なんて言葉を持ち出すのはなんか違うと思います。
unixのスケジュール粒度は昔は10ms程度が普通で(おおむかしはもっと遅かった)、それでも(ほぼ)静止画(キャラクタディスプレイとか、動画を伴わないGUI)だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
3956 Hzの根拠 (スコア:5, 参考になる)
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
(グラフィックワークステーションはOpenGLアプリケーションにおいて、フレームレートのジッタを軽減するという利点がある)
ということだそうで。
実際に秒2000回も表示しなければならないとか言ってるわけでなく、表示間隔のぶれ(ジッタ)を問題にしているのでしょう。
たとえば、割り込み周期が1000Hz だとすると、60Hz のリフレッシュレートの画面表示1回あたり、16.67回の割り
Re:3956 Hzの根拠 (スコア:3, 興味深い)
このパッチを作られた方が投稿されたメーリングリスト内にある別記事を読んでみたのですが、
この方は、DOOM3などのゲーム(OpenGLアプリケーション)のパフォーマンスを最適化しようとされているようですね。
今回のチューニングの結果、wine上で動かしたHalf-Life:Sourceまでもが "quite a different experience" になったらしいです。
ゲームがサクサク動くのならグラフィックワークステーションにも恩恵があるだろう、ということでしょうか。
デフォルトで1000Hzだった割り込み頻度を3956Hzも選択できるようにした、と言うことですが、
この割り込み頻度が何を指してるのかわかりません。(ソースが上がってましたが60MBくらいあったので私には読むの無理ですw)
勘ですけど(おい!)ハードウェア(ビデオカード、マウス、キーボード)から上がってきた割り込みをカーネルが受けて、
それを各アプリケーションに通知する頻度を1000Hzに制限してる、ってことなんですかね?
そうだとすると、最悪1msec遅れる可能性があるわけで、(マウスorキーボード入力→ビデオカードで反映、ならさらに倍)
60Hz(16.68ms)や72Hz(13.90ms)で次フレームの処理に入りたいアプリにとってはそれなりの損失かもしれません。
Linuxでゲームやったことないのでなんとも言えないのですが、
現状でWindowsと比べて反応の鈍さとか感じられるんですかねぇ?
(Windowsの実装がどうなってるかも知りませんけど)
元ネタを読むと「心理視覚最適化」なんて言葉を持ち出すのはなんか違うと思います。
Re:3956 Hzの根拠 (スコア:3, 興味深い)
unixのスケジュール粒度は昔は10ms程度が普通で(おおむかしはもっと遅かった)、それでも(ほぼ)静止画(キャラクタディスプレイとか、動画を伴わないGUI)だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは?