VR
oga at 23:01
Oculus Quest が PC 接続に対応しました。まだベータですが、Oculus Quest で PC 向けの VR ゲームも遊べるようになります。

Oculus Questスタートガイド。

使い方は上のページから「Oculus Questヘッドセットを設定するにはどうすればよいですか。」→「Oculus LinkでQuestを設定する」の順で開くと出てきます。

Oculus Quest は 6.6DoF、頭と両手合わせて合計自由度 18 に対応しつつ完全ワイヤレス化を実現した VR HMD です。外部のセンサー設置も不要で準備いらず。ルームスケール対応の本格的な VR ゲームができるのに充電して電源を入れるだけ。携帯ゲーム機のような手軽さが魅力の一体型 VR です。

ただし Platform は Android ベースの独自のもので、Quest 対応ソフトしかプレイできませんでした。Oculus Go/GearVR との互換性もなかったのですが、この辺りは徐々に解消されつつあるようです。

さらに Oculus Link 機能によってハイエンド系 VR ゲームもプレイできるようになります。つまり PC とケーブルがあれば Oculus Quest が Oculus Rift/Oculus Rift S の代わりになりるわけです。

まだ専用の Oculus Link ケーブルが発売されていないので、β版を試すには USBケーブルが必要です。

OculsuQuest

↑推奨のケーブル (Anker USB 3.0 3m) を使用しています。

専用ケーブルではないのでコネクタが斜め前方に飛び出して少々じゃまになりがち。ケーブルを引っ張ると簡単に抜けてしまうので写真ではベルトで止めています。

使い方は Oculus Rift と同じです。予め PC 側で Oculus アプリをインストールしておくと、接続時に Quest を認識します。Quest 側にダイアログが出るので許可すれば OK です。

Oculus LInk

Oculus Store で Rift 向けアプリがプレイできますし、そのまま SteamVR を起動すれば Steam の VR ゲームも動きました。

SteamVR

特に遅延なども見られず遜色ない動きです。使用した PC は Ryzen 7 1800X + GeForce RTX 2070 SUPER。モバイルも据え置きもこれ一台。今お勧めできるデバイスを選ぶとしたら Quest 一択になりそうです。


関連エントリ
Oculus Quest 5万円ちょうどで買えるフルスペック VR
Oculus Quest も文章書き&開発マシンにする
Android/Oculus Go/Daydream の画面をミラーリングするツールを作ってみた
Oculus Go で一般 Android アプリを起動できるランチャーを作ってみた
VR で物が大きく見えたり小さく見えたりするわけ
Oculus Go は VR ができる新しい携帯ゲーム機


外出時のちょっとしたメモ取りやドキュメントのまとめ作業で Note PC の代わりに使っています。

UserLAnd + Termux

以前も触れていますが、UserLAnd 経由で Termux を使用しています。UserLAnd だけでなく Termux を併用している理由はいくつかあります。

◎Termux を使う理由

・proot オーバーヘッドが無いのでファイルアクセスが高速
・Mercurial が安定して動く (UserLAnd は HardLink を使うソフトで問題が出やすい)
・Termux 内のファイルを Android 側から直接アクセスできる

◎UserLand を使う理由

・mozc による日本語入力が可能
・Window (Desktop) 環境が使える
・Android 9 以降で Ctrl+SPACE を入力できない問題の回避 (xmodmap)

Termux で ssh サーバーを起動する方法

$ pkg up
$ pkg install openssh
$ passwd
  <ログインパスワードを設定>
$ sshd

UserLAnd から Termux にログインする方法

$ ssh localhost -p 8022
  <ログインパスワードを入力>

UserLAnd に日本語入力環境を構築する方法や Ctrl+SPACE 問題については下記を参照してください。なお Android 10 (Q) も Android 9 (Pie) 同様 Ctrl + SPACE の入力ができませんでした。

HYPERでんち: LserLAnd
UserLAnd : Android 9.0 で Ctrl + SPACE を使えるようにする
Android Termux で日本語入力を行う / UserLAnd との併用


●PC との同期

データの管理に git や mercurial のリポジトリを使用しているので、PC からも直接同期することができます。

Termux で持ち運べるモバイルリポジトリを作る Mercurial/Git

sshd を起動しておけば PC 側から「git ssh://~」や「hg ssh://~」で直接同期できます。

同期のタイミングでは UserLAnd 不要で Termux 上で sshd が動いていれば OK です。ファイルの転送だけなら scp (WinSCP 等) も使えます。


