アカウント名:
パスワード:
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
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も選択できるようにした、と言うことですが、この割り込み頻度が何を指してるのかわ
unixのスケジュール粒度は昔は10ms程度が普通で(おおむかしはもっと遅かった)、それでも(ほぼ)静止画(キャラクタディスプレイとか、動画を伴わないGUI)だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
3956 Hzの根拠 (スコア:5, 参考になる)
タレコミの文章自体、ちょっと誤訳というか誤解してる感じですね。
(グラフィックワークステーションはOpenGLアプリケーションにおいて、フレームレートのジッタを軽減するという利点がある)
ということだそうで。
実際に秒2000回も表示しなければならないとか言ってるわけでなく、表示間隔のぶれ(ジッタ)を問題にしているのでしょう。
たとえば、割り込み周期が1000Hz だとすると、60Hz のリフレッシュレートの画面表示1回あたり、16.67回の割り
Re: (スコア:3, 興味深い)
このパッチを作られた方が投稿されたメーリングリスト内にある別記事を読んでみたのですが、
この方は、DOOM3などのゲーム(OpenGLアプリケーション)のパフォーマンスを最適化しようとされているようですね。
今回のチューニングの結果、wine上で動かしたHalf-Life:Sourceまでもが "quite a different experience" になったらしいです。
ゲームがサクサク動くのならグラフィックワークステーションにも恩恵があるだろう、ということでしょうか。
デフォルトで1000Hzだった割り込み頻度を3956Hzも選択できるようにした、と言うことですが、
この割り込み頻度が何を指してるのかわ
Re:3956 Hzの根拠 (スコア:3, 興味深い)
unixのスケジュール粒度は昔は10ms程度が普通で(おおむかしはもっと遅かった)、それでも(ほぼ)静止画(キャラクタディスプレイとか、動画を伴わないGUI)だけ出せばすむころは、でまったく問題なかったのですが。インタラクティブな60FPSの描画とかをしたければ、プロセススケジューリングの時間粒度を小さくすると嬉しいんでしょうね。 たしか、昔のUNIX WSでもフライトシミュレータで本気で遊ぶために HZを変えるとかやってました。
3956という値そのものより、現状の1000より4倍早いってほうが効いてるのでは?