Oculus Go 入手しました。名前が Oculus なので Oculus Rift との互換性を期待してしまいますが、実際は GearVR の専用機になります。

↑左が Oculus Go、右が Daydream View (2017)
Oculus Go の方が若干大きめ。左下の黒いのは GearVR コントローラ

Oculus Go には Snapdraogn 821 を搭載した Android デバイスが内蔵されており、Daydream で言えば Pixel 初代機や ZenFone AR と同じです。Galaxy だと S7 世代がほぼ近いスペックです。ただし Oculus Go の RAM は 3GB でした。

性能面では HTC Vive, Oculus Rift といった PC ハイエンド VR とは比較にならないものの、一体型の専用機なのでケーブルやアダプタの接続といった煩わしさが一切ありません。セットアップも専用機らしく簡単になっています。iOS や Android のコンパニオンアプリから行うので、Wi-Fi 設定も使い慣れた操作でできました。

さらに Oculus Go の手軽さを実感できるのはサウンドです。ヘッドホンが無くてもかぶるだけで音が聞こえてきます。

ケーブルレスの Daydream や GearVR でもヘッドホンは必要でした。本来 VR では音の効果は重要なのですが、Vive や Windows MR でもヘッドホンケーブルは絡まりやすく、開発中何度もテストするときはヘッドホンを使わない場合がほとんどです。便利なのでこのスピーカーは他の HMD にも付けて欲しいくらいです。

VR デバイスは機能面で大まかに分類すると 2種類あります。

◎ ハイエンド VR (6DoF + 6DoF)

・PC Desktop GPU
・Position Tracking 対応 HMD
・Position Tracking 対応 MotionController

HTC Vive, Oculus Rift, PSVR, Windwos MR

◎ Mobile VR (3DoF + 3DoF)

・Mobile GPU
・回転のみの HMD
・回転のみの MotionController

GearVR, Daydream (Smartphone), Oculus Go

スマートフォンは普段持ち歩くので HMD に装着したままにはできませんし発熱も結構気になります。Daydrream 対応機種もなかなか増えないので、Mobile VR の場合は手軽に使える Oculus Go のような専用機は良い選択かもしれません。

Snapdraogn 835 以降では Mobile VR でも 6DoF のデバイスがいくつか登場しています。モーションコントローラの制約はまだ残っています。

◎ Mobile VR (6DoF + 3DoF)

HTC Focus (Mobile GPU, 6DoF + 3DoF)
Daydream Mirage Solo (Mobile GPU, 6DoF + 3DoF)

その他の詳細なデバイス一覧はこちらにまとめています。

関連ページ
・HMD VR / AR Device spec 一覧

最近のハイエンドスマートフォンは 6G ～ 8GB もの RAM を搭載しており PC との差がなくなってきました。termux というアプリを使えば Android 上でも開発環境を整えられるとのことなので、コンパイル時間を比べてみました。

・2回連続で計測しており単位は秒です。time1, time2 の値が小さい方が高速です。

big.LITTLE で 8 core の Galaxy S6 Edge が際立つ結果となっています。4 core PC で 30秒ほどなので十分なな速度と言えそうです。

今回のビルドは RAM 容量よりも Thread 数が有利に働いたようです。Galaxy S6 はビルドに 8 core 全部使われており、LITTLE core も使って並列度を増やした方が速いことが分かります。下記は Galaxy S6 と ZenFone AR でスレッド数を変えて試した結果です。bit.LITTLE を意識して制限するよりも全 core 使った方が高速でした。

↓Galaxy S6 Edge (4+4 big.LITTLE 8 core)

以下はスマートフォン以外のデバイス含めてテストした結果です。

・Chromebook は termux ではなく Crouton + Ubuntu を使用しています。

スマートフォンやタブレットは計測時のばらつきが結構あります。2回目以降の方が遅くなるケースも多く、形状が小さいデバイスほど発熱の影響を多く受けているものと思われます。

ARM で一番速かったのは Tegra X1 の SHIELD TV です。こちらは他の ARM デバイスと違い内蔵ファンによる熱対策が行われています。

キーボードがつながらないので実用性はほぼ無いものの Wear OS (Android Wear) の Smartwatch でも動きました。

関連エントリ
・AMD CPU Ryzen とコンパイル時間の比較 (2)
・AMD CPU Ryzen とコンパイル時間の比較
・ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
・2955U vs N3150/J1900/Athlon5350 (コンパイル時間の比較)
・Raspberry Pi 2 で速くなったコンパイル時間の比較
・BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)
・コンパイル時間の比較 BayTrail
・Atom vs Core i7

遅くなりましたが DirectX 12 の対応状況に Vega 56 のデータを追加しました。Vega (GCN 5) は FEATURE_LEVEL 12_1 に対応しており、ROV 等 D3D12 の機能を搭載しています。ただし ShaderModel は 5.1 のままでした。

