Ryuzのブログ

私自身別にCGに詳しいわけでもなんでもなく、OpenGLあたりをちょっとかじった程度なのですが、OpenGLにいろいろ課題があるのは非常に感じました。

誤解を恐れずに書くなら、OpenGLの当初の思想は、そもそもCGが専門で無い人(GNUplot使う科学者の層とか？)が、単発描画で3D描画をするのを簡単にするためのものが出発点ではないかと思います(私の勝手な理解)。そこにいろいろ後付けしたのですごいことになっている感があります。

あらゆるリソースがコンテキストに紐付けられており、明示的な管理がありません。

前の描画の時に変更した状態が、裏で残るので、次の描画の挙動に影響します(バグの巣窟です)。

全部コンテキストに紐付くという点でグローバル変数１個となんら変わらないので、プログラムの基本である、分割統治法での設計が困難です（バグの巣窟です）

リソースを保有してハンドルに紐付けて明示的管理するという概念が無いので、マルチインスタンスをやるのが大変です(バグの巣窟です)。

マルチスレッドで性能出そうとかするととっても大変です(バグの巣窟です)。

GPUというフィジカルのレイヤーが見えていないので、コンテキストごとに異なるフィジカルを想定するしかないので、同じリソースをコンテキストを超えて共有できないとか(性能が出ない)もあります。

他にも、少し深いことすると性能を出すのが大変です(バグの巣窟です)。

ライブラリごと（プログラマごと）に想定しているGLのバージョンが違っても動いちゃいます(バグの巣窟です)。シェーダープログラミングのバージョンまで混ぜても動きます(別の意味ですごい)。

アプリ書く人だけではなく、ドライバ作る人も大変なようで、ドライバ間の挙動が違ったり、そもそも品質も揺らぎがあるようです。

なので、C言語で言うなら、main関数１個だけでグローバル変数しか使わないようなプログラムしか書かない人にとってはとっても便利。でも、まじめなCGアプリを書く人には結構大変なイメージです。

私が感じたことの原因を非常に分かりやすく、非常に詳しく書いてあるページを見つけました。

https://cpplover.blogspot.jp/2014/05/opengl.html
https://cpplover.blogspot.jp/2014/05/opengl_19.html
https://cpplover.blogspot.jp/2013/09/dolphinopengl.html

うーん、いろいろよく分かる気が。

特に厄介なのが分業のやりにくさでして、あらゆるものがコンテキストに格納されるので、Aという描画ライブラリのコンテキストの不始末が、ずっと後で呼ばれるBという描画ライブラリでの障害となって現れる点です(そしてそれが「OpenGLの正しい仕様」です)。

ライブラリAとライブラリBをそれぞれ違う人や会社に依頼した場合のデバッグの困難さとか容易に想像できると思います。

Bを作っている人は、「お前のところで不具合が出た」といわれて必死に解析と再テストを繰り返すわけですが、そもそもBさんがアクセス可能なコードの中にバグは無いわけですから収拾がつかなくなるわけです。
（政治的力関係次第では、Aのバグを回避するためにBに対策が入って、新たなバグを呼ぶという悪循環に...）

で、なんでそれでもOpenGLを使うかというと、それしか選択肢が無い(DirectX はWindowsでしか動かない)からです。世間ではAndoroidやiOSなどのモバイルフォン向けの比率が高まっており、非Windows対応がどうしても必要なケースがあるわけです。
  そもそもプロのCGクリエイターさんはWindowsなんか使わずにMacBookなのでまじめにCGやりたけれればDirectXはなくなっちゃうわけです。

　そういった中で、OpenGLの後継のVulkan は非常に期待しているのですが、まだまだ未対応機器が多いのと、AppleがVulkanではなく、Metalを進めるという状況だそうなのでどうしたものやら(MetalVKってのがあるらしいですが)。

ゲーム作るのが目的なら、Unityみたいなこの辺の問題を隠蔽してくれるソフトが使えるのですが、Unityはアプリケーションソフトを書くには不向きなわけです。

となると、アプリケーションソフトの中で、ガリガリCG使うパーツを組み込まないといけない人はどうすりゃいいの？

って話になるわけです。

とはいえいずれ対応機種増えるだろうから、とりあえずVulkan勉強しとこうかな...

まったくもって今更ですが、世の中の流行から無視できなくなってきた深層学習を少し勉強して見ようと環境構築中です。

深層学習のおかげで、GPUはFP16の復活などこちらを意識したアーキテクチャの変化が起こりつつ、FPGAへの適用も各所で見かけるようになって来ました。Caffeなどのツール郡もいろいろと進化を遂げているようです。

実は、年初に体調を崩してしまい、人生初のプチ入院を経験したのですが、そのとき読んでいた本が

  ・深層学習-Deep-Learning-監修-人工知能学会

なのですが、恥ずかしながらさっぱり理解が追いつかず、ちゃんと基礎からやっておきたいなと。

やはり自分でプログラム書きながら理解を進める必要がありそうです。

で、郷に入れば郷に従え、ということで、素直にこの分野で一番使われている Python の勉強から始めてみました。
なるべく中身を解説してくれているサイトを探して、目標はとりあえず下記を理解することに。

http://qiita.com/kiminaka/items/9ae195739093277490fe

で、始めて早速嵌りました、Pythonでの環境作成に(笑)。

Pythonはプログラミング入門にも適しているので、その手の入門書も多いのですが、既にC++とかJavaとかの、オブジェクト指向プログラミングは知っていて、MATLABとかOpenCVとかそれ系のライブラリも使い慣れていて、とりあえず Python + Numpy で似たようなことがしたい、と言うだけだと、割と「環境づくり」が一番の罠だったように思います。

