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 とコンパイラ


AI
oga at 01:12
Snapdragon 845 の Kryo 385 (Cortex-A75) は ARMv8.2 の拡張命令である半精度浮動小数点演算に対応しています。半精度浮動小数点数は HDR テクスチャなど GPU ではおなじみで、符号 1bit 指数部 5bit 仮数部 10bit の合計 16bit で表現されます。

CPU でもこれまで単精度と半精度 (fp32 と fp16) の相互変換が可能でした。X86/X64 では F16C 命令 (vcvtph2ps/vcvtps2ph) がありますし、ARM では以前試したように Cortex-A9 以降で変換命令が追加されています。変換だけなのでメモリアクセスは速くなるものの演算速度は特に変わりません。

ARMv8.2 ではオプションの拡張命令 FPHP, SIMDHP が新設され、対応していれば 16bit 半精度のまま演算ができるようになりました。128bit の SIMD(NEON) なら同時に 8個の積和演算を行うので、ピークの演算速度は単精度の倍になる計算です。

fmla  v0.2d, v1.2d, v2.2d   ; 倍精度 64bit x2
fmla  v0.4s, v1.4s, v2.4s   ; 単精度 32bit x4
fmla  v0.8h, v1.8h, v2.8h   ; 半精度 16bit x8

新しい vfpbench で対応したので実際に計測してみたのがこちらです。8 core で 8 thread 並列時の値です。

half fp16 single fp32 double fp64
Snapdragon 845 ARMv8.2A 277.7 GFLOPS 138.4 GFLOPS 68.7 GFLOPS
Snapdragon 835 ARMv8.0A -- GFLOPS 129.5 GFLOPS 67.3 GFLOPS

・GFLOPS の値が大きい方が高速

予想通りほぼ fp32 の倍の値になっています。なお big/little core を個別計測した結果の合計なので、全 core 同時に走らせた場合はもう少し数値は下がるものと思われます。big, little それぞれの値を表にすると下記の通り。

half fp16 singlel fp32 double fp64
little big little big little big
Snapdragon 845 (1.77GHz + 2.80GHz) 108.9 168.8 54.0 84.4 27.3 41.5
Snapdragon 835 (1.90GHz + 2.45GHz) -- -- 59.3 70.2 29.6 37.7

Cortex-A75 の FP/SIMD pipe は 2本ありますが、命令単位で調べると 64bit (4h) 時は IPC=2、128bit (8h) 時は IPC=1 なのでそれぞれの pipe は 64bit であることがわかります。

Deep Learning 用の命令としては他にも 8bit 積和演算である Dot Product (dotprod) 拡張命令があります。これも ARMv8.2A のオプションで、下記ような整数 Int8 の 4乗算と 4加算を 4並列で行うことができます。AVX512VNNI や GeForce RTX (Turing) などの Int8 命令によく似ています。

udot  v0.4s, v1.16b, v2.16b
sdot  v0.4s, v1.16b, v2.16b

32bit += 8bit * 8bit + 8bit * 8bit + 8bit * 8bit + 8bit * 8bit
32bit += 8bit * 8bit + 8bit * 8bit + 8bit * 8bit + 8bit * 8bit
32bit += 8bit * 8bit + 8bit * 8bit + 8bit * 8bit + 8bit * 8bit
32bit += 8bit * 8bit + 8bit * 8bit + 8bit * 8bit + 8bit * 8bit

fp16 の倍なので計算上は 500 GOPS を超えるのですが、残念ながら Snapdragon 845 の Kryo 385 では対応していませんでした。

詳細なログはこちら
Pixel 3 Snapdragon 845 Kryo 385 2.8GHz x4 + 1.77GHz x4 ARM64 (AArch64) Android 9.0

vfpbench のログ(一部)

ARCH: ARMv8.2A
FPU : ASIMD(AArch64 NEON) FPHP ASIMDHP
Name: Qualcomm Technologies, Inc SDM845

CPU Thread:  8
CPU Core  :  8
CPU Group :  2
  Group 0: Thread= 4  Clock=1.766400 GHz  (mask:f)
  Group 1: Thread= 4  Clock=2.803200 GHz  (mask:f0)
NEON  : yes
FMA   : yes
FPHP  : yes
SIMDHP: yes

Total:
SingleThread HP max:   71.675 GFLOPS
SingleThread SP max:   35.892 GFLOPS
SingleThread DP max:   17.940 GFLOPS
MultiThread  HP max:  277.711 GFLOPS
MultiThread  SP max:  138.445 GFLOPS
MultiThread  DP max:   68.745 GFLOPS

Group 0:  Thread=4  Clock=1.766400 GHz  (mask:f)
  SingleThread HP max:   27.426 GFLOPS
  SingleThread SP max:   13.683 GFLOPS
  SingleThread DP max:    6.851 GFLOPS
  MultiThread  HP max:  108.928 GFLOPS
  MultiThread  SP max:   54.046 GFLOPS
  MultiThread  DP max:   27.273 GFLOPS

