はてなブックマーク

前回 Oculus Go で UserLAnd を呼び出せるアプリを作ったのですが、せっかくなので何でも呼び出せるように普通のランチャーアプリも作ってみました。Oculus Go 上で様々な Android アプリが動きます。 任意の Android アプリを apk で直接 Install するだけで↑のようにランチャー画面にアイコンが並びます。 もちろん前回の TVWrapperUL 同様 UserLAnd や VNC Viewer、Android 設定画面も呼び出せます。(前回の記事はこちら「Oculus Go を文章書き＆開発マシンにする」) ↓Firefox ↓AnyDesk で Windows 10 にログインしてさらに VMWare で Ubuntu ↓Kindle も動きましたがテキストタイプの書籍はフォントサイズが大きすぎます。ページを画像データとして持つ雑誌や漫画のよう

Apple の製品紹介には、前モデルからどれだけパフォーマンスが向上したか比較値が載っています。この数値をまとめてみました。 iPad mini/iPad 2 はどちらも Apple A5 (Cortex-A9 1.0GHz dual/PowerVR SGX543MP2) が用いられており同一です。これを 1.0 とした時の速度の比較は下記のとおり。数値が大きい方が高速です。

S-SP = Single Thread 単精度 (GFLOPS) いずれも数値が大きいほうが高速 S-DP = Single Thread 倍精度 (GFLOPS) M-SP = Multi Thread 単精度 (GFLOPS) M-DP = Multi Thread 倍精度 (GFLOPS) 浮動小数点演算のピーク値だけの比較なので実際のアプリケーションの速度とは異なります。ですが、浮動小数点演算の速度だけでも Apple の公称値である「CPU 速度で 6倍」に近い数値を得ることが出来ました。 M-SP: 35.5 (iPod touch 6) / 6.2 (iPod touch 5) = 5.7倍 また 32bit 世代 (A4～A6) と 64bit 世代 (A7/A8) の間に入る調度良い比較対象だったので Mac mini Early 2009 の結果も載せてみました。もち

● JavaScript から C関数を呼び出す ccall() を使います。 (C/C++言語から JavaScript Lib を呼び出す方法は こちら) #include #include extern "C" void myfunc01() { printf( "MYFUNC01\n" ); } int main() { EM_ASM( // C言語関数の呼び出し ccall( 'myfunc01', 'v' ); ); return 0; } C/C++側から参照がない関数はオプティマイザが削除してしまうので そのままだと上のプログラムはエラーになります。 コンパイル時に下記のオプションが必要です。 -s EXPORTED_FUNCTIONS="['_main','_malloc','_myfunc01','_myfunc02'] EXPORTED_FUNCTIONS で個別に関

それまでコンシューマをやっていたチームが、新たに PC系ビデオカードでゲームを 作ろうと評価を始めると、エフェクトなど半透明の描画が遅いので引っかかって しまうことがあるようです。 でもよくよく話を聞いているとポリゴンを重ねすぎているだけのように見えます。 半透明の描画が通常のポリゴン描画よりも遅いのは当たり前です。 唯一当たり前じゃなかった特殊なハードが PS2 です。 PS2 には PixelShader どころかマルチテクスチャ等の pixel 演算系機能が無いので 表現力を上げるにはマルチパスを用いる必要がありました。 なのでエフェクトもひたすらポリゴンを重ねて半透明を大量に使う傾向があります。 PS2 は GPU (GS) にオンチップで VRAM を搭載していて、その転送バスは 2560bit (147MHz で 47GB/sec) もあります。16 pixel/sec と並列

OpenGL 3.2 では core 機能に Geometry Shader が含まれています。 試してみました。 ・OpenGL Registry GeometryShader はポリゴンの面単位で実行可能なシェーダープログラムです。 面単位なので、プリミティブタイプが Triangle List (GL_TRIANGLES) なら一度に 3頂点を入力として受け取ります。主な用途は下記の通りです。 ・頂点演算 ・面単位のマテリアル演算 ・形状の操作 ・出力先の変更 ・StreamOutput (Transform Feedback) わかりやすいところでは面法線の生成など面単位のマテリアル設定が考えられます。 ユニークなのは入力と関係なく出力プリミティブを組み立てられることです。 出力頂点数は任意なので、エッジだけ Line として書き出したり、面を分割したり、 面を消すことも出来ます。

