Microflake SGGX for Mitsuba Renderer

https://github.com/taqu/Microflake-SGGX

今すぐリアルタイムレンダリングに応用できるか?
と問われると思いつかない.
十分小さな誤差で線形補間ができるという性質は,
リアルタイムレンダリングへの応用を期待させる.

Opus再生サンプル

OpusでエンコードされたサウンドのOggファイルを再生するライブラリ, サンプルを作成.
https://github.com/taqu/opus

opus, ogg, opusfile, speexDSPライブラリを使用した.
Windowsでは, WASAPIをバックグランドに,
Androidでは, OpenSL ESをバックグラウンドに使用する.

Unity5のサンプルも作成してみた.
Nexus5では再生遅延の差はほとんどないが,
Xperia Z1 f SO-02Fでは明らかにUnity 3Dの方が遅い.

VorbisとOpusの差なのか, Unity 3Dの処理がよほどXperiaと相性が悪いのか.

OpenSL ES

仕様を読む限り,
SL_IID_ENGINECAPABILITIES
の実装は必須に見えるが手持ちのデバイスではとれない.
とりあえず失敗するまでCreateAudioPlayerをするしかない.

初めは, BufferQueue::GetStateで未処理バッファ数をチェックして,
データを補充する方法をとったが, 十分間に合っていると思われるのに
ノイズが入る.
ポーリングでデータを準備して, BufferQueueのコールバックで
BufferQueue::Enqueueに引き渡せばノイズが入らなくなった.
また何か見落とした文章があるのだろう.

WASAPI

WASAPIは, Core Audio APIsの中の音声再生API.
User-Mode Audio Components
共有モードと排他モードがあるが, ゲーム等, 音声を複数再生する場合,
共有モードを使用する.

基本はサンプルとおり
Rendering a Stream

音声再生のプログラムは,
ドライバなりエンジンからの次データ要求や,
再生バッファの空きの検知をトリガーに,
音声データをドライバ・エンジンに引き渡す処理を繰り返す.

WASAPIの場合, ポーリングで未処理をデータサイズを調べるか, イベントで検知する.
イベントは, WindowsのEventを引き渡し, そのEventがセットされるかチェックする.
イベントを使う方法は, 複数音声の管理には向いていないと思われる.

Core Audio APIsは, エフェクトの機能はなく, 高位のMedia Foundation等が提供する.
サンプル周波数変換には, IAudioClockAdjustmentが共有モードで使用できるが,
品質のほどはわからない.

Speexの, 信号処理部分を纏めたSpeexDSPがある.
resamplerだけ抜き出すのも簡単.

GLSL ES 3.1 メモ

抜けはあるけれど, メモなので.
チェックはglslangValidator で.

Timsort

Timsortを, python 3.4.3のコードを1行1行追いながら移植.
GitHub-Timsort

以下のJava7の実装では例外が発生するケースでテストしてみた.
http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

コードがかなり複雑. gallop_rightのあたりの理解がさっぱり.
ランダムデータではIntrosortの方が,
ソートされた部分が多いほどTimsortの方が速い,
とのことであるが, 実測はどうだろうか.

適材適所ではあるので, ライブラリに
アルゴリズムが複数あって困ることはない.

ついでにGoogle CodeからGitHubへ移行.
Exportボタンを押すだけで終了したので,
何か書くことも無し.

Hopscotch Hashingとその他

Hopscotch Hashingに入れ換える.
簡単なテストでは, Google Dense HashMapより速いよう.

キーからハッシュ等で計算した最初の位置を, ハッシュ値と呼ぶことにする.
その位置に, その位置から後ろの同じハッシュ値のキーが入っている場所を,
ビットマップとして保存する.
4bitのビットマップで, 位置nのビットマップが
bitmap=0101
なら, n, n+2に, ハッシュ値nのキーが入っている.
・検索は, ビットマップのビット数先までしか検索しない.
  ビットマップだけで空かどうかわかる.
・挿入は, 適当にビットマップのビット数 x M倍先までしか空きを検索しない.
  論文ではM=8だそうです.
  空きの位置を, ビットマップの範囲に入るまで移動してくる.
・削除は, 通常のマップの削除処理に追加で,
  ハッシュ値と削除位置の差分からビットマップをクリアするだけ.
  削除フラグは必要なし. 空きフラグは必要.

Cuckoo Hashingというのも.
Open Addressingに対して, ビットマップという余計なデータがある.
メモリ効率は仕方がないが, 追加の操作がビットマップに対する操作なのがポイントなのだろう.
ビットマップサイズ4バイト, M=8の場合で32バイト,
64バイトのキャッシュラインなら平均的に8割ぐらいキャッシュラインに入る.

Google Codeが終了のお知らせ.
引っ越し先はGitHubでいいのだろうけど,
お金払って安心を買いたい.