Group 1:  Thread=4  Clock=2.803200 GHz  (mask:f0)
  SingleThread HP max:   44.248 GFLOPS
  SingleThread SP max:   22.209 GFLOPS
  SingleThread DP max:   11.090 GFLOPS
  MultiThread  HP max:  168.783 GFLOPS
  MultiThread  SP max:   84.400 GFLOPS
  MultiThread  DP max:   41.472 GFLOPS


関連ページ
VFP Benchmark Log 計測結果まとめ

関連エントリ
Snapdragon 835 と 845 のコンパイル時間の比較&浮動小数点演算能力
Snapdragon 845 の浮動小数点演算速度
ARM CPU の浮動小数点演算能力まとめ
HTC 10 Snapdragon 820 Kyro の浮動小数点演算能力
iPhone SE, Apple A9 の浮動小数点演算速度
ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
iPod touch 6 の浮動小数点演算速度は Core 2 Duo ライン超え
iPad Air 2 (Apple A8X) の浮動小数点演算能力
ARM cpu vfp の種類と fp16 命令を使ってみる


VR
oga at 00:11
Oculus Go が登場してからちょうど一年。新しい VR デバイス Oculus Quest が発売されました。最大の特徴はポジショントラッキングにフル対応したスタンドアロン型になっていることです。

要するに、これまで PS4 かデスクトップ PC でしか遊べなかった両手モーションコントローラやルームスケール対応ゲームが、部屋へのベースステーション設置作業とかケーブルの配線とか一切の準備不要で、完全ワイヤレスで楽しむことができるようになるわけです。

・ケーブルなし
・外部センサーやベースステーションの設置なし
・両手モーションコントローラでポジショントラッキング対応
・ルームスケール対応

例えると最初のマルチタッチ対応スマートフォンが出たようなもの。手軽に VR を楽しむために欲しかったものが一通り実現されたことになるので、後はスマートフォンのように年々プロセッサの性能を上げていけばいいだけです。

もちろんモバイルプラットフォームなので、ハイエンド PC と比べると CPU/GPU 性能には大きな隔たりがあります。特に描画性能は落ちるため、決して従来型のコンソールやデスクトップ向け VR HMD が不要になるわけではありません。またアーキテクチャも違うので、Steam などの既存のゲームがそのまま動くわけでもなく、対応ソフトの登場を待つ必要があります。

対応ソフトはまだまだ少ないですが、VR 機能が統一されたので Quest 向けゲームはだいぶ開発しやすくなります。今まではコントローラやトラッキングの仕様が違いすぎて、PC の本格的な VR ゲームをモバイルやスタンドアロン機へ移植するのが困難でした。

またケーブルやベースステーションがないことで、ルームスケール範囲の自由度はむしろ従来のデスクトップ型 VR よりも高くなります。

なお Oculus Quest と同等のデバイスとしては HTC Vive Focus Plus があります。Quest より値段は高いものの、こちらもスタンドアロンかつ両手のモーションコントローラ込みでポジショントラッキングに対応しています。Daydream も HMD のポジショントラッキングに対応した Mirage Solo が出ていますが、6DoF 対応のモーションコントローラがまだありません。ただし Daydream も 6DoF 対応コントローラの開発は行われているようです。

Google VR: Experimental Daydream 6DoF controllers

今後はモバイル系のスタンドアロン機も 6.6DoF 対応が標準になっていくものと思われます。

Oculus の場合アーキテクチャ面でのプラットフォームは2種類ですが、ソフトウエアの対応は Rift, Quest, Go それぞれ異なっています。Oculus Quest の OS やアーキテクチャはモバイル系に属しますが、トラッキング性能やコントローラは PC 系の Rift (S) と同じです。アーキテクチャ上は Quest でも Go/GearVR ソフトが動きそうですが、今のところは対応していないようです。

Oculus HMD Controller Host OS Arch
Oculus Rift / Rift S 6DoF 6DoF Touch x2 外部 PC Windows x64
Oculus Quest 6DoF 6DoF Tocuh x2 Standalone Android 7.1 arm64
Oculus Go (Gear VR) 3DoF 3DoF x1 Standalone Android 7.1 arm64

ちなみに Daydream と Vive の場合は下記の通り。

Daydream HMD Controller Host OS Arch
Daydream 3DoF 3DoF x1 Smartphone Android 7.1+ arm64
Daydream Standalone 6DoF 3DoF x1 Standalone Android 7.1+ arm64

HTC Vive HMD Controller Host OS Arch
HTC Vive/Pro/Eye 6DoF 6DoF x2 +α 外部 PC Windows 他 x64
HTC Cosmos 6DoF 6DoF x2 外部 PC? Windows 他? x64?
HTC Focus Plus 6DoF 6DoF x2 Standalone Android arm64
HTC Focus 6DoF 3DoF x1 Standalone Android arm64