●クラウドへの転送

PC を経由せずに他のスマートフォンやタブレットにファイルを転送する場合は、Android の「ファイル」アプリが使えます。Termux 内のファイルが見えるので、直接 Google Drive や One Drive 等への転送ができます。

File App

「ファイル」アプリを使う場合は特に sshd が動いている必要はありません。


●共有ストレージの扱い

Android 10 から共有ストレージの仕様が変更されています。"/sdcard" (という名の内部共有ストレージ) は以前のような無制限なアクセスができなくなっています。代わりに「ファイル」アプリを使って、それぞれアプリケーション毎の個別領域にアクセスすることができます。

UserLAnd の場合は少々特殊で、ファイル毎のメタ情報があるので proot を通さずにファイル操作を行うと関連付けが壊れる可能性があります。そのため「ファイル」アプリから共有可能な別の領域「/storage/internal」が用意されています。ここは proot の管理対象外です。必要なデータを /storage/~ に転送しておけば「ファイル」アプリから見えますし、逆に Android から UserLAnd への転送にも使えます。

UserLAnd: Importing and exporting files in UserLAnd

termux の場合特に問題がないので、「ファイル」アプリから Home ディレクトリがそのまま見えるようになっています。


●UserLAnd でブラウザ

UserLAnd の Ubuntu 上でも Firefox が動くようになっています。以前は真っ暗な画面のままでした。下記ページの手順に従い firefox-esr を install します。

FAQ: Installing Firefox on Ubuntu


●Termux で Mercurial

若干パッケージに変更があったようで python2-dev が不要となりました。下記の手順で install できます。

$ pkg up
$ pkg install python2 clang
$ pip2 install mercurial

No more -dev packages


●実際に使用して速度面など

コンパイル速度の比較を見てわかるように、ハイエンドスマートフォンは基礎的な性能面で Note PC と殆ど変わらなくなっています。Atom 系や旧型 PC よりパフォーマンスは上です。

ただし UserLAnd 上では性能を体感できなくなっており、快適度では PC に大きく劣ります。

・proot のオーバーヘッドで数倍遅い
・GPU 非対応なので Desktop などの GUI は全体的に描画が遅い

機種ごとの差も結構あります。以前テストしたミドルクラスのスマートフォンで SoC のスペック通りのパフォーマンスが出ないことがありました。Android 上では動作も軽く何の問題もないのですが、CPU のピーク clock が抑えられているのか Termux 上でのコンパイルに予想の数倍時間がかかりました。

また速度面ではありませんが、OS がカスタマイズされており物理キーボードのキーマップが変更できないものもあります。

お勧めはできるだけカスタマイズされていないハイエンド系となります。Snapdragon 835, 845, 855 など。

良い点は荷物が増えないこと。(Bluetooth キーボードやマウスは別として) またスマートフォンなので Sleep や復帰が安定しており信頼できる点が魅力です。


関連ページ
HYPERでんち: LserLAnd
HYPERでんち: Termux

関連エントリ
Oculus Quest も文章書き&開発マシンにする
UserLAnd : Android 9.0 で Ctrl + SPACE を使えるようにする
Android Termux で日本語入力を行う / UserLAnd との併用
Termux で持ち運べるモバイルリポジトリを作る Mercurial/Git


AI
oga at 00:31
メモです。参考にしたページは下記の通り。TensorFlow の C言語用ライブラリを作るために実機上でビルドしています。

TensorFlow: Build from source
Building Tensorflow 1.13 on Jetson Xavier
JK Jung's blog: Building TensorFlow 1.12.2 on Jetson Nano

bazel の install ができれば、あとは PC と同じように source からビルドできます。bazel の build も上記ページのスクリプトをそのまま利用させていただきました。


(1) 予め Jetson Nano に swap を設定しておきます。

Jetson Nano関係のTIPSまとめ
Setting up Jetson Nano: The Basics


(2) bazel を install します。

bazel の version は このページ下の表 に従い TensorFlow に合わせる必要があります。TensorFlow r1.12 の場合は 0.15.2 を使用します。こちら の script をそのまま利用させていただきました。

$ git clone https://github.com/jkjung-avt/jetson_nano.git
$ cd jetson_nano
$ ./install_bazel-0.15.2.sh



(3) TensorFlow の build

TensorFlow のソースを build します。ここ の情報に従い、若干ファイルを修正する必要があるようです。こちら の script を使うとビルド時にパッチを当ててくれます。

今回は C言語用 lib が欲しいので install_tensorflow-1.12.2.sh を下記のように修正します。

