2011年8月30日火曜日

横浜Androidプラットフォーム部第12回勉強会 メモ

この投稿へのリンク

@checkela
ゲーム屋的パフォーマンスチューニング(仮) & NDK本サイン会
@tetsu_koba
Google TV add-onのemulatorをいじってみた
@androidsola
OrigenBoardPandaBoardの比較(仮)
@roishi2j2
Android開発者のためのSoC入門(のようなもの)
@hermit4
init以前 – フラッシュメモリとfastbootをさわりだけ」 



ゲーム屋的パフォーマンスチューニング
@chechela
出村

フリーランス
東北
黄色いト○ピーみたいなアイコンの人
黄色いとげとげ→黄色いチューリップ

NDK本の執筆者

普通の奴らの下を行け

1clockの削減に命を削る世界は存在する

1GHz -> 0が9個

その1つがゲーム開発

なぜ1clockにこだわるのか?

1clock削るとゲームの操作性とかに影響
 UI操作が気持ちいい!
 
1万回通るなら1万クロック削減できる
 ある部分の1クロックを削る

3Dグラフィックスが特にそう
 PS3など
  1回の描画で1万頂点演算する
   1頂点の処理時間を短くすれば全体の処理が早くなる

場所を見極めてチューニングする

全体で1番時間がかかるのは描画処理

3Dはそんなに処理は無いからチューニングしやすい、結果が見やすい


どんなパフォーマンスチューニングをする?
 10年くらい前の知識かも

ゲームプログラマを10年ほど
SFC末期〜PS2初期頃まで

ゲーム機の歴史


SFC時代
 H/Wの上でアプリが動いていた
 H/Wがマイナーアップデート入ると後期のソフトほど互換テストするのが大変だった

 ハード特性を極限まで利用する手法
 処理速度はアルゴリズム、DSP(ファミコンソフト側)でカバー
  CPUクロックは早くない
  変態コードは存在する

 H/W特性を利用した例
  ラスタースクロール(DQのワープで波打つエフェクトの事)
   テレビの走査線(H-SYNC 水平同期)の割り込みを利用
  1/60秒で処理する
   すべての画面を書き換える時間(NTSC規格)
   海外のテレビだと仕様が違うから作り直したりする 

PS時代
 H/W上でOSが動いてライブラリがあってアプリが動く
 OS、ライブラリのレイヤーは薄っぺらい
 開発ハードルが下がった

 家庭用ゲーム機に3Dの波が
 RISC CPU(32bit)を搭載
 3D演算に特化したプロセッサを搭載
  DC、PS2、PS3も

 開発スタイルが変化
  CPU、メモリが劇的に変化
  8割〜9割はC言語でつくっていた。一部asm
  昔はROM、RAMを意識してプログラムしていた


 ハードウェアの変化
  CPU性能
   キャッシュ
   パイプライン
  デバイス間のBUS幅
  コンパイラ性能
  3D描画性能
  メモリ管理
  CD-ROMアクセス
   ノウハウが溜まってBGロードができるようになった
   SFCではなかった要素

 組み込み開発で役立つ
  CPU、コンパイラの話

 CPU性能
  ・キャッシュ
  ・パイプライン
  実行効率を決める要素
  
 キャッシュ
  メインメモリから直接データ取得
   メモリから取得している間にidleする
    メモリのアクセス速度はCPUの数十倍遅いから
    CPUの速度向上にくらべメモリの速度向上していない
    刺す枚数を増やしてごまかす
   L1キャッシュからデータ取得
    CPUとL1きゃっすは同クロックで動作するからCPUのidle時間が発生しない
    L1キャッシュは容量が小さい(32K)
    コードをキャッシュに載せられるか、ヒットさせられるかは腕次第
     1ループを小さくして参照するデータ量を減らす
      似たメモリアドレスにあるデータを処理する
    L1キャッシュを意識したプログラムを書く

 パイプライン
  1命令を13のプロセスに分割して処理
  →命令の実行効率を上げる
   ちょっとずつ並行して処理する
  F:フェッチ
  D:デコード    解析
  E:エグゼキュート 実行

 パイプラインの効率化
  パイプラインストール
   パイプライン処理の間延びの事(少し止まる)
    結果の依存性がある箇所で発生
     c=a+b
     e=c+d
    コンパイラ利用すると発生しない
     asmで書くとうっかりやっちまう
     Cで書くとコンパイラがそのへん理解して自動でやってくれる
    CPUの特性把握は必須
    プロファイラを利用するのも手

 動的分岐予想
  true/falseの分岐を予測して先回りしてパイプラインでデコード処理
  ヒット率向上がカギ
  予想を外すと影響がでかい
   13clockのペナルティ
  なるべく外さないコードを書く

 コンパイラ性能
  なぜ重要視するのか?
   そもそものRISCの概念
    1命令を単純化 → 実行を高速化
    コンパイラが頑張って命令配置
     CPU特性を活かすため
    ハード・ソフトからアプローチ
   コンパイラがへぼいとCPUを生かしきれない
   GCCを利用する
    クロスコンパイラ=GCC
   -O3をしても昔は最適化が甘かった
   すべてasmで書くのか?
    →現実的な量では無い
  いかに実行効率がよいコードをはかせるのか?
   人間が頑張るしかない