より詳しいスペックはこちらに載せています。

HMD VR / AR Device spec 一覧


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


VR
oga at 22:52
前回 Daydream 上でのテストに使用した方法です。通常のスマートフォンなら Oculus TV のような仕組みが不要なので、VR 上で動く VNC か SSH client があれば OK です。ブラウザ上で動く noVNC を使ってみました。


●noVNC での接続

事前に Bluetooth キーボードを接続しておくことをおすすめします。まずはスマートフォン単体で。

(1) UserLAnd の Install

(2) UserLAnd を立ち上げ、任意の Linux Distribution を選んで VNC を選択

(3) Termux の Install

(4) Termux に noVNC を入れて起動する

$ pkg install git
$ git clone https://github.com/novnc/noVNC.git
$ ./noVNC/utils/launch.sh --vnc localhost:5951

(5) Android の Chrome ブラウザから "http://localhost:6080/vnc.html" を開く

(6) noVNC の画面になるので "Connect" を押して VNC password を入れると Desktop が表示される。

(7) Menu の設定から Scaling Mode を "Local Scaling" に変更するとデスクトップ全体になります。

noVNC を開いたところ
noVNC

Android の Chrome 内で UserLAnd で Linux (Ubuntu)
UserLAnd で Linux Desktop


●VR 上での接続

Daydream View を使います。

(1) VR 上でライブラリのアプリ一覧から Chrome ブラウザを選びます。

(2) あとは同じように "http://localhost:6080/vnc.html" を開くだけです。

Daydream の Chrome でも UserLAnd で Linux (Ubuntu)
Daydream Chrome で UserLAnd の Linux Desktop


●速度面

前回 も載せましたが、さらに VR なしの noVNC のデータを追加しました。UserLAnd 上から Termux に ssh localhost -p 8022 で繋いでビルドを行っています。


VR あり VR利用 SoC RAM Thread Time
Daydream + Pixel 3 (noVNC) あり Snapdragon 845 4GB 8 72
Oculus Quest あり Snapdragon 835 4GB 8 105 秒
Oculus Go あり Snapdragon 821 3GB 4 275 秒
Daydream + ZenFone AR (noVNC) あり Snapdragon 821 8GB 4 349
VR なし VR利用 SoC RAM Thread Time
Pixel 3 (Termux Console) 無し Snapdragon 845 4GB 8 32
Pixel 3 (noVNC) 無し Snapdragon 845 4GB 8 38
Essential Phone 無し Snapdragon 835 4GB 8 38 秒
ZenFone 3 Max ZC553KL 無し Snapdragon 430 3GB 8 100 秒
ZenFone AR (Termux Console) 無し Snapdragon 821 8GB 4 111
ZenFone AR (noVNC) 無し Snapdragon 821 8GB 4 135
Nexus 5X 無し Snapdragon 808 2GB 6 135 秒

・Time はビルドにかかった時間で単位は秒。Time の値が小さい方が高速。



●画面など

デスクトップウィンドウのような細かい文字だと Pixel 3 の解像度 (2180x1080) ではかなり厳しいことがわかりました。携帯できる大画面モニタとして使えると便利かと思いましたが、全体的にぼやけており逆に画面が狭くなったように感じます。

ZenFone AR は解像度 (2560x1440) が高い反面、ビルドのような高負荷な状態が続くと処理落ちが発生します。リプロジェクションも追従できなくなっており、酔いやすいので注意です。

どちらもレンズの端に歪みが生じていたり、何らかのタイミングで 2D アプリのウィンドウが表示されたりと専用機と比べるとどうしてもあらが目立つ印象です。今回テストした範囲では UserLAnd/termux で VR を使うメリットはありませんでした。Pixel 3 XL や Galaxy S9、Mirage Solo ではまた違った結果になるかもしれません。



関連ページ
Android の上の開発環境
HMD VR / AR Device spec 一覧

関連エントリ
Oculus Quest も文章書き&開発マシンにする
Android UserLAnd の更新と VNC 画面設定
UserLAnd : Android 9.0 で Ctrl + SPACE を使えるようにする
Android Termux で日本語入力を行う / UserLAnd との併用
Android 9.0 と Bluetooth Keyboard による日本語入力
Android/Oculus Go/Daydream の画面をミラーリングするツールを作ってみた
Oculus Go で一般 Android アプリを起動できるランチャーを作ってみた
Oculus Go を文章書き&開発マシンにする
UserLAnd とブラウザ
Android 上の開発環境と UserLAnd
OS の中の Linux (WSL/Chrome OS/Android UserLAnd)
ARM CPU 上の開発環境とコンパイル時間の比較 (2) Pixel 3/UserLAnd
Oculus Go は VR ができる新しい携帯ゲーム機


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