・「sudo apt-get」「sudo pip3」「bazel-bin」で始まる行をすべてコメントアウト。
・「bazel build」の実行を下記のように修正

bazel build --config=opt \
            --config=cuda \
            --local_resources=2048.0,1.0,1.0 \
            //tensorflow/tools/pip_package:build_pip_package



bazel build --config=opt \
            --config=cuda \
            --config=monolithic \
            --local_resources=2048.0,1.0,1.0 \
            //tensorflow:libtensorflow.so


あとは script を実行すると $HOME/src/tensorflow-1.12.2 以下でビルドが行われます。

$ ./install_tensorflow-1.12.2.sh

途中でエラーが出ても、$HOME/src/tensorflow-1.12.2/bazel-bin/tensorflow 以下に libtensorflow.so が出来ていれば成功です。lib とヘッダファイルは下記の場所にあるので、必要に応じて別の場所にコピーします。

lib:     $HOME/src/tensorflow-1.12.2/bazel-bin/tensorflow/libtensorflow.so
include: $HOME/src/tensorflow-1.12.2/tensorflow/c


あとは下記のような感じで使えるはずです。

#include <tensorflow/c/c_api.h>


auto* graph= TF_NewGraph();
auto* option= TF_NewSessionOptions();
auto* status= TF_NewStatus();
auto* session= TF_NewSession( graph, option, status );


関連ページ
HYPERでんち: NVIDIA Jetson Nano

関連エントリ
Jetson Nano / Clang の Version とコンパイル速度の比較


Jetson Nano Developer Kit を入手しました。Jetson Nano は Tegra X1 を搭載した SBC です。各種インターフェースを搭載した I/O ボードがセットになっています。そのため見た目は Raspberry Pi のような印象を受けますが、上に載ってる Compute Module のような小さいカードの方が本体です。

NVIDIA Jetson Nano

Nano は Jetson シリーズの中でも低価格で入手しやすくなっています。その代わり搭載されている Tegra X1 のアーキテクチャは少々古い世代のもので、GPU も GeForce でいえば 900 シリーズの Maxwell に相当します。また同じ X1 を使用している Jetson TX1 や SHILED TV (Android TV) よりも Shader Core 数が半減しています。公式ページに書かれている 472 GFLOPS は fp32 ではなく AI 向け fp16 のものです。

Tegra X1 Device CPU clock Shader GPU clock GPU fp32 GPU fp16
TX1/SHIELD TV A57 1.9GHz 256 sp 1000 MHz 512 GFLOPS 1024 GFLOPS
Jetson Nano A57 1.4GHz 128 sp 922 MHz 236 GFLOPS 472 GFLOPS

Tegra X1 には Cortex-A53 含めて CPU が 8 core 搭載されているのですが、過去の Tegra 同様省電力 core が見えない仕様のようです。8 core 同時稼働ができないため、実質 4 core 相当となっています。

Nano にはパフォーマンス重視の big core A57 が載っているので、同じ Quad core でも Little core のみだった Raspberry Pi 2/3 より CPU 性能は高くなります。ただし最近リリースされた Raspberry Pi 4 では big core (Coretex-A72) に置き換わったため、この点での優位性はなくなりました。

Device CPU core clock IA RAM 価格
Raspberry Pi 2(旧) Cortex-A7 Little 0.9 GHz ARMv7A 1GB $35
Raspberry Pi 2(新) Cortex-A53 Little 0.9 GHz ARMv8.0A 1GB $35
Raspberry Pi 3 Cortex-A53 Little 1.2 GHz ARMv8.0A 1GB $35
Raspberry Pi 3+ Cortex-A53 Little 1.4 GHz ARMv8.0A 1GB $35
Raspberry Pi 4 Cortex-A72 big 1.5 GHz ARMv8.0A 1-4GB $35-55
Jetson Nano DevKit Cortex-A57 big 1.4 GHz ARMv8.0A 4GB $99

似たようなボードのスペックをいくつかまとめてみました。より詳しい表は wiki の方に載せています。メモリ速度に結構違いがあります。

NPU/SBC

Device SoC CPU core clock RAM MEM B/W TPU/GPU
Jetson Nano Tegra X1 A57 x 4 1.4GHz 4GB 25.6GB/s 472 GF@fp16
Coral Dev Board NXPi.MX 8M A53 x 4 1.5GHz 1GB 12.8GB/s 4 TOPS@int
Raspberry Pi 4 BCM2711 A73 x 4 1.5GHz 4GB 9.6GB/s
Raspberry Pi 3+ BCM2837B0 A53 x 4 1.4GHz 1GB 3.6GB/s 28.8 GF@fp32
Dragonboard 410c Snapdragon410 A53 x 4 1.2GHz 1GB 4.2GB/s