まとめ
  機械は人間の思いを理解してくれない
  人間が機械の思いを理解するしか無い
  チューニングは細かい作業の積み重ね

おまけ(学習手法)
  97年 → 書籍がほぼすべての情報源
       ハイパフォーマンスコンピューティング(RISC特有のチューニング手法を解説 絶版)
       MMXテクノロジオフィシャルガイド(SIMDを学ぶ)

  今はこの手の情報が減ったからNDK本買ってね。

FAQ
どうやったらコンパイラの気持ちがわかるの?
 コンパイラがだしたコードを読んでみると特徴が分かってくる
  どこで無駄が出てるとか。
 コンパイラに色々な情報を追加して人間の思いをつたえる
 相手をよく知ること!

SIMDの考え方はNEONとかでも変わらない?
 実装されている命令は変わらない
 特徴的なのは、命令に合わせたアルゴリズムを考えないといけない。そうしないとNEONの特徴を生かしきれない。




Tweaking Google TV emulator
@tetsu_koba

Google TVのアドオン
KVMの説明
やってみたこと
 NDKが動かなっかったのはなぜか?

Google TVアドオン
 code.google.com/tv/android/docs/gtv_addon.html
 Android SDK上で動く
 Javaのアプリが動くけどUIを変えてねって趣旨のページ
 
 FAQページ
  Android 3.1
  NDK動かない
  chrome 11(Linux用)
  Flash 10.1
  Native Clientはあとで実装する
  HTML5のVideoタグのH.264サポートを続ける
  
 ターゲットCPU x86 atom
 KVMが必要
  リナックスの技術
  Windowとmacは今はサポートしない
   そんな簡単に移植できないだろ
 Open GLつかって描画
  GPUで動いていない
  画面サイズでかい、3Dガリガリ使うから遅い
   HOST側のGPUにエミュレータの情報を食わせるエミュレータを作ってる

 Kernel Based Viertual Machine
  VMとかViertual Boxみたいなもの
 Intel VTとかADM_V
 ゲストCPUとホストCPUが一緒である必要がある
 KVMはQEMUと一緒に使う
  www.linux-kvm.org/page/Main_Page

 KVMがどんなふうに動くか
  QEMU
   すべての命令をエミュレート
   MMU(仮想メモリのハードウェア支援)もソフトウェアでエミュレートしてるから遅い
  QEMU + KVM
   普通の命令はCPUでそのまま実行
   IO命令、状態を変えるような命令を何らかの仕組みでフックして特別な割り込みをしてKVMの本体が差し替えて動作さるようなイメージ
   95%くらいは普通のCPUで動いている
    だから速度向上が見込める
 
 KVMのセットアップ方法(Ubuntu)
  sudo apt-get install kvm

  Ubuntu 10.04
   sudo chmod a+rw /dev/kvm
  Ubuntu 11.04では必要ない
  gtv_emu**.html

 速度比較
  Ubuntu 10.04 KVM無効 52秒
         KVM有効 32
  Wubi  11.04 KVM無効 52
      11.04 KVM有効 17

  新しいカーネルを使ったほうが速度が上がるのかもしれない


NDK
 NDKr6からはx86をサポートしている
  armとx86を同時につくるとおかしくなる
 AOSPのマスターのソースからx86のエミュレータがビルドできる
 NDK for x86はちゃんと動いている

 Google TVのランタイムはandroidとだいぶ違っている
  Vynamic linkerとかlibcがbionicじゃない
  ソースを見た感じglibcじゃないかな?
  NDKr6はbionic向けだからglibcじゃ動かない

Google TV emulatorをWin7上で動かす
 KVM無効でも動くからwin7でも動くんじゃないか?
 
 eulator executable (QEMU + KVM)
 Linuxカーネル
 target file system
 Skin image files
 AVD file configure
 onley (1) depends on host OS

 起動方法
  Android SDK for windowsにはemulator-86.exeがある
  Linuxで作ったエミュレータをコピーする
  iniファイルにパスが入ってるからwin用にパスを変更する
  eclipseからは起動出来ないから、コマンドラインから起動する
   emulator -avd
  起動するけどむちゃくちゃ遅い

参考資料
 KernelVM探検隊
 てつこばさんのサイト

デモンストレーション
 仮想マシン上ではKVMが動かない
 画面構成はDirectFDからSurfeceフリンガーに変わった

FAQ
 QEMUのイメージをVM用のイメージに変えればいけるんじゃない?
  ぜひやってみてください


OrigenBoardとPandaBoardの比較(仮)
@androidsola

OrigenBoardとPandaBoard
似たようなスペックと価格だったから比較してみた

