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

WebGL Performance Tuning Tips

ハードウェア特性に基づいた
WebGL 高速化手法
WebGL fast method that is based on hardware characteristics

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen
  • Als Erste(r) kommentieren

WebGL Performance Tuning Tips

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

    Als Erste(r) kommentieren

    Loggen Sie sich ein, um Kommentare anzuzeigen.

  • majiro

    Jun. 6, 2015
  • kubosho

    Jun. 6, 2015
  • tokoik

    Jun. 6, 2015
  • hiroyukinakamura78

    Jun. 6, 2015
  • hirumakazuya

    Jun. 6, 2015
  • Teruichi81

    Jun. 6, 2015
  • syuichitsuji

    Jun. 6, 2015
  • MarikoKatsumata

    Jun. 6, 2015
  • toruwatanabe777

    Jun. 6, 2015
  • ykiwng

    Jun. 7, 2015
  • KenichiTakahashi2

    Jun. 7, 2015
  • otachan

    Jun. 13, 2015
  • simpish

    Jun. 23, 2015
  • KeiIketani

    Nov. 14, 2020

ハードウェア特性に基づいた WebGL 高速化手法 WebGL fast method that is based on hardware characteristics

Aufrufe

Aufrufe insgesamt

7.210

Auf Slideshare

0

Aus Einbettungen

0

Anzahl der Einbettungen

623

Befehle

Downloads

64

Geteilt

0

Kommentare

0

Likes

14

×