・Direct3D 12 (DirectX 12) GPU の対応

GeForce, Intel HD Graphcs のテスト結果も更新しています。新しいドライバでは GeForce の Maxwell, Pascal も ResourceBindingTier が Tier 3 に上がっていることがわかりました。また ShaderModel 6.0 (WaveOps == true) にも対応しているようです。

Intel HD Graphcis も Skylake 世代からは ShaderModel 6.1 対応となっています。結果は今後ドライバの更新で変わる可能性があります。

関連ページ
・Direct3D 12 (DirectX 12) GPU の対応

関連エントリ
・Direct3D 12 GPU GeForce GTX 1070 Pascal と RADEON RX 480 Polaris

Android 用ポケコンエミュレータで LC-3 コンパイラが動いたとの連絡を頂いたので紹介させていただきます。

・Pokecom GO

LC-3 について幾つか質問もいただいたのですがだいぶ忘れていました。資料が残っていると思うので発掘できたら紹介させていただきます。

また LC-3 の配布に関しては自由に行っていただいて構いません。ダンプリスト、バイナリ等、任意に掲載していただいて結構です。

SHARP のポケットコンピュータに使われた CPU SC61860 は、小型でポケットに入る電卓サイズの機種に搭載されています。小型＆安価な機種ながら、8bit でマシン語が使えることから人気が出ました。それ以前のポケットコンピュータ PC-1211/10 は 4bit CPU が使われており BASIC しか使えませんでした。また最上位機種 PC-1500/1501 はより強力な CPU を搭載しており性能が高かったものの、サイズも大きく高価でした。

PC-1250/51/45/55 当時のポケコン向け BASIC は非常に低速で、アクションゲームのようなリアルタイムな処理はほぼ不可能でした。数値演算はすべて10進数の BCD で行われており、内部表現は単精度で 8byte も消費します。整数型はありませんし CPU Clock も 576KHz です。

画面に任意の dot pattern を表示することができず、表示できるのは ASCII の A～Z 大文字のみ。しかも BASIC 演算実行中は画面の表示が強制的に off になり、画面に文字列を表示できるのは表示命令で実行が止まっているときだけです。

サウンドも予め内蔵されている BEEP 音を一定期間鳴らすことしかできず、音程等はありませんでした。

しかしながら隠し機能だったマシン語を使うことで、これらのこれらの制限がほぼなくなることが判明します。PC-1250/51 向けのマシン語解析記事が当時の雑誌に掲載され、さまざまなゲームも作られるようになります。

マシン語を活用すると動作も高速でリアルタイムなキー入力も可能。常時画面表示を ON にしたまま任意のドットパターンを表示することができました。サイクル計算次第では任意の音程のサウンド再生も可能です。

ただ上記の通り RAM が圧倒的に足りません。RAM は不揮発性でストレージを兼ねていましたが、外部記憶装置はカセットテープなので外部から容易に読み込むこともできません。

そのため当時のマシン語プログラミングは動作効率よりもいかにサイズを減らすかが重要でした。1byte 減らすためには何でもしました。

例えば相対ジャンプは前後 8bit 範囲 (= 9bit 512byte 範囲) にしか飛べないので、リロケータブル前提で大きなプログラムを作る場合は途中に中継地点が必要です。無駄な命令が増えるので、条件付きジャンプだったとしても同じ番地に戻る命令があればそこを再利用します。もちろん飛ぶ前にフラグが誤動作する組み合わせにならないように、前後の命令を入れ替えるなどして調整します。

A:
           ; 目的位置

B:
  102Dnn   ; DP を破壊しても良い前提で中継地点を埋め込む。2Dnn が A: に飛ぶ命令


  41       ; I--
  29nn     ; JRNZ ; 中継地点の B: +1 に飛ぶ。

A:
           ; 目的位置

C:
  2Bnn     ; JRNC ; たまたま同じ A: に飛ぶ別の命令 (条件付き)


  41       ; I--
  29nn     ; JRNZ ; C: に飛ぶ。41 により C=0 が保証されている

これで中継地点が不要となり 3byte 減ります。CMP/INC/DEC 系はフラグを破壊するので、代わりに BIT TEST や 5A/D2 (SHIFT) を使うのもありです。リロケータブル化が不要な場合でも絶対ジャンプと比べると 1byte 削減になります。

CPU の未定義な挙動も使いました。そのため CPU エミュレータを作るには、ドキュメント化されていない CPU の内部挙動まである程度再現する必要があるかもしれません。

有名なところだと特定の命令で Q レジスタに定数(レジスタ番号)が格納されることでしょう。

1302    Q=02