x86 の Atom を搭載した Android Tablet も増えてきました。 本来なら NDK を使用したアプリケーションの互換性が気になるところです。 ところが実際はほとんど問題が起こらず、想像以上にそのまま動作するものが多いようです。 最初から複数のアーキテクチャに対応しているアプリももちろんありますが、 x86 未対応でも動く仕組みが用意されています。 ・Bay Trailが実現する、WindowsとAndroidが共存するタブレット x86 の Android 端末は armeabi-v7a のコードを x86 に変換して実行することができます。 実際に試してみました。 ASUS MeMO Pad 7 ME176 (BayTrail-T Atom Z3745) を使い、 ARMv7A のバイナリ (so) だけ含んだ VFP Benchmark を走らせてみました。 NDK

昨年の AMD Mantle を皮切りに DirectX 12 が発表され、 つい先日 Apple から Metal も登場しました。 DirectX 11 以降停滞かつ安定していた状態から一変、 新しい GPU 向け API への流れが加速しつつあります。 どれも DirectX11, OpenGL とは互換性がない全く新しい API セットです。 これまでと趣が大きく異なっているのは CPU のための刷新だということ。 新しい描画機能への対応はなく GPU へのハードウエア追加も特に求められていません。 目的は CPU 負荷の軽減です。 API Platform Beta SDK GPUs ------------------------------------------------------------- Mantle Windows 2014/5 RADEON GCN Dire

iOS/OSX の API の多くは Objective-C の Interface となっています。 他のプラットフォームとのコード共有を考えるならば、 アプリケーション側はできるだけ普通の C/C++ で書きたいと思うかもしれません。 この場合 System の API 呼び出し部分を分離して、何らかの Wrapper 経由で アクセスすることになります。 Applicaton *.cpp : C++ Library header *.h : C++ / Objective-C++ Library source *.mm : Objective-C++ Wrapper Library のヘッダは C++ と Objective-C++ で共有されることになるので、 Objective-C の Object をそのまま記述することが出来ません。 ヘッダとソースで実装を分離して隠蔽すべきな

Chromecast 上でも Emscripten のプログラムが動きました。 少々ややこしいのですが、PC のブラウザで走らせた結果を、 Tab のミラーリング機能で TV に表示しているわけではないです。 Emscripten で作った JavaScript コードを、Custom Receiver として登録することで Chromecast 上で走らせています。 速度は 10～15fps 前後。 Android 端末よりも遅いので、 Chromecast の CPU はあまり動作クロックが高くないようです。 ● Chromecast とは ほぼストリーム専用に特化したメディアプレイヤーです。 ・Google Chromecast 端末の画面を TV にミラーリング表示するような、リモートモニタアダプタとは異なっています。 インターネットへの接続機能を持っており、基本的には Chrom

● JSライブラリ JavaScript で書かれたライブラリと直接リンクすることができます。 // lib.js mergeInto( LibraryManager.library, { print: function(x){ console.log( x ); } }); // main.cpp extern "C" { void print( int x ); } int main() { print( 12345 ); // これ return 0; } ビルド手順 emcc main.cpp --js-library lib.js -o main.html C言語のリンケージに含まれるので、extern 宣言するだけで呼び出せます。 Emscription の library*.js を見ると、標準で用意された関数も JavaScript で書かれていることがわかります。 利点と

BC6H/BC7/BPTC は GPU が対応しているテクスチャ圧縮の進化系です。 DXT よりも柔軟な bit 配置が可能で圧縮画質が向上しています。(前回) その block 構造を調べてみました。 参考にした資料は下記の 2つです。 ・ARB_texture_compression_bptc ・BC6HBC7EncoderDecoder11 Sample 基本的な考え方は S3TC(DXT) と同じです。 S3TC の場合 4×4 block 単位で基準となる 2つのカラー値を保持します。 この 2色を補間し 3 または 4 階調のカラーをパレットを生成します。 4×4 block の各 pixel は 2bit の index を持っており、生成されたパレットから 1色を選択します。 BPTC/BC6H/BC7 では格納されているカラーが endpoint、補間に用いる 2色のペア

前回 Cortex-A15 の動作だけ極端に低速で少々疑問が残る結果となりました。 RAM 1MB の端末でも動くようになったのでさらに調べてみました。 Tegra4 Cortex-A15 Firefox 60fps 以上 (Tegra Note 7) Tegra3 Cortex-A9 Firefox 20～47fps (Nexus 7 2012) 今回の結果を見る限り、Cortex-A15 でも Krait 並に高速に動作していることがわかります。 また Cortex-A9 も予想よりも速い印象です。 上の両機種とも画面解像度が低く 1280×800 dot です。 前回速度が出なかった Nexus 10 は 2560×1600 と非常に解像度が高いので、 ブラウザが何らかの解像度に応じた CPU 転送を行っている可能性もあります。 なお内部のレンダリング解像度は 960×640 固定で

