変換機が必要だそうです。この場合入力信号の色フォーマットだけ置き換えるので、同期信号の周波数や解像度などは変わりません。変換しても入力信号にモニタが対応していなければ表示できないようです。解像度まで自由に変換できるものはスキャンコンバータに分類されます。スキャンコンバータはバッファリングが必要なので、ものによっては遅延が発生する可能性があります。トランスコーダを試してみようと思っています。このあたりの情報は下記のページを参考にさせていただきました。ATI(AMD)系だろうとかなり前から使われているテクニックです。この辺の話は後藤さんの記事でかなり突っ込んで紹介されています。http://pc.watch.impress.co.jp/docs/2006/1121/kaigai320.htmこの記事で書かれている3つのスレッディングのうち「カスケード」と呼ばれているものは割と初期の段階から用いられています。後藤さんの説明では「メモリアクセス」のレイテンシを隠蔽するためとなっていますが、これはもともとシェーダーのパイプラインを埋めるのが目的です。実行でない限りパイプラインの終了を待つためにストールが発生します。命令上は順番並んでいても、パイプライン化が行われているためすべての命令実行は半分以上がオーバーラップしているからです。仮にパイプラインステージ数が5段と仮定するとイメージ的には次のようになります。W前の命令完了を待つため数サイクル分のストール(パイプラインの空き)が生じます。そのため動作速度を上げるには、命令を並べ替えて依存関係が発生しないようにプログラムを改良する必要があります。(なお、この例ではレジスタの読み書きに関するストールなので、実際はバイパス化でもうちょっと効率が上がるかもしれません)シェーダーでは依存関係がない複数の演算が同時に大量発生するので、複数のコンテキストを用いたスレッド化(カスケード化)でパイプラインを埋めることができます。3頂点を同時に処理します。依存関係が無いことがわかっているためストールは発生しません。演算が完了しているので、命令の並び上直接依存関係があっても見かけ上レイテンシ無しに実行することができます。この場合特に最適化コンパイラや人間が並び替えで最適化する必要も無く効率が良いことがわかります。レイテンシを考えながら書かなければならない他のハードと比べて、シェーダーのプログラミングが便利で簡単なのはこのおかげだと思っています。その代わり1つの実行パイプでもスレッド数分のコンテキストを保持しなければならず、またパイプラインが深くなればなるほどレイテンシを隠すためのスレッドが余計に必要になることがわかります。このリソース量の上限が実際の演算速度上の制限になっていたようです。リソースが枯渇すると各スレッドの実行に必要なコンテキストの割り当てができず、実行できるスレッド数が減ってしまいます。演算ユニットやパイプラインに余裕があっても、スレッドを発行できずに動作速度が頭打ちになってしまうわけです。性能を謳う部分に「ハードウエアスレッド○○個」と書かれていたことがありますが、このようにスレッド化はインオーダー実行時のレイテンシを隠すための機能なので、その分並列演算能力が増加するわけではありません。理論上は動作効率が変わらないことになります。その分人間やコンパイラが苦労わけですが。命令がかなりあって意外でした。いうかレジスタが128bitでどの命令もSIMDになってるだけでそれ以外は普通な感じです。使うらしいので割と近いのかもしれません。使うようになってますね。系より使いやすそうです。ひとつ意外だったのが、浮動少数演算系の命令が少なくて本当に必要最小限であること。ような至れり尽くせりのベクトル演算を期待すると少々肩透かしを食らいます。ように水平加算系の命令はなく、内積演算等でも同じようにベクトルの並べ替えが発生するようです。スカラー単位の演算ユニットに分離したのとは方向性が異なります。内積などの水平系命令は演算ユニットをまたぐわけですがどのような実装になってるんでしょう。05:24ゲームの開発が大変になったと良く聞きます。ハードの性能が上がってより高いクオリティのものが作れるようになったし、同時にユーザーが求める内容もあがります。その分だけ物量も必要で開発人数も増えて規模が大きくなりました。分業化が進んで個々の作業はさらに専門化し、作る人と考える人の距離が遠ざかります。物量に頼る機会がますます増えてしまいます。ハードの進化についていけずに、力技の対応で食いつないできたつけが回ってきたのかもしれません。開発がついていけないからといってハードの進化を否定するのは少々強引な気がします。既存の環境やハードウエアなら使いこなしているから開発の負担が減るだろうという考えも少々短絡的ではないでしょうか。使っていればやっぱり不満点や足りない点が出てくるものです。速ければ、クオリティがあがるのに、などなど。進化しなければその同じ制限に再び悩まされることになります。当たり前に解決されていることであっても、進化を止めてしまったら古い手法を使い続けなければなりません。スペックはものすごい速さで進化しています。とってプログラマの作業が極端に大変になったかといえばそうでもありません。手法も使えるようになっています。ライブラリが整備され、デバッガも高機能になって、スクリプト言語による開発も幅広く用いられるようになりました。メモリやディスクを大量に消費する重いアルゴリズムでも以前と比べると気楽に使えます。新しいことを覚え続けなければならないのは当然だけど、むしろ制限は減ってきています。前の世代でぎりぎりまで使い切って、限界が見えていればいるほどハードの進化は歓迎すべきものでしょう。したら使いこなせていないときは、ハードの進化が重くのしかかってくるのかもしれません。同じように、データの作成手法でもさまざまな変化が必要でしょう。性能があがったことでいくらでもデータの作りこみができるようになりました。時代に例えれば色数に制限が無くなったようなもので、描こうと思えばどんな絵でも出ます。本当に力を入れるべき表現のポイントを絞らなければならないでしょう。不要な手間はできるだけ省き、人間が手でやる必要が無い部分は徹底的にツール化していく必要があるでしょう。進化はまだまだこれからです。グラフィックがすごすぎます。開発なので、もちろんエンジンそのものが最初からすごいんだけど...。性能を限界まで引き出すすばらしいデータの数々。キャラもマップも今まで見たことが無いくらい、緻密で作りこんであって、それでいてプログラムの性能を活かしきる。エフェクトやシェーダーの効果もさりげなくて実に効果的です。http://www.xbox.com/ja-JP/games/g/gearsofwar/今まで見たゲームの中では最高の緻密さ。圧倒的なクオリティです。いけるんじゃないかと思ってしまいました。拡張ならできるということをすっかり忘れていました。向けプログラミングキットまで出ています。向けプログラムが書けて、演算用のストリームプロセッサとして活用できるようです。数千というスレッドが可能とのこと。http://developer.nvidia.com/object/cuda.html描画向けパイプラインを流用して演算させる手間が要らず、ハードにあわせた専用のシェーディング言語を用いなくても良いわけです。仕様になって非常に汎用性が高く、一般の計算用途に活用できる構造になりました。その先を行ってるわけです。整数型が追加されています。演算やシフト演算子も使えるようになっています。マニュアルにもアセンブラについては書かれていません。相当のアセンブラ命令を見ることができます。整数系命令が並んでいることがわかります。分の演算が必要なので、浮動小数点演算よりも負担が高くなります。制限するオプションがあり、これで浮動少数点相当の演算コストで高速に乗算できるようになっています。受け取ることもできます。2命令必要になります。値で代入できる専用の命令もありますが、演算や代入と同時に結果をフラグに反映させることができます。フラグの更新と参照は依存関係を持つためパイプラインストールに原因になりがちです。2セットのフラグレジスタを使い分けることで回避しているようです。場合は間にラスタライザが介入します。補間を行わない場合は任意の型で渡すことができるようです。記事ばかり眺めていました。アーキテクチャ自体が完全に異なるフルモデルチェンジです。だいたい2世代ごとに完全に生まれ変わります。除いて大幅なアーキテクチャの刷新と、マイナーバージョンアップによる高速化を繰り返しています。速度ではなく機能を求めるプログラマ的には今が買いです。アーキテクチャの改変時は、機能が大幅に増える代わりにあんまり速くなっていないことが多々ありました。どこまでできるのやら。毎に異なるテクスチャを参照するため、その境界がはっきりと見えてしまうことがあります。テクスチャ間で線形補間を行うことができます。方向が加わるためトライリニアフィルタと呼ばれます。大きな差が生じる場合は少々厄介です。カメラに対して大きく傾いている地面や天井は、元のテクスチャ画像よりも細長い形状となります。縦方向(画面の奥に向かって)は小さいテクスチャを参照したいのですが、横方向にはもっと大きな解像度の画像が必要です。そのため高い解像度のテクスチャを参照しつつ、縦方向(画面の奥)に向かって縮小をかけます。filtering)です。効果も引き締まって見えるので見栄えのいい画面になります。データを作ってるようなもの。重い処理となってしまいます。傾きの大きいポリゴン以外は効果が小さいので、場所によってどの程度までフィルタリングするのか使い分けがいります。極端な例だとビルボードには全く必要ないわけです。嫌われることがあります。レンダリングではカメラからの距離に応じて、参照するテクスチャの解像度を切り替えることができます。テクスチャ画像がある場合あらかじめ縮小した画像を次のように何パターンも用意しておきます。256x256128x12864x6432x32:カメラから近い場合は高い解像度のテクスチャを参照しますが、遠くの場合は高い解像度を使う必要がありません。用意しておけばそのため遠くに行くほど小さいテクスチャの参照で済みます。レンダリング時に行われます。正確にはカメラからの距離というよりも、レンダリングするポリゴンの面積から計算すると効率が良いことがわかります。画面のピクセルに対してできる限り1対1で対応する解像度のテクスチャを参照したいたいためです。命令で求めることができます。情報を畳み込む必要があります。点には元のテクスチャのすべての平均値が含まれます。低負荷ながら遠くのポリゴンのちらつきをおさえて画質の向上につながります。使った方がテクスチャフェッチは高速です。できるだけ使ったほうが良いのです。デメリットは、あらかじめ縮小した画像を含んでいる分だけテクスチャ容量が1.34倍程度に増えることです。使われないのは、ひとつは容量の問題でしょう。以降なら容量に対してアクセス負荷が高いので、使用した場合のメリットの方が大きいと考えられます。極端にバスアクセスが速かったり、シェーダーでピクセル演算の方が重くてテクスチャ読み込みが負担にならない場合はこの限りではありません。使ったほうが負荷が高いという思い込みがまだ残っていることかもしれません。画像が過度にぼけすぎることです。画質がぼけすぎるのは、最適な解像度よりも下のレベルのテクスチャが参照されることがあるためです。短い辺では最適な解像度でも、長い辺では解像度が足りなくなってしまいます。見た目よりも低いレベルのテクスチャが参照され、引き伸ばされるが故に余計にぼけているように見えます。視点で描画される地面のように、カメラに対して角度のついたポリゴンはこの傾向が強いので非常にボケボケの画質になりがちです。書き込んだテクスチャの詳細も失われてしまうので、これを嫌がるデザイナーも多いのです。filtering)を活用します。11:57:30)oga/遅くなりましたが情報ありがとうございます。