OS は Ubuntu Desktop が用意されています。ARM で最初から GPU が有効なものはなかなか触れないので貴重です。OpenGL ES だけでなく OpenGL が使えますし、Vulkan、CUDA にも対応してます。

いつものように ARM 環境でコンパイル速度を調べようとしたのですが、clang の Version によって速度に違いがあることに気が付きました。あらためてデータを取り直してみました。clang の Version が上がるほどビルド速度が遅くなっているようです。

Device v3.5 v3.9 v4.0 v5.0 v6.0 v7.0 v8.0
PC Core i7-4790K -- -- -- -- 30 33 31
Pixel 3 SDM845 -- -- -- -- -- -- 35
Mac i7-3615QM -- -- -- -- -- 42 --
PC A10-7870K -- 64 69 70 74 79 69
Mac i5-3210M -- -- -- -- -- 98 --
ZenFone3 ZC553KL -- -- -- -- -- -- 97
Chromebook C101PA -- 96 95 -- -- -- --
Jetson Nano -- 108 113 113 118 125 121
PC Celeron J1900 -- 174 189 192 202 216 207
Chromebook 2955U -- 191 207 216 225 248 231
PC x7-Z8700 -- -- -- -- 274 304 297
Raspberry Pi 3B 148 194 -- -- 331 351 --
Raspberry Pi 2B 314 395 -- -- 752 820 --

・横軸は clang の Version。数値は秒で値が小さい方が高速。

Windows 上の WSL だと素の Linux より遅くなるため上の表からは除いてあります。wiki の方には WSL 含めたデータを載せています。ストレージ速度など、必ずしも条件が一定ではないので予めご了承ください。

Compile Benchmark

コンパイル時間は core 数や Thread 数が多い方が速くなります。Nano は 8 thread のハイエンドスマートフォンには敵いませんが、RAM も多いし big core なので Raspberry Pi 2/3 より数倍速く、Celeron (Atom) 搭載 PC と比べても半分近い時間でコンパイルが完了しています。

TensorFlow も普通に CUDA で動きます。PC と同じコードがそのまま走るので、メモリ容量の制限はあるものの学習も可能です。TensorFlow をソースからビルドしなおすことで、Python だけでなく C言語 API も使うことができました。


関連ページ
Compile Benchmark
Jetson Nano

関連エントリ
Snapdragon 835 と 845 のコンパイル時間の比較&浮動小数点演算能力
Snapdragon 845 の浮動小数点演算速度
ARM CPU 上の開発環境とコンパイル時間の比較 (2) Pixel 3/UserLAnd
ARM CPU 上の開発環境とコンパイル時間の比較
AMD CPU Ryzen とコンパイル時間の比較 (2)
AMD CPU Ryzen とコンパイル時間の比較
ARM CPU の浮動小数点演算能力まとめ


Snapdragon 845 の CPU Kryo 385 は ARMv8.2 対応の Cortex-A75 がベースとなっています。前回新しく追加された半精度浮動小数点演算命令を使用してみましたが、他にもいろいろと生成コードに違いがあることがわかりました。そのひとつが atomic 命令です。実際に生成されたコードを比べてみました。


● Atomic 演算

まずは fetch_add() の場合。下記コードのコンパイル結果です。

std::atomic<int>  val( 0 );
val.fetch_add( 10, std::memory_order::memory_order_seq_cst );

x86/x64 では lock prefix 付きの xadd が使われています。

; x64
    lock xaddl  %esi, 8%(rsp)

ARMv7-A の場合 LL/SC 型なので複数の命令に分解されます。ldrex, strex が LL/SC です。途中で同一メモリにアクセスがあると Atomic 操作は失敗するので、失敗していたら loop からやり直します。またメモリアクセスの順序付けが必要な場合はメモリバリア命令 dmb が挿入されます。

; armv7a
loop:
    ldrex  r0, [r4]
    add    r2, r0, #10
    strex  r2, r0, [r4]
    cmp    r2, #0
    bne    loop
    dmb    ish

ARMv8.0 (AArch64) も同様ですが、命令体型はほぼ別ものです。またメモリバリアが命令に組み込まれているので命令数は減っています。ldaxr は ldxr(LL) + acquire に相当し、同じように stlxr は stxr(SC) + release を意味しています。これだけで memory_order_acq_rel な Atomic 操作になります。