Python一日目でWindows な私としては、 easy_install とか pip とか wheel とか、その辺で「何それ？？？」状態で、どんどん時間を削られていってしまい、「いつになったらプログラミングはじめらるんだぁ～」となってしまうわけです(苦笑)。

  で、結論から言うととりあえず Anaconda 入れとく、というのが素人がとりあえず使うだけなら一番楽そうですね(賛否ありそうな雰囲気ですが)。
  もっとも OpenCV とかもコンパイルできる状態にするまでの罠が多いですので、やっぱり環境つくりは大切ですね。

  Pythonのバージョンは 2系と3系で、少し大きな変化があるようですが、とりあえずは言語的に難しいことはしない予定なのと、print が制御文から関数に変わった程度を知っていれば何とかなりそうなので、あまり気にしないで最新バージョンの3を入れてしまいました。

   Anaconda で 一緒にインストールされる、SpyderなるIDE環境を使うなり、Jupyter notebook なりを使うのが環境的に楽なようです。

  で、次にPython の文法のお勉強。
  こちらのサイトさんが個人的にはコンパクトに良くまとまってました。
  http://tohoho-web.com/python/index.html

  シンプルでよくまとまった言語ですね。他のプログラミング言語に知識があれば、文法自体は短時間で概略つかめますね。

  で、早速、Webのサンプルを打ち込んでみるわけですが、Python界の常識をいろいろ知らないのでまたもや嵌るわけです。

  Webにあるサンプルコードを打ち込んでもエラーしかでない。 Numpy という、いわゆる MATLAB的なライブラリを使う場合

  import numpy as np

  のような定義をしておくのが暗黙の了解のようです（フムフム）。

  他にも

from sklearn import datasets, linear_model

  とかも最初「？？？」 でしたが

   モジュール：ファイル
   パッケージ：ディレクトリ

  な理解と共に、雰囲気が掴めて来ました。

import matplotlib

  すれば、グラフが書けるのか、フムフム。
  でも Jupyter notebook で、グラフが出ない、

  なるほど

%matplotlib inline

  が必要なのか(フムフム)。

なんとなく、こんな感じで格闘中です。


で、まあサンプルどおり動き始めましたが、どう理解したものか。

興味深いのが 隠れ層を１にした場合の下記の結果




よく考えて見ると、

z1 = xW1 + b1

の計算って、n次元空間の平面の式に他ならないわけで(この例の場合は2次元なので直線の式ですが)、平面の法線方向に、活性化関数で尤度の割付をしている以上でも以下でも無いわけですよね(多分)。
隠れ層が１個のみの場合は、一次関数で勾配降下法で解いてるだけなので、最小二乗法的な解に落ち着くのは、まあ当然なわけです。

これを複数組み合わせていく以上でも以下でも無い中で、いろんな認識が出来てしまうというのはなんとも不思議な世界です。

ただ、身も蓋も無いことを言ってしまえば、ニューロン１個は NANDゲートの上位互換なので、「NANDゲートだけでどんな回路も作れる」ってのはまあそのとおりなのですが、問題はどう繋げば、目的の回路になるかだったりするわけです。
  そこのところは従来なら人間こその設計だったところに、自動的な最適化手法が出来上がりつつあるというのはなんとも奥深い世界ですね。

  うーん、ちゃんと理解できる日が来るのだろうか....

前回からの続き。

計算を単精度に変えてみた。
画像の右上に三角形のつなぎ目で計算誤差で塗りつぶされない領域が出来てしまった。

続けて、Q14で固定小数点にして見た場合。

ラスタライズによる塗りつぶし領域は正常になったが、テクスチャ座標でパースペクティブ補正が精度不足で悲惨なことに。
ラスタライズ演算後の座標は、あくまでピクセル数なので固定小数の方がトラブルが無いようだ。

一方で、除算の入る座標系は、単精度のままの方がよさそうだ。
(一応 Q20 ぐらいまで持っていくと正常にはなったが)。

FPGA化する場合、ステップサイズでインクリメントするとレイテンシが長いので、毎回乗算したほうがいいかもしれない。

(2015/07/25 追記)  普通に浮動小数点でステップ増加していくコア書けました。XILINXのIPカタログの浮動小数点コア使う場合は accumulator が使えますが、単純ステップ増加の場合は指数部のケア(仮数部の桁合わせ)が簡略化できるので、回路的には少しお得に出来るのではなかろうかと。

前回の続きです。

ようやく、OpenGL風に視点の指定など出来るようになってきて、パースペクティブコレクションの有無の実験だけ出来ました。

いろいろと感覚は掴めて来ましたが、さてどうしたものか。

ZyboにはDSPが80個ほどあったはずなので、単精度実数ぐらい実装できるかもしれないが、どのあたりを狙うべきか...

高位合成とか使うべきなんだろうなとは思いつつ（汗）

  将来GPUなんぞを実装して見たいと思いつつ、まずはGPUのお勉強がてら、古典的なレンダリングパイプラインを OpenCV上でプログラミング中である。

参考になったサイトなどを、備忘録的に残しておきます。

ラスタライザを作る人の古文書集
uimac実装メモ
https://www.opengl.org/sdk/docs/man2/xhtml/gluPerspective.xml
https://www.opengl.org/sdk/docs/man2/xhtml/gluLookAt.xml

githubにも入れてますが、まだ作り途中なのでそのうちURL張ります。