もし A を破壊しても構わなければ INC A を代わりに使うことができます。これで 1byte 減ります。

42      A++   (副作用で Q=02)

35 命令は PC を使ってメモリ内容を読み出すことができます。PC が破壊されると困るので、内部で一時的にスタックに PC を保存しているようです。そのため 35 命令を使うとスタックに PC の痕跡が残ります。

ただし PC の読み出しなら 35 命令を使わなくても、内RAM 内ROM 内の任意の 37 (RTN) を一度呼び出せば良いので、あまり使わなかったように思います。

SC61860 は RAM にアクセスするには必ず特定のレジスタを経由しなければなりませんでした。DP もしくは PC です。

メモリアクセス可能なレジスタ

内ROM (CPU 内蔵 ROM) はプロテクトがかかっており通常のデータアクセス用 DP では読み出すことができませんでした。ですがプログラムの実行はできるので、PC は当然読み出すことが可能です。35 命令は PC を使うことで、本来読み出せないはずの内 ROM の内容を読み込むことができます。

マシン語モニタを作る場合は DP ではなく常に PC (35命令) を使えばよいかというとそうではなく、今度は VRAM を読むことができません。すべてのメモリにアクセスするには、DP, PC 両方を併用する必要があります。ちなみに PC は VRAM にアクセス出来ないので、VRAM にマシン語コードを書き込んでも実行できませんでした。

byte 削減のために一番活用したのはやはり 内ROM で、少しでも都合が良い命令並びがあれば積極的に 内ROM CALL を多用していました。たった 3byte の命令並びでも、内ROM CALL だと 2byte で済むからです。

関連エントリ
・24年ぶりに「おくやくん」が移植されました。ポケコン PC-1245
・BASICコンパイラと手書き原稿の時代
・28年前のモバイル PC-1211 他
・20年前のモバイル PC-1417G

Windows MR も SteamVR に対応したので、Dell Visor で HTC Vive 向けのソフトをプレイしてみました。思ったよりも遜色なく動くものが多く Fallout 4 VR も遊べます。コントローラにタッチパッドがあるおかげで操作方法も Vive と同じです。

1. Steam で「 SteamVR 」を install
2. Steam で「 Windows Mixed Reality for SteamVR 」を install
3. Windows の Start Menu から「Mixed Reality ポータル」を起動
4. 3. が「準備完了」になってから Steam 上で「 SteamVR 」を起動
　　(Steam 右上タイトルバーにある [VR] ボタンでも OK)
5. SteamVR 用のソフトウエアを起動 (Fallout 4 VR 等)

↓アイコンが Windows MR Device の形に

終了時は「Mixed Reality ポータル」を一番最後に閉じる必要があります。

1. SteamVR 用のソフトウエア終了
2. SteamVR (Steam VR Monitor) を閉じる
3. Steam のウィンドウを閉じる
4.「Mixed Reality ポータル」を閉じる

Windows MR Controller の Home ボタン (Windows Button) だと Windows ポータルに戻ってしまいます。代わりに左スティックの押し込み (L3/ThumbButton) で Steam の Home を呼び出すことができます。ヘッドホンのボリューム調整はここです。また右スティックの押し込みでコントローラの左右入れ替えができました。

Dell Visor で気になった点も幾つか

◎ HTC Vive でプレイしたときよりも若干視野が狭く感じる

HTC Vive のように物理 IPD 調整ができず、マージンも少ないので位置合わせがシビアでした。Dell Visor は上に跳ね上げられるのが特徴ですが、PSVR のように前後位置を調節できるわけではないです。

◎ ヘッドトラッキングの処理落ちあり (首を振ったとき滑らかではない)

処理落ちかインサイドアウトのトラッキングエラーか不明です。Vive と比べると動きによっては酔いやすいかもしれません。特に激しく首を動かす場合など。
使用した PC は Ryzen 7 1800X + GeForce GTX 1070 です。もともと Fallout 4 VR の推奨スペックは 1080/Vega64 以上なので GPU 不足の可能性が高いです。トラッキングの違い＆ディスプレイ解像度が高いことから、Vive 向け推奨スペックよりも高い PC 性能が必要になるかもしれません。

◎ コントローラのタッチパッドが Vive より小さく操作ミスしやすい

これは仕方ないのですが、面積が小さいのでタッチを使ったカーソル移動とアイテム選択がやりづらい場合がありました。

↓コントローラの比較。Windows MR (写真左) は円形タッチパッドの面積が小さい。

↓VR ヘッドセットの比較

上 HTC VIve, Daydream View (2017), 下段 PSVR, Dell Visor

関連エントリ
・Windows Mixed Reality Dell Visor (VR HMD)
・HTC Vive (VR ヘッドマウントディスプレイ) の接続