C++ で開発していた OpenGL/OpenGL ES の Project を Emscripten でビルドしてみました。 Native Code 向けのプログラムがそのままブラウザ内で動いています。 ・Windows Firefox (29.0.1) ・Android Firefox (29.0.1) Chrome では 7 fps 程度なので asm.js (Firefox) の効果は絶大でした。 Android でも十分な速度で動いています。 追記 2014/05/24: その後 Chrome でも 60fps 以上出るようになりました。詳しくはこちら Windows 8.1 Firefox 29 60fps 以上 (Core i7-3615QM) FireOS 3.0 Firefox 29 60fps 以上 (Kindle Fire HDX7 MSM8974) Android

Android NDK r9d では、新しく APP_ABI に armeabi-v7a-hard が追加されました。 とはいえ端末側の ABI の種類が増えたわけではなく、hard-float を指定した バイナリのビルドがより簡単に行えるようになります。 ・Android NDK r9b/r9c では hard-float を使うために jni/Android.mk に直接オプションを 記述していました。 # android-ndk-r9b/r9c # jni/Android.mk ifeq ($(TARGET_ARCH_ABI),armeabi-v7a) LOCAL_CFLAGS+= -mhard-float -D_NDK_MATH_NO_SOFTFP=1 LOCAL_LDLAGS+= -lm_hard -Wl,--no-warn-mismatch endif r9d からは上記のよ

