前回は、NVIDIA(緑のたぬき)と、今はAMDのATI(赤いきつね)との激しい「化かし合い」の話題をお届けしたが、今回は前回に入りきらなかった「その後のバトル」を紹介したい。
このバトルは、前回取り上げた「FP24演算精度論争」と同じくらい、「正確性よりも、それなりの見た目が担保されていればパフォーマンス優先でよい」というその後の「ゲームグラフィックスの最適化方針」を決定づけたとも言える事象になるので、あえて取り上げることにしたい。
テクスチャフィルタリングを巡る新たな戦い
2002年から始まった「GeForce FX系とRADEON 9000系の闘い」のあとも、NVIDIAとATI(AMD)の闘いは続くことになる。
たとえば「NVIDIAのG-SYNC(2014年)対AMDのFreeSync(2015年)」や「NVIDIA Mesh Shader(2018年)対AMDのPrimitive Shader(2017年)」の闘いなどは比較的メジャーな規格化戦争として知る人も多いだろう。まあ、これらは比較的最近のことなので、本稿で取り扱うのはまだやめておく。
本稿では、もっと「地味な闘い」で、しかもその後のGPU関連技術に深く影響したバトルを紹介したい。
それは2004年あたりから始まった「テクスチャフィルタリング技術最適化の乱」だ。
このバトル自体は、すでに1990年代から、「ユーザーの意識がおよばぬ領域」で密やかに行なわれていたと思われるが、GeForce FX系の後継であるGeForce 6000系(NV4x)と、RADEON 9000系の後継のRADEON X800系(R4x0系)とが戦っていた時代に“表沙汰”となった。
GeForce FX時代に、マウントされまくっていたNVIDIAは、ATIに対して「なんか一言、言い返してやりたい」と思っていたのだろうか。
NVIDIAは「テクスチャフィルタリング処理の異方性フィルタリング(Anisotropic Filtering)において、ATIのRADEON X800シリーズはインチキをしている」と声明を出したのだ。
テクスチャフィルタリングをアンチエイリアスと混同されているゲームファンも少なくなく、馴染みのない方も多いと思うので、本稿では前提知識として、この技術概要について解説をしておこう。
テクスチャフィルタリング技術とは
PCゲームファンからすれば「テクスチャフィルタリング」というキーワード自体は、各ゲームのグラフィックスオプションの設定項目にもよく出てくるので、結構見覚えがあるのではないだろうか。
テクスチャとはポリゴンに貼り込む画像……すなわちステッカーのようなものという認識があると思うが、実際の「画像系のテクスチャデータ」そのものはデジカメの写真データのような、いわば画像データである(さすがにJPGファイルではなく、グラフィックスメモリには独自形式で格納されているが)。
だから、色情報を持った画素データが何ピクセル×何ピクセル……みたいな感じでグラフィックスメモリに格納されている。画面を構成する画素を「ピクセル」というが、これと同じようにテクスチャを構成する画素を「テクセル」という。
実際にポリゴンにテクスチャを貼り付ける際(このプロセスをテクスチャマッピングというわけだが)、そのポリゴンが視点から遠かったり近かったり、あるいは傾いていたりする関係で、ゲーム画面内の各ポリゴン達を構成するピクセルに、テクスチャマップのテクセルが1対1でうまく対応して貼り付けられるケースはほとんどない。
一口にテクスチャマッピングとは言うが、実際のポリゴンへの貼り付け処理の際にはテクスチャを拡大縮小したり、変形したりする“画像処理”が必要になるわけだ。
テクスチャフィルタリングとは、このときの“画像処理”を高品質に行ない、見栄えをよくするための仕組み……と考えると概念的に分かりやすいだろう。
では逆に、テクスチャフィルタリング処理をまったく適用しないとどうなるのか。
ゲームファンであれば、昔懐かし、初代プレイステーションやセガサターンの3Dグラフィックスを思い浮かべればいい。拡大されたテクスチャがモザイク模様のような映像になっていたと思う。あの状態だ。
視点に近い手前では、生のテクセルが拡大表示されて矩形形状が非常に目立ってしまっている。一方、奥まったところはごちゃごちゃしていてディテール感が欠如している。
この方式ではポリゴンを構成するピクセルに最も対応すると判断されるテクセルを1つだけ取ってきて貼り付けるだけの処理系で成り立っている。
つまり、1ピクセルに対するテクスチャマッピングの際に、テクスチャユニットがグラフィックスメモリから取り出してくるテクセルは1つのみということであり、パフォーマンス的には無駄がない。
なお、ここでは「テクスチャフィルタリング無し」として呼称しているが、この処理系自体は「ポイントサンプル」と呼ぶ。
テクスチャフィルタリングの基本形「バイリニアフィルタリング」
最も原始的で、しかも効果はそれなりに高いテクスチャフィルタリングが「バイリニアフィルタリング(Bilinear Filtering)」だ。
この手法では、1ピクセルに対するテクスチャマッピングの際に、テクスチャユニットは、テクスチャマップから4テクセル分を取り出し、テクスチャの拡大縮小率を吟味した上でこの4テクセルの色を混ぜ合わせ、最終的なテクセルの色を決定する。
フィルタリング無しの時と比較すると、1ピクセル毎のテクスチャマッピングの都度、4倍もテクセル読み出しが発生することになる。
この処理系は、いわゆる「“2”次元的な“線形”補間」が行なわれることに相当するので、「Bi-Linear」フィルタリングと呼ばれるわけである。
家庭用ゲーム機ではニンテンドー64がこの方式のテクスチャフィルタリング機能を内蔵していた。言うまでもないが最近のGPUにもこの処理系は内蔵されている。
「フィルタリング無し」時に見られたモザイク感が、ほとんど姿を消しており、「いい感じのぼやけ」になっている。ただ「悪条件が重なる」と、視点からある離れた地点付近に、その“ぼやけ”方に境界線のようものが顕在化することがある。
下は「奇妙な境界線」が露呈した事例だ。
ちなみに、この「奇妙な境界線」は、テクスチャの貼り付け対象となるポリゴンが、視線に対して直交しているとき(言い換えればポリゴンとディスプレイ面が平行なとき)には出現しない。
しかし、逆に上の画像のように、視線に対してパースが効いたポリゴンに貼り付けられたテクスチャマッピングでは盛大に目立つ。
なお、実際の3Dゲームグラフィックスにおいて、画面内のほとんどのポリゴンは、視線に対して幾ばくかは傾いている。つまり、バイリニアフィルタリングでは、ほとんどのシーンにおいて、この境界線が露呈する可能性があることになる。
では、この境界線の正体はなんなのか。
結論から言うと、これは「MIP-MAP」の切り替えポイントに相当する。
MIP-MAPとはなにか
視点から近いところにあって、大きく見えるポリゴンにテクスチャを貼る際、ポリゴンの大きさと比べて貼り込むテクスチャが小さいときには、テクスチャを拡大処理しなければならない。
この時のテクスチャマッピングでは、先ほど解説したバイリニアフィルタリングを実践することになる(≒読み出したテクセルをボックスフィルタにより拡大して適用することになる)。結果、「それなりの滑らかさ」で拡大されてテクスチャが貼り付けられるわけだ。
では逆に、視点から遠いところにあって小さく見えるポリゴンに、そのポリゴンサイズよりも大きいテクスチャを張らなければならないときは、テクスチャマッピングの前に、テクスチャの縮小処理が必要になるのが想像できるだろう。
高品位な縮小を行なうには、複数のテクセルを読み出してその平均値を求めていかなければならず、縮小率が上がるにつれてより多くのテクセルを読み出して平均値を計算しなければならなくなる。
拡大時には4テクセルで済んでいたバイリニアフィルタリング時のテクセル読み出しが、縮小時には倍々に多くなってしまうのだ。
縮小のたびに計算していては効率が悪いよね……ということで、GPUには、あらかじめテクスチャマップの縦横の辺を1/2ずつ縮小させた、面積比で言うと1/4、1/16、1/64のテクスチャをあらかじめ用意しておき、必要に応じてこの「縮小テクスチャ」からテクセルを読み出す仕組みが搭載された。
この「縮小テクスチャの仕組み」が「MIP-MAP」だ。一種の「事前計算を取り入れた最適化」だ。
複数存在するMIP-MAP中の、どの縮小レベル(MIP-MAPレベル)の縮小テクスチャからテクセルを取り出してくるかは、テクスチャマッピング適用対象のポリゴンが、視点からどのくらい離れているか……によって決められる。
なので、テクスチャマッピング対象のポリゴンが「視点の近いところから遠方まで奥行き方向に長い」、なおかつ「適用するテクスチャマップが1枚画像である」というケースでは、テクスチャユニットは、単一のテクスチャマップを貼り付けるにも関わらず、MIP-MAPレベルを切り替えながらテクスチャマッピングを行なうことになるわけだ。
典型例としては「ドライブゲームの道路」を思い浮かべよう。
同一テクスチャ(道路の場合ならばアスファルト模様テクスチャ)が手前から奥に向かって貼り付けられることになり、視点からある程度離れたあたりに、このMIP-MAPレベルの切り替えポイントが可視化されてしまうのだ。
奇妙な境界線が出ない「トライリニアフィルタリング」
この「奇妙な境界線」を出ないように克服した、バージョンアップ版のテクスチャフィルタリング技法が「トライリニアフィルタリング」(トリリニアフィルタリング)になる。これもPCゲームファンならば見たり聞いたりしたことはあるだろう。
トライリニアフィルタリングでは、バイリニアでは無視していた「MIP-MAPの切り替えポイント」に対しても、線形補間を適用する“きまじめ”なテクニックになる。つまり、視点からの奥行き距離に対応した第1候補のMIP-MAPを選ぶだけでなく、第2候補のMIP-MAPまでをも選ぶのだ。なんて“きまじめ”な！
たとえば、レベル0のMIP-MAPが第1候補として選ばれたならば、第2候補として、レベル1のMIP-MAPをも採択するわけである。これを本稿では「1ペアのMIP-MAP」と呼称することにしたい。
あとは、バイリニアフィルタリングと処理系は同じ。「1ペアのMIP-MAP」の両方からテクセルを取り出して、バイリニアフィルタリングを適用していく……といった感じになる。
より具体的に解説すると、1ペアの隣り合う2つのMIP-MAPテクスチャからテクセルをそれぞれ4つずつ……合計8つのテクセルを取り出し、これら8テクセルの色の値を元に、奥行き(≒縮小具合)に配慮しつつ、線形補間を行なって最終的なテクセル色を決定していく……ということだ。
常に2つの、異なるMIP-MAPレベルのテクスチャからテクセルを読み出して処理していくので、バイリニアフィルタリングで見られたような、MIP-MAPレベルの切り替えポイント(奇妙な境界線)が可視化されなくなるのだ。
しかし、視線とポリゴンの向きの関係は、依然と無視されたままの技法であるため、テクスチャ貼り付け対象のポリゴンが奥にあればあるほど(テクスチャの縮小率が上がれば上がるほど)、テクスチャ本来の解像感やディテール感が失われる。
「奇妙な境界線」が見えなくなっただけで、見た目の印象としては、あまりバイリニアフィルタリングの結果と差が感じられないのである。
傾きにも配慮した高度な「異方性フィルタリング」
荘厳なテーマ曲とともに、あらすじを記した黄色い文章が、星空背景の奥行き方向に流れていく、あまりにも有名すぎる、映画「スターウォーズ」の始まりのシーンを思い浮かべてみてほしい。
パースが付いた文書は、手前の文字は大きく見えるが奥の文字は小さく見える。遠近があるので当たり前のことだ。
小さく見える奥の方の文字は密集して見える……つまりは狭い範囲に多くの情報が密集していることになる。
これを踏まえた上でテクスチャマッピングを考えてみると、視線とポリゴン面が織りなす角度関係が鋭角だったり、あるいは遠景ポリゴンへのテクスチャ適用の際には、画面上のたった1ピクセルへのテクセル適用においても、テクスチャマップ上の広範囲のテクセルを取り出して演算して最適なテクセル色を決定しないと「ただボケるだけ」のテクスチャフィルタリングとなってしまう。
バイリニアやトライリニアでも、視点とポリゴンの距離関係に応じて、MIP-MAPを用いて縮小率に配慮したテクセル選択は行なっていたが「視線とポリゴン面の織りなす角度」についてまでは無視していた。
だから、バイリニアやトライリニアでは、遠方に行けば行くほど、角度がきつければきついほど、テクスチャマッピング時のディテール感が失われていたのだ。
ゲームグラフィックスのオプション項目において、たびたび目にする「異方性フィルタリング」(別名、アニソトロピックフィルタリング : Anisotropic Filtering)は、「視点とポリゴンの遠近関係によるMIP-MAP選択」だけでなく、「視線とポリゴン面が織りなす角度関係にも配慮して最適なテクセルを取り出して線形補間する」テクスチャフィルタリング技法なのである。
下の画像を見ると分かるように、手前から奥まで、一定のディテール感が保たれている様がよく分かる。
「異方性」という難解そうな字面に「なにそれ」っとドキッとさせられるが、このキーワード、3Dグラフィックスではよく使われる傾向にある。意味合い的には「やるべきことを臨機応変に賢く切り換える手法」というイメージの捉え方でいいだろう。
異方性フィルタリングの「2X/4X/8X」ってどういう意味？
バイリニアやトライリニアではボケボケだった奥の密集域でもテクスチャ模様が非常に鮮明に見えるところが、異方性フィルタリングの最大の特長になる。
異方性フィルタリングの動作メカニズムを図示化したものを下に示す。
この図の左側は、視線上では傾いて描かれる1枚の正方形ポリゴンに、あるテクスチャを貼り付けようとしている状況と思ってもらいたい。
四頂点が直角な正方形のポリゴンも、3D空間上で視点から傾いて見えているので、歪んで変形した四角形に見える……そんなイメージだ。
この時、この図の左側のポリゴン上の「Pixel’s Cell」部分に貼り付けるテクセルはどんなものになるかを考えてみる。
ポリゴンが傾いていようが、描画画面(ディスプレイ画面)はすべての画素が縦横に直列配置された格子構成になっている。当たり前のことだ。だから「Pixel’s Cell」は、この図を見るものに正方形として表されている。
一方、図の右側は「ビデオメモリ上に格納されているテクスチャ」をイメージしたものだ。テクスチャは、ポリゴンにどんな形に変形されて適用されようが、ビデオメモリ上では256×256テクセル……みたいな感じで整然とした解像度画像として静的に格納されている。
以上のことから、図左の「Pixel’s Cell」部分に適用すべきテクセルは、対応する図右内に描かれた“下すぼみ”の四辺形領域内部のテクスチャ領域から取り出されることになる。
本来、広い範囲からテクセルを取り出さなければディテールは向上しないのに、バイリニアでは代表1点からだけ。トライリニアは代表2点から取り出すと言っても、MIP-MAPが異なるだけで、数理上、同一の代表点から取り出しているに過ぎない。
だから、視線とポリゴンの角度関係がきつくなればなるほどバイリニアやトライリニアでは「ディテール感の乏しさ」がよく似た傾向にあったのだ。
これに対し、異方性フィルタリングは「視線とポリゴン面の織りなす角度」に配慮した、より多くの代表地点からテクセル取り出しを行なう。この代表地点の個数が、ちょうど異方性フィルタリングの品質設定に相当する。
ゲームのグラフィックスオプションの異方性フィルタリング(Anisotropic Filtering)設定には、「2X/4X/8X」とか「2:1/4:1/8:1」のような設定が選べるが、これはこの「代表地点の数」に相当する。
上図の右側は「MIP-MAP samples」を2点取っているので「2X」や「2:1」に相当する設定になる。設定値を上げていくと、「line of anisotropy」上の「MIP-MAP samples」の数を増やしていくことに相当する。
異方性フィルタリングにはバイリニア型とトライリニア型が存在
さて、ここまでで異方性フィルタリングの基本的な考え方は理解していただけたかと思う。
しかし、この異方性フィルタリングという技法、その実践手法は1種類ではないのだ。それを説明するために、ここまで、長々と説明してきたというのもある。
実は、異方性フィルタリングは、大別して2タイプがあり、1つはバイリニアタイプ、もう1つはトライリニアタイプだ。
テクスチャフィルタリングは、バイリニア、トライリニア、異方性の3種類ではなく、本当はバイリニア、トライリニア、バイリニア型異方性、トライリニア型異方性の4種類があるのだ(笑)。
どういうことか。
上で説明した異方性フィルタリングの「異方性処理」で求めた2X/4X/8X/16Xといった複数の代表地点は、テクセルのサンプリング数を表してはおらず、サンプルすべきテクセルの場所(代表地点)の数を表しているだけだ。
だから、実際には、その各代表地点に対して、複数テクセルを取り出して、バイリニアフィルタリングなり、トライリニアフィルタリングなりを実践しなければ異方性フィルタリングは完遂されない。
見方を変えれば、バイリニアフィルタリングの異方性拡張版と、トライリニアフィルタリングの異方性拡張版がある……という考えの方が分かりやすいかもしれない。
たとえば、前出の図のような、2地点(2X)の異方性フィルタリングの実践を考えてみる。
この2点の代表地点から、それぞれ4テクセルずつを取り出してバイリニアフィルタリングを適用するのが「バイリニア型異方性フィルタリング」(Bilinear Anisotropic Filtering)だ。
つまり、この方法では「異方性フィルタリングの品質で指定した代表地点数の4倍のテクセル」が読み出されることになる。たとえば2X設定のバイリニア型の異方性フィルタリングならば8テクセルが読み出されることになるわけだ。
この方式は、異方性フィルタリングではあるが、実践されているのはバイリニアフィルタリングなので、その弱点を見事に継承してしまっている。
そう、MIP-MAPの切り替えポイントが「奇妙な境界線」として可視化されてしまうのだ。
前へ突き進んでいくようなタイプのゲームで、異方性フィルタリングを適用しているのにも関わらず、奥の方でテクスチャのボケ方の境界線が見えるような場合は、バイリニア型異方性フィルタリングが適用されているとみていいだろう(下図)。
そして、もはや説明は不要かもしれないが、より高品位な結果が得られるのが「トライリニア型異方性フィルタリング」(Trilinear Anisotropic Filtering)だ。
この方法では異方性フィルタリングの品質で指定した代表地点数に対して、視点からの奥行き距離に対応した1ペアの2つのMIP-MAPを参照して4テクセルずつ、つまり合計8テクセルを取り出してテクスチャフィルタリング処理をする。
前出の2Xでいけば、2つの代表地点それぞれから8テクセル読み出されるので、全体としては合計16テクセルの取り出しが行なわれることになる。バイリニア型異方性フィルタリングのときの、ちょうど2倍のテクセル量を取り出すことになるわけだ。
2つのMIP-MAPからテクセルを取りだして、なおかつ奥行きに配慮した形で補間されるので、(ノーマル版のトライリニアフィルタリング」がそうであったように)トライリニア型異方性フィルタリングではMIP-MAPの切り替えポイントが可視化してしまうことがない(下図)。
結論としてはトライリニア型異方性フィルタリングこそが、汎用かつ基本形のテクスチャフィルタリング技術としては最良の結果が得られるテクスチャフィルタリングメソッドだとされている。
ただ、処理として重いのは想像に難くないだろう。
異方性フィルタリングの品質パラメータ(=テクセル参照先の代表地点の数)で「16X」を与えたときには、1テクセルの値を算出するのに、なんと128個(16地点×8テクセルサンプル)ものテクセルを取り出して演算をしなくてはならないからだ。
なお、豆知識としてバイリニア型異方性フィルタリングは品質パラメータの4倍、トライリニア型異方性フィルタリングは品質パラメータの8倍のテクセル読みだしが必要だということを覚えておくといいだろう。
「最適化」という名の「手抜き」～見た目に違いがなければありでしょ？
だいぶ前置きが長くなったが、GeForce 6800とRADEON X800のパフォーマンスを比較した場合、テクスチャフィルタリングを「異方性フィルタリング」に設定してゲームやベンチマークソフトなどほ実行すると、GeForce 6800と比較して異様にRADEON X800のパフォーマンスが高いことに、NVIDIAが気が付くのだ！
「ATIさんよ、あんた達またなんかやってるだろ？」とNVIDIAが言ったかどうかは分からないが、当時、わざわざ「An Act of Desperation」(あなたたちって死に物狂いなんですか？)とどこかの論破王が言いそうな声明までを出していることから、NVIDIAの顔面真っ赤ぶり(真緑？)は容易に想像が付く。
バイリニアフィルタリングやトライリニアフィルタリングのような単純な処理系ならいざ知らず、異方性フィルタリングのように、処理系が複雑になってくると、逆に「最適化」とか「高速化」という名の「手抜きどころ」……よく言えば「工夫しどころ」が出てくるのである。
さて、異方性フィルタリングは、視線とテクスチャを貼り付けるポリゴンとの角度関係に応じて、2X～16Xといったパラメータで与えられる、複数地点に対するテクセル参照を行なうことを説明した。
また、視線に対して角度のきつくなっているポリゴンには、広範囲のテクスチャが凝縮されるようなイメージで適用されることについても説明した。
しかし、そうでもない地点に対し、トライリニア型異方性フィルタリングならば、x16設定で128個ものテクセル参照を行なうのはちょっとやり過ぎなのではないか。もっと少なくても結果には大差ないのではないか。そういう「手抜きどころ」「工夫しどころ」の発想が思い浮かんでくる。
たとえば、視点位置との距離関係によっては、処理の重いトライリニア型異方性フィルタリングの方ではなくて、バイリニア型異方性フィルタリングで代行してもほとんど映像結果には差がないケースも出てくるのではないか。
ならば、距離にも応じて処理系を「バイリニア型異方性フィルタリング」と「トライリニア型異方性フィルタリング」を適宜切り換えてやってもいいのではないだろうか。
これをやれば、かなりの高速化に結びつくはずだ。なにしろバイリニア型異方性フィルタリングで代行させた部分は、トライリニア型異方性フィルタリングの半分のテクセル処理量で済むのだから。
……という感じで「手抜きどころ」「工夫しどころ」の発想がどんどんと具体化してくるわけである。
実のところ、ATIは、RADEON X800でこうした「最適化」を導入していたのだ。
ATIは、NVIDIAの指摘に対して「よくぞ、分かったな、NVIDIAの諸君！また逢えて光栄の至りだ」といったかどうかは定かではないが、ATIは「そんなこと言うNVIDIAさんも、やってますよね、我々と似たようなこと」と反論。
実は、NVIDIAもGeForce6800系にて、上で挙げたような最適化を実践していたのである。
これは、Ralf “Demirug” Kornmann氏制作の「D3D AF-Tester」で調査すると一目瞭然であった。
この「異方性フィルタリング品質検証テストプログラム」は、各MIP-MAPレベルのテクスチャにおいて“あえて”異なる単色で塗りつぶしてしまったテクスチャを、奥行き方向に伸びるトンネルの筒状の壁面に対して、異方性フィルタリングを適用しながらテクスチャマッピングをしていくようなものだ。
視点はトンネルの中心にあって奥行き方向を見据えているので、理想的には色分けされたMIP-MAPが、同心円状にトンネル壁面に現れなければならない。
下に、このテストをRADEON X800とGeForce 6800で実行した結果を示す。参考までに、近代GPUのGeForce RTX 3090とRadeon RX 6900 XTの結果も合わせて示しておこう。実践した異方性フィルタリングのタイプはトライリニア型で、品質設定は「4X」としている。
さすがは最新世代のGPUであるGeForce RTX 3090とRadeon RX 6900 XTでは、ほぼ同心円状に色分けされたMIP-MAP模様が出現している。理想通りの結果である。しかも結果自体が“うり二つ”である。
一方で、GeForce 6800とRADEON X800では、花形のような模様になってしまっている。しかも、花形の花びらの出方が結構異なっているのが興味深い。
この「花形」の結果からは、視線とテクスチャ適用先のポリゴン面とが織りなす角度や距離に応じてMIP-MAPの参照法やテクスチャフィルタリングの種類を切り換えていることの現れと推察できる。
詳しいアルゴリズムまでは分からないが、条件によってテクセルサンプル数を減らしたり、あるいは処理の重いトライリニア型異方性フィルタリングを避けて、部分的に処理の軽いバイリニア型異方性フィルタリングに切り換えたりしているのだろう。
NVIDIAとATIはお互いを罵り合いながらも、実は「最適化という名の手抜き」を、大小のレベルの違いはあれど、ともに実践していたのである。
「俺たちってさ、よくケンカしているけど、やっていること似てるよな」と、黄昏の土手で笑い合ったかどうかは不明だが、ユーザーとしての我々は「お前達の言うこと、全部信用するのはもうやめるよ」と結束しあったのだった。
ちなみに、参考までに、同テストを同条件にて、GeForce3 Ti 200、RADEON 8500LE、GeForce FX 5600で実行した結果も以下に示す。
こうして見てみると、GeForce3 Ti 200とGeForce FX 5600の結果は近代GPUに近く、RADEON X800やGeForce 6800ほどのアグレッシブな「最適化？」は適用していなかったことが見て取れる。
性能競争が激化した、この後の世代で「禁断の最適化？」に手を出していった……ということだろうか。
なお、あまりにも明瞭な花形の結果となったRADEON 8500LEでは、異方性フィルタリングがそもそも実践できていないようである。
ちなみに、近代GPUのGeForce RTX 3090とRadeon RX 6900 XTの結果はよく似ているものの、細かくみると結果が完全に一致しているわけでもないことに気がつくだろう。
なので、この不毛な「テクスチャフィルタリング技術最適化の乱」の後の近代においても、両社は「最適化という名の手抜き」を適宜、介入させているということだ。
つまり、GPUが異なれば、同じ設定の異方性フィルタリングを実行して同じシーンを描画しても、結果は異なってくる(かも？)ということなのである。
ちなみに、テクスチャフィルタリングに関して言えば、近代GPUはキャッシュシステムが大容量となっており、しかもキャッシュ制御が超優秀となっているため、異方性フィルタリングをx2設定からx16設定にしてもパフォーマンスの低下が10年以上前のGPUと比べると軽微となっている。今では「攻めた手抜き」は不要となってしまったのだ。
最新世代のGeForceと最新世代のRadeonにおいて、ここで解説したような「最適化という名の手抜き」の介入を、ユーザー側でカスタマイズすることができる。興味がある人はいろいろといじってみよう。
「緑のたぬき」と「赤いきつね」の闘いは続く
こうした激しい「お互いの揚げ足取り」は、このあたりがピークで、その後あまり両社では行なわれなくなった。
新製品を発表した際のプレゼン資料に「赤い棒より高い、緑の棒が列んだグラフ」「緑の棒よりも高い、赤棒が列んだグラフ」を示すくらいのものだ。
直近で思い出されるのは、VESAがAMD FreeSyncを「AdaptiveSync」として採用することを発表した2014年頃、AMDが「AMD FreeSync勝利宣言」的なニュアンスのマウントスピーチを基調講演か何か言及したくらいで、その後のNVIDIAの反撃も、「我々はG-SYNCをブランドとして残していきますんで」と述べたくらい。穏やかなものである。
そうした闘いを経て、AMDもNVIDIAも大人になったということなのだろう。
ただ、一連の闘いで、興味深いディープな技術の存在を知ることができたし、彼らの製品と賢く付き合っていくための心構えのようなものも身に付いたので、「懐かしきよき思い出」となっている気はする。
今後とも、「緑のたぬき」と「赤いきつね」の活躍に期待していきたいと思う。
次回は、先延ばしとしていた「プログラマブルシェーダ技術台頭後の歴史」の話に戻すとしたい。
コメント