2つの大きな変更があります。実装方法を選択しただけだといえるかもしれません。Linkage)シェーダーによって、ハードウエアのレンダリング動作を自分で記述することができるようになりました。自由度が高まる反面、動作の種類毎に個別の異なるシェーダープログラムを用意しなければならないという問題も生じました。ライティングアルゴリズムによって数種類。スポットライト等複数存在します。複数光源を照射する場合、オブジェクトの配置位置によって光源の組み合わせが変わるかもしれません。屋外だと平行光源が必要ですが屋内だと必要なかったりします。環境光源+点光源×1~4など。マテリアルによってはテクスチャをレイヤーで複数重ねたり、それぞれのブレンド式を変えるかもしれません。ノーマルマップやレリーフマップを持つ場合、付随して頂点に必要な情報も増えます。持たせるのか、テクスチャによっては共有するのか、パラメータで生成するのかなど。半透明やテクスチャアルファによる抜きの扱いでシェーダーを分けたり。影のレンダリングのありなしや、ライトスペースの求め方の違い、フィルタリングの種類による変更など。アニメーションによって、頂点ウエイトの個数、ビルボード化、ジオメトリインスタンシングへの対応など種類が必要です。これらをすべて自由に組み合わせられるような汎用的な描画の仕組みを作るとシェーダーの数は爆発的に増えます。シェーダープログラムも外部の情報へアクセスはできますし、分岐やループ命令もありました。シェーダーの組み合わせをによるバリエーション数を減らすために用意された機能ではなかったことが問題でした。マテリアル(描画命令)単位で大きな処理の切換えをしたいだけなのに、コード内で分岐を行うのは少々大げさでです。最適化の妨げになるし条件判断コードの実行によるパフォーマンスへの影響もあったので、どちらを取るか選択を迫られます。導入はこれらの問題を解決するために設けられたものです。シェーダーのバリエーションを減らして管理しやすくすることが目的で、プログラム内の命令ジャンプの飛び先を外部から切換えることが可能になりました。分岐切り替えの粒度も不必要に細かくなく適切で、レンダリング命令単位(マテリアル単位)で決められるし、その条件判断もシェーダーの外部で一度だけやればいいわけです。期待が大きい反面、気になる点もあります。マッピングに過ぎず、すべて静的に決まってなければなりません。非常に巨大な単一のシェーダープログラムができあがる可能性があります。コンパイラでできる最適化は減少します。間接ジャンプはインライン化を阻害しますし、結局サブルーチン分の消費レジスタも予めアロケートしておかなければならないのではないか、との疑問も生じます。実ハードが出てからあらためて検証する必要がありそうです。4.0以前をターゲットにしても使えます。表記上の違いだけなので、できることは今までと変わりません。20:51●レンダーステートテセレータにはレンダーステートがありません。