note.x

Stage3D Software Rendering

FlashPlayer11はハードウェアアクセラレーションに対応してない環境でStage3Dを使った.swfを再生すると、SwiftShaderによるソフトウェアレンダリングにフォールバックする。シェーダー含めコードの書き換えが必要ないのでステキな配慮だとは思うんだけど、ぶっちゃけどの程度動くもんなのか見てみたい。とりとめない感じであれこれ迷走してみた。

下記は、描画サイズ640×480でテクスチャ貼った板ポリをランダム配置して回しただけの簡単なデモ。強制Softwareモードで動かしてる。

Stage3D Hardware Acceleration Test(要:FlashPlayer11)

これを自分の環境で試してみると、

WindowsXP SP3 Intel PentiumM 1Ghz:△12000で12〜24fps(CPU使用率:85%〜95%)
OSX10.6.8 Intel Core i5 2.53 GHz:△20000で60fps(CPU使用率:120〜150%)

格差すごい。Core i5のほうはまだ行けそうな感じだけど、PentiumM 1Ghzのほうは△12000でいっぱいいっぱいな感じ。どんな環境でもそれなりに動くものを作るとなると、この差異を吸収できるだけの柔軟さが求められるのか。。
GPUでの描画性能との対比で考えると「Softwareモード遅ぇー!」ってのが率直な印象だし、ブラウザの表示領域目一杯使って、10万オーダーのポリゴン描画とかちょっと現実味がない。

とはいえ悪あがきをしてみよう。
描画面積が小さくなればフィルレートが上がるはずなので解像度を下げてみる。
描画サイズ320×240版

WindowsXP SP3 Intel PentiumM 1Ghz:△12000で28fps〜60fps(CPU使用率:42%〜80%)
OSX10.6.8 Intel Core i5 2.53 GHz:△20000で60fps(CPU使用率:40〜50%)

これならPentiumM 1Ghzでも△12000描画で概ね30fps以上をキープできた。安直だけど効果はデカイ。

テクスチャ以外に
単色カラー塗り
頂点カラー塗り
テクスチャ(ミップマップあり)
加算ブレンド
とかで違いが出るか試してみたけど、それぞれ単独で使っても極端にパフォーマンスが変化することは無かった。

これをどう捉えるか?
320×240で△12000描画して30fpsって、初代プレステ並の描画性能なわけで、FlashPlayer上でのソフトウェアレンダリングにしては結構ヤルんじゃないのかコイツは…と、超前向きな解釈もできる。確かに、自前ラスタライザの場合640×480で△4000〜△4500をPentiumM 1Ghzで描画した場合15fpsにも届かなかったので、これはこれでスゴい。

シーン全体のポリゴン数が△10000程度でポストエフェクトも使わないようなコンテンツなら、描画サイズを調整するだけでも、ある程度古い環境までカバーできそう。逆に、描画サイズを大きく取りたかったり、数十万ポリゴン描画するのが前提な場合、勝手にフォールバックされるのはむしろ危険だと思うので、警告出して再生そのものができないようにする配慮が必要かと。

描画サイズ小さくすることでパフォーマンスは向上したものの、いまどき320×240はいくらなんでも小さい。低解像度でいいから表示面積を大きく拡大したいなーと思ったら、これがどうもステージサイズに連動して拡大されたりしないっぽい。
Betaリリースの段階だとStageScaleMode.NO_SCALE指定してなかったりすると、Stageサイズに合わせて拡大表示されてた記憶があったんだけども…、現状はconfigureBackBufferで定義されたサイズで固定になってしまう。フルスクリーン表示も試してみたけど小さな描画領域が表示されるのだった。

ダメモトで、Context3D.setRenderToTexture()使ってテクスチャレンダリングして、それを貼った板ポリ描画。
描画サイズ640×480、256×256のテクスチャに描画

WindowsXP SP3 Intel PentiumM 1Ghz:△3000で17fps(CPU使用率:87%〜96%)

普通に描画バッファに描くより猛烈に遅い。。結局、バッファ自体は640×480で確保してることに変わりないから、テクスチャレンダリングしてる分余計に負荷がかかるだけってことだろうか?Softwareでマルチパスは諦めたほうがよさそう。

ならば、Context3D.drawToBitmapData() 使ったらどうか。
バックバッファ320×240、同サイズのBitmapDataに描画、640×480に引き延ばして表示
若干パフォーマンスは落ちるけど、描画バッファに描くだけの場合と同じような速度出た。このサイズなら使える手段かもしれない…けど、負荷無く拡大表示できる方法ないもんかなぁ。

と、あれこれ試してみて、オレ的にはこれが活きる環境って限られるんじゃないの?という印象。強制的にSoftwareになっちゃうLinux環境とか、Win/Macで、そこそこのCPU積んでるけどGPUモードには対応してないマシンとか? 数年経ってSandy Bridgeがあたりまえ、みたいな状況になれば大概GPUで動くようになりそうだし、今後のアップデートで対応範囲が広がるかもしれない。個人的な方針として、当面はSoftwareモードへのフォールバックはあんまり気にしすぎないようにして、GPUでの動作に重点を置くことにする。

作るものの方向性次第で、PV3D, Away3D3.6とかのベクターベースなライブリを採用した方が良いケースもまだまだありそうだ。


Trackback URL : http://blog.r3c7.net/as3-stage3d/608/trackback/

Leave a Reply