PandaBoard
 CPU:OMAP4430 Dual Core 1GHz
 メモリ:DDR2 1GB
 GPU:PowerVR SGX540
 無線・BTが付いている

OrigenBoard
 CPU:Exynos4210
 メモリ:DDR3 1GB
 GPU:Mali-400
 CPU基板が取り外しができる
 無線・BTが付いている
 
ベンチマークソフト
 Quadrant Standard
  CPU、メモリ、I/O、2Dグラフィック、3Dグラフィックの総合結果
 0xBenchmark
  村長がよく使ってる
 AnTuTu Benchmark
  Pandaで落ちたから不採用
 Neocore

結果
 PandaはNSに劣る
  解像度のせいかも・・・
 解像度を変えても遅い
  解像度が何故か1680×1080でだしてた・・・
 解像度を1024*600にしてもOrigineBoardの方がいい




Android開発者向けSoC入門(のようなもの)

目標
Xoomはギャラタブ10.1でNEON命令が使えなくなった事情を理解する

NEONとは
 ARMのSIMD拡張命令の1つ
 マルチメディア向けの命令

SoCとは?
 System on Chipの略
  昔はボード上に実装していた回路を1chip化したもの

Tegra2の構成
 CPU
 キャッシュ
 GPU
 バス AMBA
 などなど・・・

Tegra2のコピーを作ってみよう

そもそもどうやってSoCをつくるのか?
大規模ソフトを開発する場合は?
 まったくの新規開発でなければパッケージやライブラリを買ってきて手を加える
 新規開発でもOSを1からつくることはめったにないでしょ?

H/Wも一緒
 CPUはNVIDEAから買う
 DDR2 I/Fはxxx社から買う
 USB I/Fはyyy社から買う
  ・・・

なぜTegra2にNEONを入れなかったのか?
 NEON命令を処理する回路をレイアウト出来なかった。
  その分だけチップサイズをでかくしてもいいけどうまく収まるとは限らない
  矩形のフロアプラン問題はNP困難

SoCの製造って?
 シリコンウェーハから切り出す

課題
 チップをでかくするとどうなるのか?
 有効面積問題
  丸から四角を切り出すから使える面積な問題がある
   4.9mmから5.2mmに変更するとどうなるのか?
 歩留まり問題
  300mmウェハ1枚あたりに数十個の微細なゴミが落ちているとする。
  ゴミを含むチップは不良品
  4.9mmから5.2mmに変更するとどの程度影響するか?

ARMから買ってきたCPU
 TSMC 40Gハードマクロ実装で2GHzの標準動作を実現する卓越したパフォーマンス
 TSMCは世界的に有名な半導体製造メーカー
 40G : 40nmプロセスのハイパフォーマンス版

しかしTegra2はTSMC 40LPで生産
 40LP : 低電圧版

IP(Intellecual Property)
 知的財産権
 日経新聞では「設計済み回路ブロック」
 半導体業界では通信プロトコルは「TCP/IP」と読んで使い分ける
 ハードマクロ
  配置・配線が完了しているモジュール
  物理的な制約(デザインルール)が満たされている
   ゲートの大きさ、素子間の距離、配線間隔
   デザインルールを満たすラインでしか製造出来ない
   Tegra2の場合:TSMC 40LPのハードマクロが必要
 ソフトマクロ
  配置・配線を行う前のモジュール
  素子の間の接続情報だけが記述されている
   ネットリストと言うこともある
   手間暇かければ解析できるかもしれない

ソフトマクロとハードマクロ
 ソフトマクロ(Verilog等)
 ハードマクロ(GDS2等)

買ってきたIPを修正
 ソフトの場合、ソースコードを書き換えることで修正
 ハードマクロの場合は形状固定でブラックボックス
 ソフトマクロは自由にレイアウト、頑張れば解析可能
 IPベンダーはソフトマクロは売りたがらない

IPを組み合わせるには
 全体の仕様を決める
 接続部分のRTLを書く Register Transfer Level
 論理合成する 合成した出力はソフトマクロと等価
 配置配線する
 レイアウト後に検証

ハードの検証
 シミュレーション
  PC上でクロックを与えて回路を実際に動かす
   最新のハイスペックPCでもせいぜい100Hz
   遅いので回路全体を動かすのはまれ
   デバッグ用のコードを任意の場所に挿入できる
    買ってきたIPではできない
    IPにも普通にバグがあるのでIPベンダはソースに検証用のコードを入れておくのが一般的
 エミュレーション
  エミュレータという専用装置を使う
  数十KHzでる
  内部状態の参照に制限がある
 実機

Tegra2にNEONがない理由は?
 *根拠はない
 
 レイアウト上の制約
  そんなにNEONの実装面積でかいのか?
 ARMが「NEON入りのA9ハードマクロ」を高く売っている
  NEON無しIPって価値があるのか?
 実はNEONが載っているけど、マスクされているとか?
  ありそうな話:NEON命令を実行したらバグがでた