PAGE.自分のためのメモ、気になったことなどを書いています。Part.2MS-DOS時代の自作ソフトウェアPC-9800シリーズ用30行BIOS&90桁BIOSご利用上の注意とお願いさかきけいについてAMDの提唱するグラフィックスAPI「Mantle」の行く先AMDが新Radeonシリーズとともに発表したグラフィックスAPI「Mantle」ついて、私の予想を書いてみたいと思います。WatchAMDがグラフィックスAPI「Mantle」を発表。4Gamer.net新チップの演算能力が5TFLOPS(テラフロップス)を超えるとアピールしているようですが、正直になところ生の演算性能(理論値)はあまり参考にならないので、そのあたりは興味がなかったりします。AMDの場合、スーパーコンピューターの世界に入り込めていないので、直ちにその方面に応用されるわけではありませんし、現状における主な用途がクライアント向けのOpenCLでも、AMDのAPUとIntelのCPUを比較してあまり効率的とは言えない結果が出ています。ピーク性能はIntelが396.8GFlops,AMDが748.8GFlopsとなります。このように、理論値のスペックではAMDが大幅に高いものになっています。実際のベンチマークの結果はそれぞれ得手不得手が出ていますが、総合的には、SemiAccurateの結果ではFlopsCL-floatではIntelは0.43倍,FlopsCL-Doubleでは0.69倍と劣るものの,Raytraceは1.34倍,Folding@Homeでは2種のアルゴリズムで,1.10倍と0.93倍と全体的にみて互角の性能となっています。いうことになっています。このようにあまり理論値だけであれこれ語っても実際の性能との開きが大きいことがあり、やはり製品が出て、実際のベンチマーク値を見るまで、何とも言えないところだと思います。話を新グラフィックスAPI「Mantle」に戻します。現在Windowsで使われている3DグラフィックスAPIは皆様ご存知のようにDirect3D(DirectX)です。これとは互換性がなく、使用できるのはAMDの特定製品以降、ただし、パフォーマンスは向上するというふれこみで発表されたのが「Mantle」です。Windowsにおけるグラフィックシェア最大手のIntel製品はもちろん、NVIDIAの製品でも使用できないということで、完全に「Mantle」専用にゲームを作るベンダーは少ないのではないかと思います。対応するにしても、「Direct3D」と「Mantle」というように、2つの対応を行わざるを得ないでしょう。Researchより引用これによると、IntelとNVIDIAを合わせたシェアは76.8%であり、やはり「Mantle専用」は厳しいと言わざるを得ないでしょう。自社=AMDの過去~現在のMantle非対応の既存製品と他社の既存製品が実使用状態にあります。Mantleは対象となるGPUの使用率シェアが非常に少ない状態から立ち上げることになります。Interactiveという企業がありました。同社の「Glide」というAPIを使用すると、当時のPCとは思えないほど性能が出せたため、専用タイトル、兼用タイトルを含め、数多くの対応ゲームがリリースされていました。BansheeでGlide対応の「サイキックフォース2012(タイトー)」をプレイしていました。※3どうしても、このGlideを思い出してしまいます。同社は製品が出せなくなって自滅したので、あまり比較すべきところはないのですが、Mantleが初めてのOS提供外3DグラフィックスAPIではない、ということは念頭に置いておくべきかと思います。※4MantleがDirect3Dより高速だとすると、それはDirect3Dよりも層が薄い、すなわち機能あるいは抽象度を削減しているはずです。9倍の描画APIが呼び出せる※5としていることから、既存のDirect3Dにあるパイプライン系APIの呼び出しとは違った構造を持っているのかもしれません。少なくとも、このMantleによって「新機能(=新たな表現ができる機能)を提供」するとせずに「高速化する」と強調していることから、GPUに情報を伝える部分を自社向けに最適化しているという部分がメインなのではないかと推測します。この予想が正しいとすると、例えばDirect3Dの仕様をMicrosoftが更新して高速化対応をすることも理論的には可能なはずです。OpenGL系も9倍も差があるということであれば、(9倍の性能差と引き換えにするものの内容によりますが)見直しをしてくるでしょう。この努力によって、少なくとも「9倍」と主張される差よりは性能差を少なくすることができるでしょう。専用APIと標準APIの差は50%未満くらい※6には詰められるのではないかと、個人的には予想します。従来であればAMDもMicrosoftに働きかけ、自社のGPUにとって都合の良い仕様をDirect3Dに追加するようにしていたはずですが、今回はそうではなく、Mantleという独自仕様を持ち出してきたのが面白いところです。※7重要なのは、このMantleは流行るかどうか、です。これを考えてみましょう。Watchここに「AMD専用」で「Mantle」が追加されるわけですね。個人的な予想としては、AMDの働きかけによってWindows向けに少数のベンダーが対応する少数のゲームを初期段階で投入してくるだろうと思います。EngineやUnityのようなフレームワークやエンジンのベンダーに如何に食い込むかによるでしょう。次世代のゲームコンソールをAMDが一手に握っているからできる、と思うか、それでも難しい、と見るかによって大きく評価が変わるところです。そこで、ゲームコンソールでの状況がどうなりそうかを考えてみます。それをAMDの独自APIに変えたいと思うか、となると、それはないんじゃないか、という気がしてなりません。同様に、ソニーもPlayStation独自のAPIを持っています(しかもAMDがMantleで主張しているのと同様に、OpenGLやDirectXよりも薄く高速であるとしています)。かかわらず自身のプラットフォームのAPIを、パートナーとはいえ他企業であるAMDに任せたいと思うかどうかというのは微妙な気がしてなりません。なると、おそらくMantleは実質的にパソコン上のWindowsがメインに限定されるのではないかと思えるのです。R9世代以降のGPU構造を変えづらくなります。結果として自分自身の手足を縛る可能性があります。Interactiveほどの自縄自縛状態にはならないと思いますが※10、もしもGPU構造を変えるとなると、Mantleの抽象度を上げることになり、結果として速度的メリットが削られていくことになります。AMDがGPUの構造を変える必要があるかどうか、ということになりますが、この先Direct3DやOpenGL、OpenGL|ES、OpenCLなどの仕様が追加・変更され、結果的に構造を変えた方が効率的になる、という可能性がないわけではないでしょう。今後のプロセス技術の進化によって、それまで難しかったことが可能になったりすることもあるでしょう。これらの状況変化が生じた際に標準APIのパフォーマンスを無視して、Mantleと心中する覚悟があれば話は別ですが、さすがにそんなつもりはないでしょう。いったことを考慮すると、いくつかのコアなゲームベンダーのコアなゲーム以外にはあまり採用する理由がないのではないか、と予想します。具体的にはNVIDIAが提供するPhysXに対応したゲームの数と同じくらいまでいければ、大成功だと思います。そこまで行けないと考えています。私には、AMDは自分で立ち上げた独自規格をうまく継続することが苦手な会社だという印象があります。今度の「Mantle」、私の予想が当たるかどうかは別として、どうなるのか楽しみです。※1あるいはIntelの最適化が素晴らしいということなのかもしれません。Ryanさんの記事からです。※3Direct3D版とGlide版をインストール時に選択する方式でした。Interactiveの自滅の原因の1つではないかと考えています。※5あくまでも9倍のAPIを呼び出せるとしているわけであり、9倍速になるわけではありません。GPU描画に必要となるセットアップ時間を最大で9倍速にするということを主張しているものと思われます。どこを計測して9倍としているのか、具体的な情報は現時点ではありませんので、今後の情報を待つ必要があります。※6仮にセットアップが1フレームの10%の時間を使用するとして、その50%とすると全体の5%差ということになります。同じ前提で9倍という数字の場合でも1フレーム全体からみると約8.9%の速度差ということになります。要するに何が9倍なのか、ということがはっきりしないと、実は非常に小さな性能差の可能性もあるのです。※7Microsoftが提案を断った可能性もあります。※8MicrosoftはIntelにAMD64互換を飲ませた時のように、自分の手にカードを持ちたい会社です。それはどこの会社でも同じでしょう。ベンダーロックインされたい動機があるはずもありません。RTの開発とSurfaceの事業ではNVIDIAをパートナーにしてバランスを取っています。このことも考慮に入れる必要があるでしょう。One」の低レベルAPIとMantleが同一なのではないか、という推測もありますが、いかんせん現時点では確定情報がないため、この予測ではそれを加味していません。InteractiveはGlideの成功に縛られすぎて失敗した面があると私は考えています。