; armv8.0a
loop:
    ldaxr   w9, [x8]
    add     w1, w9, #10
    stlxr   w9, w1, [x8]
    cbnz    w9, loop

ARMv8.1 (AArch64) では命令が拡張されており x64 同様 1命令で済むようになっています。ldaddal の最後の al が acq_rel を意味しており、他に relaxed, acquire, release があるので 4通りです。さらにサイズも 8, 16, 32, 64bit から選べるので ldadd だけでも 16 種類あることになります。

; armv8.1a
    ldaddal w23, w8, [x22]

ARMv8.1 は add 以外の atomic 演算にも対応しています。

例えば x64 の場合 xadd 以外の演算命令がないので fetch_xor( 7 ) は load + xor + CAS に展開されています。

; x64
loop:
    movl  8(%rsp), %ecx
    movl  %ecx, %edx
    xorl  $7, %edx
    movl  %ecx, %eax
    lock  cmpxchgl  %edx, 8(%rsp)
    jne   loop

ARMv8.1 ではこれも 1命令です。他にも and, or 相当の ldclr/ldset があります。

; armv8.1a
    ldeoral w8, w1, [x19]


● compare_exchange (CAS) の weak/strong の違い

ARMv7/ARMv8.0 では compare_exchange_weak() と compare_exchange_strong() で違いがあります。strong は LL/SC の失敗時に再実行しますが weak はそのまま抜けます。SpinLock など CAS の戻り値によって繰り返し呼び出す用途では、判定が二度手間になるため weak で十分なことになります。

; armv8.0a  cas-weak (0 -> 3)
    ldaxr  w2, [x19]
    cbnz   w2, lbb18
    orr    w8, wzr, #0x3
    stlxr  w9, w8, [x19]
    b      lbb19
lbb18:
    clrex
lbb19:

strong では再実行あり。

; armv8.0a  cas-strong (3 -> 0)
loop:
    ldaxr  r2, [x19]
    cmp    w2, #3
    b.ne   lbb24
    stlxr  w8, wzr, [x19]
    cbnz   w8, loop
    orr    w1, wzr, #0x1
    b      lbb25
lbb24:
    clrex
lbb25:

x64 と ARMv8.1A はそれぞれ weak/strong の違いがなく 1命令です。

; x64
    lock  cmpxchgl  %ebx, 8(%rsp)

; armv8.1a
    casal    w2, w3, [x22]

casal は Compare and Swap (CAS) + acq_rel。



● memory_order の違い

load/store それぞれの memory_order 指定による違いは下記の通り。まずは load の場合。

; armv7a

; (relaxed)
    ldr    r0, [r4]

; (acquire/consume/seq_cst)
    ldr    r0, [r4]
    dmb    ish

ARMv8.1 の違いは特になく 8.0 と同じでした。

; armv8.0a/armv8.1a

; (relaxed)
    ldr    w1, [x19]

; (acquire/consume/seq_cst)
    ldar   w1, [x19]

store の場合。

; armv7a

; (relaxed)
    str    r5, [r4]

; (release)
    dmb    ish
    str    r5, [r4]

; (seq_cst)
    dmb    ish
    str    r5, [r4]
    dmb    ish


; armv8.0a/armv8.1a

; (relaxed)
    str    w20, [x19]

; (release/seq_cst)
    stlr   w20, [x19]

x64 では store( seq_cst ) に xchg が使われている以外は全部 mov です。ARM では厳密に Memory Barrier が挿入されています。

Snapdragon 845 向けに ARMv8.2 バイナリを作ると思ったよりも生成コードに違いがあることがわかりました。iOS では従来の arm64 に加えて arm64e が追加されており、ARM v8.x 拡張命令に対応した新しいバイナリを区別しています。Android では特に区別がないですが、fp16 演算を使った最適化を行う場合は ARMv7 + NEON のときと同じように binary を分けてロードする必要があるかもしれません。

実際の出力などより詳しくは下記のページにまとめています。

CPU Atomic / Memory Barrier


関連ページ
CPU Atomic / Memory Barrier

関連エントリ
Snapdragon 845 ARMv8.2A 半精度 fp16 演算命令を使ってみる / Deep Learning 命令
スレッド同期命令の比較 C++11 とコンパイラ


<<前のページ(日付が新しい方向) | 次のページ(日付が古い方向)>>