WebGL Performance Tuning Tips

Transcript

• 1. ハードウェア特性に基づいた WebGL 高速化手法 WebGL fast method that is based on hardware characteristics 2015/6/6 WebGL Meetup Tokyo #2 株式会社エクサ 安藤幸央 @yukio_andoh
• 2. WebGL Cheat Sheet via. https://www.khronos.org/files/webgl/webgl-reference-card-1_0.pdf
• 3. SGI IRIS GL 1984∼, OpenGL 1992∼ VRML 1995∼ Canvas3D 2006∼ WebGL 2011∼
• 4. WebGLは、 ソフトウェア というよりも、 ハードウェアを最大限 コントロールするため のAPI
• 5. ２のべき乗サイズの テクスチャの方が、 親和性が良いのも そのせい
• 6. 速い？ 遅い？ photo (cc) ph-stopphoto (cc) Will Richards
• 7. Google RAIL 100 ms Response Animation Idle Load 16 ms 100 ms 1000 ms
• 8. Google RAIL 100 ms Response Animation Idle Load 60 fps 50∼100 ms 1000 ms fps : frame per second = フレームレート
• 9. via. https://paulbakaus.com/tutorials/performance/the-illusion-of-motion/
• 10. 遅くならない為には ターゲットを絞る パフォーマンス計画 を立てる via. AKQA Winterlands
• 11. 初めは低いスペック の端末に合わせる 高性能端末向けには 徐々にリッチな素材 を追加すれば良い via. AKQA Winterlands
• 12. 何を重視するか、 基本ポリシーを検討  ●美しさ？  ●操作性？  ●オブジェクト数？  ●fps？ Photo (cc) Andrionni Ribo cf. http://akirodic.com/p/jellyfish/
• 13. Pixar の Rendering の歴史 10 hour / frame via. (C) Pixar
• 14. このハードウェアで は、このくらい.... ベンチマークツールで 計ったり、単純サンプ ルで計り比較する （3DMark, GFXBench, UnityBench 等） via. (C) 3DMark
• 15. 透明、霧、照明、影表 現は高い負荷。 通常描画を透明にする よりも、特別に考える 単なるブレンド描画で 十分な場合も... via. http://blog.bonzaisoftware.com/stochastic-order-independent-transparency/#more-348
• 16. 手前から描くとカリ ング（隠れている面 を描かない）が効く ので速い。 ただし、PowerVR 系(iOS) は効かない (Tile Based Deferred Renderer) via. (C) imgtec
• 17. 後から加えるの は容易だが、 後からチューニ ングしたり削除 するのは難しい photo (cc) Chris Martin
• 18. via. http://caniuse.com/
• 19. ブラウザ間の主な差 分はJavaScript部分 Chrome:V8 Safari: Nitro Firefox: asm.js可 IE11: WebGL0.93 (全命令には未対応) https://kripken.github.io/ammo.js/examples/new/ammo.html
• 20. 闇雲にチューニング せずに、どこが遅い のか見極める パレートの80:20 の法則 photo (cc) Will Richards
• 21. JavaScript CSS http(img) Network WebGL
• 22. Page Speed Insights https:// developers.google.com/ speed/pagespeed/ 画像の最適化や、サーバー 側の設定の不備など、まず は JavaScript 周辺の遅い 箇所を発見できる
• 23. WebGL Inspector http://benvanik.github.io/ WebGL-Inspector/ 動作中の命令群のスナップ ショットを取得し、 OpenGLの命令が無駄に重 複している箇所を見つける ことができる。発見したら ループ外へ移動するなど、 命令配置場所を検討できる
• 24. fps表示 chrome://flags fps stats.js を取り込んでおく 方法もあり https:// github.com/mrdoob/ stats.js 機能追加ごとに速度を体感
• 25. via. http://daureg.free.fr/ta_webit/3d_pipeline.jpg あらゆる箇所が遅くなる要因に.... CPUの限界、頂点の限界、ピクセルの限界
• 26. 何かの描画要素を ON/OFF して何が 負荷なのか、何が関 係無いかを見いだす テクスチャ有無、 ポリゴン数半分とか
• 27. 描画画面を 1/2 や 1/4 に小さくして みる。 遅さが変わらないの であれば、CPU/ JavaScript 側の 負荷が多い
• 28. 早すぎる最適化 は諸悪の根源で ある ドナルド・クヌース （アルゴリズムの大家。アートオブコ ンピュータプログラミングの作者） photo (cc) Will Richards トニー・ホーア説もあり
• 29. CPU GPU
• 30. 1+1 1+1 1+1 1+1 1+1 1+1 1+1 1+1 1+1, 1+1, 1+1, 1+1, 1+1, 1+1 CPU GPU
• 31. CPU GPU
• 32. JavaScript WebGL
• 33. CPU GPU Unified Memory の場合を除く
• 34. WebGL は、 ステートマシン 一度設定した状 態は保持される photo (cc) Eric Lubbers
• 35. 何度も同じ設定 をするのは無駄 設定を切り替え るのは高負荷 photo (cc) Eric Lubbers
• 36. これらをふまえて... 高速WebGL 20の法則
• 37. #01 バラバラのポリゴンよ りも、まとめたポリゴ ンで扱う。 drawCallの回数を少な く。THREE.js だと GeometryUtils.merge() ただし、妄信せず、コ ンテンツ表現とのバラ ンスが重要
• 38. #02 頂点データの再利用 drawElements() を使っ た indexed Polygon 指定 でできるだけデータ数 を少なく
• 39. #03 縮退三角形 Degenerate triangle 面積がゼロの三角形を 表現して、離れたポリ ゴン同士を連続したも のとして扱う
• 40. #04 同じことするにも、 複数の方法があり、速 い方法と遅い方法があ る。 バイト配列の指定や RGB順の違いなど gl.bindTexture(gl.TEXTURE_2D, tex1024); gl.texSubImage2D(gl.TEXTURE_2D, 0, 0, 0, gl.RGBA, gl.UNSIGNED_BYTE, img1024);
• 41. #05 必要の無い OpenGL命 令を何度も呼ばない OpenGLはステートマシ ンなので重複呼び出し は高負荷。 パラメータの ON/OFF をチェック。両面描 画？片面？フォグい る？毎回クリア？
• 42. #06 ループの回数の多いと ころ、負荷の多そうな ところに気を配る ループ内をよりシンプ ルに、ループ外で良い ことは、事前計算。 簡単に試すには、空 ループに書き換える等
• 43. #07 CPU、JavaScript で計 算しているが、 GPU側で出来そうなこ とを肩代わりしてもら う。事前計算しておく 特に同時並列で実行可 能な、それほど精度が 必要でないもの
• 44. #08 型付き配列を活用 Float32Array() が 座標値の配列にも色値 もマトリックス表現も 調度いい。適度な精度 trianglePositions = new Float32Array([ // X, Y, Z, -0.5, -0.25, 0.0, 0.5, -0.25, 0.0, 0.0, 0.559016994, 0.0]);
• 45. #09 テクスチャは一番資源 を食う。小さくて荒く ても比較しないと実は あまり気付かない。 よく使うテクスチャは できるだけ始めの段階 でロードしてバインド しておく。あとは切り 替えて使うだけ
• 46. #10 JPEG, PNG自身を圧縮 展開する時間もあるの で、ハードウェアが対 応しているテクスチャ 圧縮フォーマットが一 番いい（要拡張命令） 実はネット上をやり取 りするのが一番遅い （PNG圧縮、8bit index） http://toji.github.io/texture-tester/
• 47. PowerVR PVRTC via. http://wiki.sparrow-framework.org/manual/pvr_textures
• 48. #11 テクスチャのロードと バインドは大きな負荷 テクスチャアトラスで まとめる。 使う時に UV 指定をう まくずらして使う (C) Minecraft
• 49. #12 ミップマップを活用。 テクスチャがバインド されたままで、最適サ イズを切り替えてうの で一番都合がいい。 遠くにあるオブジェク トは描画面積も小さい ので、小さいテクス チャで十分。
• 50. #13 LOD活用 広い空間や、 広い領域を扱う場合 は、Level of Detail がと ても効果あり。 視点から近い時は細か く、遠い時は荒く
• 51. #14 read系の命令を描画 ループ中で使わない。 コンテキストスイッチ ングにとても負荷がか かる。設定値を read() したり、ピクセル値を read() したりがとても 遅い
• 52. #15 スマートフォン向けに は、常に最大性能が良 いわけではない。 バッテリー消費とのバ ランスを考慮する 3G/LTEは最初の立ち上 がりが遅いので、なる べくまとめてやり取り
• 53. #16 エラーチェック用や、 デバッグ用のコードを 綺麗に取り除く。 笑うかもしれないが、 以外と盲点。 最初から仕組みを準備 しておく エラーの発生を直すと 速くなる時もあり
• 54. #17 Retina なら 2倍拡大表 示でも十分？！
• 55. #18 カラースクリプティン グ、ストーリーテリン グも重要 雰囲気や、気分で速度 に関する感覚もだいぶ 変わる
• 56. #19 使えるからといって限 界値まで使わない 出来るだけ少なく http://webglreport.com/
• 57. #20 利用機材を最適な環境 設定にしよう。 特にノートパソコン、 モバイル機器は、バッ テリー温存のために 色々と遅くなる GPUが切り替わる機種
• 58. まとめ ハードウェアの性質や仕組みを理解し、最大限に生かす 適切な量と適切な表現で、無駄なことはしない できるだけまとめて、場合によっては、できるだけ分割して WebGL以外のネットやJavaScriptが遅くはないですか？ 適切なチューニングには、適切プロファイリングが重要 選択と集中。ループの中を速くするのが一番効果あり
• 59. スマートなデータ を使う つまらないコード を書くのだ ロブ・パイク （UNIX、Go言語の作者の一人） photo (cc) Will Richards
• 60. WebGL は インタラクティブ な上に、動画より も小さいよね！ Mr. doob （Three.js の開発者） photo (cc) ricardo cabello
• 61. おまけ 極端なチューニングによりコードを書き換えた時は、元の コードも書き残しておいた方がいい（何をやっているのか デモやギャラリー展示など、単発、単体の時は、苦労して チューニングするよりも、速いマシンを調達した方が早い メーカーが提供しているチップのドキュメントを読むとより 深く理解できます（特に PowerVR や NVIDIA系は充実）
• 62. PDF download http://goo.gl/ Thanks! @yukio_andoh