SSE 等の SIMD 命令やキャッシュを意識したプログラムではメモリのアライメントを 考慮する必要があります。 これまではコンパイラ毎の拡張命令に頼っていましたが、 C++11 では言語仕様に含まれるようになりました。 メモリアクセスの同期命令も含めて、低レベルなメモリ命令を積極的に取り込んでいる印象です。 CC alignas alignof ----------------------------------------------------------------- VisualC++ __declspec(align(byte)) __alignof(type) gcc/clang __attribute__((aligned(byte)) __alignof__(type) C++11 alignas(byte) alignof(type) alignas はメモリ配置時のア

Android 4.3 から OpenGL ES 3.0 が使えるようになりました。 対応 GPU も順調に増えていますが、Android 4.3/4.4 が動く端末自体が まだあまり多くありません。 GPU によっては OpenGL ES 3.0 の動作で問題が生じるものもあり、 互換性の意味でも OpenGL ES 2.0/3.0 両対応が望ましいでしょう。 iOS の方は比較的簡単で、今のところ 64bit 対応 (ARMv8 arm64) なら OpenGL ES 3.0 にも対応しています。 Android 端末が OpenGL ES 3.0 に対応してるかどうか調べる方法は ドキュメントに記載されています。 ・OpenGL ES : Checking OpenGL ES Version ただしこの方法は以前も書いたように必ずしもうまく行きません。 1. 及びサンプルコードは O

MacOS X が 10.9 Mavericks から OpenGL 4.1 対応になりました。 特筆すべき点は Intel HD 4000 でも OpenGL 4.1 が使えることです。 Windows のドライバはまだ OpenGL 4.0 のままなので逆転が起こっています。 しかしながら Windows のドライバも、Windows 8.1 向けの 15.33.5.64.3316 (10.18.10.3316) では改善されていることがわかりました。 ● Mac OS X 10.9 下記の通り 4.1 になっています。 // Mac OS X 10.9 Mavericks GL_VERSION: 4.1 INTEL-8.18.26 GL_RENDERER: Intel HD Graphics 4000 OpenGL Engine GL_VENDOR: Intel Inc. GL_SH

昔 Direct3D 10 で作成した迷路シェーダーを Mobile GPU に移植してみました。 if 文の塊で非常に複雑な内容となっています。 そのため GPU によってはいくつか問題がありました。 迷路生成 (Nexus 10) 迷路探索 (Nexus 7) このシェーダーでは各ピクセルが状態を持っており、自分の周囲のピクセルを 参照して次の状態を決定します。 例えば壁、床、成長点、移動判定中など、状態遷移の繰り返しで迷路の生成や 探索を行っています。 周囲のサンプリングは上下左右の 4点 + 自分自身を加えた 5回です。 プログラムでは毎フレーム迷路サイズの矩形を一回だけレンダリングしています。 例えば 512×512 なら、262144個のすべてのピクセルに対して上記の サンプリングと遷移判定を行っていることになります。 そのため原理的にはテクスチャサイズ (迷路サイズ) だけで

Windows を除いてほとんどのプラットフォームには zlib が入っており、 データの圧縮に利用することが出来ます。 ・zlib メモリ上のイメージを圧縮するだけなら下記のとおり。 // [1] // 圧縮データが入るバッファの確保 uLong buffer_size= compressBound( src_size ); Bytef* buffer= memory_alloc( buffer_size ); // 圧縮 compress( buffer, &buffer_size, src_memory, src_size ); // 圧縮後のサイズ compressed_size= buffer_size; 圧縮率を指定するなら compress() の代わりに compress2() を使います。 展開も同様。 // [2] uLong buffer_size= uncompre

下記 CPU ベンチ の結果を更新しました。 この結果だけを見れば iPhone 5 (A6) より約 1.8倍速く、 iPhone 5s は Core2 duo の 1.74GHz 相当となっています。 ・CPU ベンチ 以下抜粋 (詳細は上記ページを参照してください) CPU arch GHz time MB/sec 1GHzあたり -------------------------------------------------------------- Apple A7 CPU ARMv8 (arm64) 1.3 1.04s 104.27MB/s 80.21MB Apple A7 CPU ARMv8 (armv7s) 1.3 1.16s 93.04MB/s 71.57MB Cortex-A15 ARMv7A 1.7 1.49s 72.61MB/s 42.71MB A6 swift

iOS7 では iPad mini/iPad 2 の iPhone アプリの解像度が上がっています。 これまでの iOS6 の対応デバイスと対応する画面解像度は下記の通り。 iOS6 3.5 3.5R 4.0R HD HD-R RAM 480x320 960x640 1136x640 1024x768 2048x1536 ---------------------------------------------------------------- iPhone 3GS 256M ◎ -- -- -- -- iPhone 4 512M -- ◎ -- -- -- iPhone 4S 512M -- ◎ -- -- -- iPhone 5 1G -- -- ◎ -- -- iPod touch 4 256M -- ◎ -- -- -- iPod touch 5 512M -- -- ◎ --

iPhone 5s の浮動小数点演算速度を命令単位で比べてみました。 A7 の CPU core は ARMv8 で 64bit 命令に対応していますが、 ここでの比較は AArch32 (32bit mode) の VFP/NEON 命令となっています。 64bit mode (AArch64) ではレジスタの個数や view が異なるので 違う結果になる可能性があります。 (1) (2) (3) (4) (5) (6) Nexus7 EVO 3D iPhone5 HTL21 Nexus10 iPhone5s Cortex-A9 Scorpion Swift Krait Cortex-A15 ? Tegra3 MSM8660 A6 APQ8064 Exynos5D A7 1.2GHz 1.2GHz 1.3GHz 1.5GHz 1.7GHz 1.3GHz? ----------------

Bitbucket などクラウド系のリポジトリサービスを使うと、 どこでもソースコードをチェックできるので非常に便利です。 電車の中や外出時だろうと、ちょっとした空き時間にブラウザだけで コードを追うことができます。 そのうち欲が出てきて、どうせならこのままコードを手直ししたいとか コンパイルもできたらいいのに、とか思うようになります。 最近のモバイルデバイスは非常に性能が高いので、 クロス開発でなく自分でコンパイルしてもそれなりに速いはずです。 Android 端末なら各種 Linux 環境を install できそうなので試してみました。 Nexus 7 で動く Ubuntu 13.04 ●開発環境として gcc, clang はもちろん、python, git, mercurial などそのまま使えるので ライブラリのコンパイルや arm CPU のテストには十分です。 RAM は

下記の CPU ベンチに Apple A6 の結果を追加しました。 ・CPU benchmark 以下抜粋 SoC/CPU core 実行時間 実行速度 1GHz時 ---------------------------------------------------------------- iPhone 5 A6 ? 1.87 (57.96 MB/s) 44.58? iPad 3 A5X Cortex-A9 1.0GHz 4.60 (23.55 MB/s) 23.55 iPod touch 4 A4 Cortex-A8 800MHz 6.07 (17.85 MB/s) 17.92 実行時間が小さい方が高速。(実行速度が大きい方が速い) こちらでも A6 は非常に良い結果となっています。 リンク先の説明にもある通りテストはデータの暗号化を行なっており、 処理の大半がメモリアクセスやテーブ