DevTexThumb 0.9.1 に更新しました


テクスチャ画像ファイルのサムネイル拡張の DevTexThumb を更新しました。
今回 0.9.1 では、TGA や DDS で一部読み込めないファイルが存在していた点への対応です。

DevTexThumb のページはこちら。

TGA ではインデックスカラー(パレット)のタイプへの対応と、16bit 形式でアルファチャンネルがついたものの処理を見直しました。


EGL_MESA_platform_gbm 拡張


今更かもしれませんが、 EGL_MESA_platform_gbm という拡張が出現しているようでした。
さらりと中身を見てみると、 Xorg 関連の初期化不要で、 EGL と GBM の初期化だけで OpenGL ES が使えるようになるものと思われます。

手元の環境では VMware Player 6 のドライバおよび Fedora23 では、この拡張が出現しませんでしたが、 Mesa の今後の Version アップにより使えるようになるといいなと思いつつ待つことにします。


X-Window なしで OpenGL ES2 を使う その2


前回 実装はしたので、これらがちゃんと各環境で動くのかを確認してみたいと思います。

VMPlayer 6

VMPlayer6上での Fedora23 での結果は以下の通りです。
OpenGL ES 3.0 のコンテキストが生成されています。ベンダ名やレンダラ名から一応完全ソフトウェアエミュレーションで動いているというわけではなさそうです。
動作速度的にもドライバがちゃんと機能していそうです。

Radeon

Debian8 で RADEON HD 7750 が刺さっている環境での結果は以下の通りです。
OpenGL ES 3.0 のコンテキストが生成されており、オープンソースドライバで動いているようです。

ここでは省略ですが、DisplayPort, HDMI, DVI の端子を保持するボードのため、
これらの情報も Connector として検知できているようでした。

Intel

Debian8 で オンボードの Intel チップ(G41)でも同じように試してみました。
古いチップではありますが OpenGL ES 2.0 で描画可能でした。

こちらは VGA 出力でしたがコネクタタイプも正しく検知できてました.

NVIDIA

Debian8 で NVIDIA Geforce 750Ti で試してみました。

見ての通りオープンソースドライバで動いているようです。
こちらについても接続端子の情報はうまく取得できていました。

まとめ

簡単ですが各環境での動作確認を行いました。試してみた範囲ではうまく動作できているようです。
Linux におけるメーカー公式ドライバではちょっとインストールに手間取り十分な確認ができていませんのでご注意ください
(おそらく NVIDIA 公式 Linux ドライバでは動作しないと思われます・・・)


Vulkan の情報


2015年に Vulkan がAPI公開、ベータドライバ公開という大きな変更がくるかなと思っていましたが、それは起こらず静かに終わりました。
しかし、最近になって Vulkan の情報が徐々に増えてきているのを感じています。

その中でも、 NVIDIA のドキュメントがすごく理解しやすい感じにまとめられていたので紹介します。

https://developer.nvidia.com/engaging-voyage-vulkan

DirectX12 を既に理解して触られている方は、 Vulkan ではこうなっているんだね、という程度で難しいところはないと思います。
ただ逆に DirectX12 を触ってみたけど、何やっているかよくわからない、という人にとってはこの情報はその理解を助けるものになるんじゃないかとも感じました。少なくとも自分は、 Allocation Management の図が非常に良い図に仕上がっていると思います。


X-Window なしで OpenGL ES2 を使う


今まで Linux で OpenGL を使うといえば、 X Window (X11, Xorg) が必須と考えていました。組み込みな何かならフレームバッファ直指定で OpenGL が使えると思いますが、デスクトップ環境においては使えないと思っていました。
 しかし、割と最近になって Linux 側のほうで KMS (KernelModeSetting), DRM が進化して、X Windowなしでも OpenGL(ES2) を初期化して使用することが可能になっていたようです。 kernel 3.x 以降で /dev/dri/card0 などが存在している環境で使えるようです。
もちろん従来の方法で、EGL+GLES2 を X11 上で使うことも可能です。(このEGL,GLES2 を X11 で動かした日記はこちらに)

必要なもの

Fedora や Ubuntu なら以下のパッケージらが必要です。

X-Window が起動している必要はありませんでしたが、ライブラリは必要なようです。詳しく確認出来ていませんが、EGL,GLESv2 らが要求してしまうのかもしれません。

結果

X-Window なしで動いているのですが、スクリーンショットではわからないですね。VMware の中で動作させています。
kms-gles2-cube

実装方法など

X関連のコードは不要になのですが、代わりに色々と必要になるものがあります。ひとつは DRM (Direct Rendering Manager), もうひとつが GBM (Graphics Buffer Manager) です。これらの初期化が必要になります。

今回試しに Gist によるコード貼り付けで以下を説明していきます。 続きを読む


Linux でも使える Git の GUIクライアント


git 操作はコンソールで行うのが一番確実で柔軟に対応できるのですが、GUIがあっても損ではないので調べてみました。ただ実用的に使えるかどうかまでは調べていませんのでご注意ください。

Gitk
本家定番のツール。これで出来ないこともないけれど他のツールのほうが優れているならそちらを使用したい。

GitForce
WindowsとLinuxに対してツールを提供している。
ぱっと見たところログのグラフが無いようなのでつらいかも。

QGit
2007年で開発停止。スクリーンショットを見る限りでは普通。

git-cola
Windows, Mac, Linux(archlinux,debian,fedora,gentoo,ubuntu,opensuse) と対応範囲が広い。Pythonで実装されている模様。
スクリーンショットを見る限りこれは検討するに値しそう。

tig
text mode interface for git ということらしい。GUIではないけれど、git のコマンドラインラッパーということで。
単純なコマンドたたきはつらいが、これなら使える気にさせてくれるかも。

Giggle
開発が停止している模様.こちらもログの描画はそれなりに出来る模様。

git-cola を試してみる

インストール

Fedora23 で試したときには以下のコマンドを実行しました。

起動

git-cola とタイプすれば起動します。即座にはコードのコミットを行うモードとなっているようです。

コミット要約のテキストボックスと、コミット詳細のそれぞれのメッセージを入力する部分が独立しているので、コミットメッセージの書き方をある程度整えることが出来そうです。
またこの画面でメニューから項目を選ぶことでリポジトリ操作が可能なようになっていました。

git-cola-1

グラフィカルな履歴を見る場合には、メニューから “View/DAG” と選択します。
コマンドラインで直接 git-dag とタイプしても起動できるようです。

git-cola-2
複数のブランチを集約してグラフ化する方法はちょっと見つけられませんでした。
コミットログの確認の部分がやりにくいため、自分のスタイルには合わなさそうでした。ただログを確認せずガンガン進むような人は扱いやすいのかもしれません。

tig を試してみる

tig: text mode interface for git を試してみます。
最初の感想としてはこれは常用アリかなと思っています。CUIだけどマウス操作もちょっとできたりして驚きです。

インストール

Fedora23 で試したときには以下のコマンドを実行しました。

起動

実行するには tig とタイプします。デフォルトではカレントブランチの情報しか出ないため、すべてを表示するには “–all” オプションを使用します。

起動すると以下のようになります。コミットログを確認するモードで立ち上がりました。

git-tig-1

ブランチへの派生グラフがスラッシュ、バックスラッシュを使わない描画のためか、自分には割とこれが見やすかったりします。

git らしくコミットのフェーズがステージング、コミットと分かれた方法になっています。
ステータスビュー(“S”)に切り替えた後、コミット対象を”u” で選んで、”C”(Shift+s) でコミットメッセージ入力となります。

これらのヘルプを確認するには、”h” となっています。

git-tig-2
いくつか機能としては足りていない部分があり、たとえばブランチの切り替えはこのツールでは見当たらない感じだったので、git コマンドを操作することになりそうです。
ただ設定ファイル(.tigrc) で拡張コマンドを定義できたりデフォルトの設定を変えたりと柔軟なことが出来そうだったので、カスタマイズをちゃんと行えば出来る範囲は広がっていくものと思われます。

その他

カーソルキーではビューの移動になってしまい、スクロール関連に戸惑いました。
アクティブのビューでのページスクロールは PageUp/Down で、1行単位での行スクロールは、”j”, “k” となっています。
git add -p のように部分的な変更をステージングへ登録する際にはこれも使用することになります。行を選択して “u” で、その部分をステージング登録できます。
これは git add -p を直接実行するよりは使い勝手がよいと感じています。

git-tig-3

まとめ

とりあえず gitk を卒業して tig で Linux での git 生活を始めてみようと思います。


DRM/KMS についてメモ


以下のメモは概要把握としては間違っていないようには心がけたつもりですが、
間違っている可能性が大いにありますので、鵜呑みにしないようご注意ください。

DRI, DRM, KMS の目的

昔は Xサーバーが描画を一手に引き受けていたため、描画に関するコードが X依存になってしまっていた。OpenGL など最近のグラフィックスを描画使用したいケースで問題になってしまう。また Xorg の設計が古くて現状耐えられない状況にきていたりもするようで。

LibDRM

DRMカーネルモジュールはユーザー空間に危険な(不安定な)APIを公開しているので、
アプリが直接この DRMのモジュールを使うべきではない。その代わりに libDRM が提供されているので、アプリはこちらを使用する。この libDRM は Xからも使用される。

DRM (DRMcore)

カーネルモジュールです。これはすべてのカードに適用されるモジュールです。
このモジュールがロードされるとカード固有の DRM ヘルパモジュールが動きだして、
機能ポインタのセットを含めた状態でシステムに登録される。
これにより /dev/dri/card0 などのデバイスファイルが作成・登録される

KMS (Kernel Mode Setting)

ユーザースペースではなくカーネル空間側でディスプレイの解像度・色深度を設定するモジュールです。他の利点としてシステムは素早くグラフィックスの機能を使用可能になったり、ちらつきの問題改善などがあるらしい。

DRM/KMS

これらをまとめて DRM/KMS という表記をしている模様。つまり KMS をサポートしたドライバがあるなら libDRM を直接叩いて描画コードを作れば、X11(Xorg) なしでも画面描画が可能になりそうな感じです。Xサーバーの実装さえ、この libDRM 経由っぽいですし。

これらの関係らをブロック的に表すとこういうことだろうかと思います。
libdrmkms


クロスコンパイラの作成 (ARM/Barematal)


毎回同じような時期にクロスコンパイラの作成をやっている気がします。
今回は対象を Raspberry PI 2 で、ベアメタル用のクロスコンパイラの作成をテーマにやっています。

使用した環境やツールは以下のようになっています。

  • Ubuntu 15.10 (AMD64)
  • gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

使用したソース類

  • gcc 5.3.0
  • binutils 2.25.1
  • newlib-2.1.0

ディレクトリ構成例

意外とここが大事なので注意してください。自分のやってみた範囲ではコードと中間成果物の位置関係が大事な部分があるようです。ここを対応していないような構成を取ってしまうと、途中でエラーが発生して進めなくなってしまいました。

make作業

binutils, gcc, newlib らを先に説明したような場所に展開します。

基本的には別ディレクトリで作業するため build-* なディレクトリを作成します。

前提条件

先に説明したように、ベアメタルな環境を想定しているため、
この先の手順で作成したコンパイラを用いて linux で動く何かを作ることはできません。
また Raspberry Pi 2を対象として決めているので、 hard float ABI を使用し、arm-mode の命令を使ってほしいという想定で設定を行っています。

binutils 2.25.1

ここでは以下の設定で make, install を行いました.

disable-werror を付けないと、binutils の make に失敗してしまうので、付加してあります。以前はそのようなことがなかったため、ホスト gcc のバージョンが上がっていることによる挙動差かなと思っています。
さて、この binutils らをこの先使用するためにパスを通しておきます。

gcc 5.3.0 1回目

定番の話にはなるのですが、1回目のgcc では C言語のみの設定で gcc のみを生成させます。

newlib 2.1.0

ターゲットのシステムには OS がないため linux の共有オブジェクト群はありません。
システムコール類に当たる部分も自作する環境を考えているので
newlib のシステムコールを外した状態で出来上がるようにしています。
そのオプションが、”disable-newlib-supplied-syscalls” です。

make install の部分で失敗することがあれば、ディレクトリ構成を見直した方がよい感じでした。
試してみた範囲では構成を直しただけで成功するようになりました。

gcc 5.3.0 2回目

libcらが newlib によってできたため、残りの gcc の作業を行います。
先ほどのディレクトリに戻って、 make all で残っていた make作業を再開します。

まとめとこれから

これで C言語が使える gcc が出来上がりました。
C++も使えるようにするのであれば、C++ も有効にしてgccのmake 3回目を行えばよいようです。変更する部分は、 –enable-languages=c,c++ となります。

このようにしてできた gcc で -v で確認してみると以下のようになりました。

コツがわかればクロスコンパイラの作成は難しい点はなさそうです(たぶん


Proxmox で NFS 共有されているストレージを使う


Proxmox でネットワーク共有されているストレージを使うとライブマイグレーションが可能になります。今回はその準備として、 NFS 共有のストレージを Proxmox に登録させてみるところを説明します

NFSサーバーの登録

Proxmoxの管理画面(ブラウザ)で、 ServerView の Datacenter をクリックします。
するとタブに “Storage” とあるのでこちらを開きます。そして、Add ボタンがあるのでこちらを押すと、種類が出てくるので NFS を選択します。
proxmox-nfs-1
すると以下のような画面が出てくるので各項目を設定します。
proxmox-nfs-2

  • ID: 任意のIDを設定
  • Server: NFS共有しているサーバーのIPアドレス
  • Export: サーバーがexportしているリストが出てくるはずなのでその中から選択
  • Content: 仮想マシンのHDD を格納するなら Disk Image

登録が終わると、仮想マシン作成時のHDD設定の際、以下のようにストレージをどこにするかを選択することができるようになります。
proxmox-nfs-3


Proxmox でクラスタ環境作ってみた&マイグレーション確認


クラスタという表現が曖昧なのでここでは以下のことを指すものとして使います。
各Proxmoxが動いているコンピューターをノードと呼びます。
そのノードは1つのグループに属します。
このグループのことをクラスタと呼びます。

Proxmox でこのクラスタを作ると、クラスタ内のどの環境に WebUI でログインしても属しているノードの情報を確認することができるようになります。
今回は2台の構成でやってみました。このときどちらの WebUI にログインしても以下のように相手方の情報も見ることができます。
proxmox-cluster-1

設定方法

設定の方法ですが、 WebUI から行う方法がわからなかったため、コンソールで作業しました。
またここでは PVE1 をマスター、それ以外をスレーブと考えることにします。

まずは PVE1 側に ssh でログインします。
そして以下のコマンドを実行します。

# pvecm create example-cluster
orosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

初回の状態を確認してみます。

# pvecm nodes

Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve (local)

ノードが追加されました(自分のことですが)

続いて PVE2 側に ssh でログインします。
そして以下のコマンドを実行します。ここで指定するIPはマスターのIPを指定してください。
これでメンバーとして PVE2 が登録されます。

# pvecm add 192.168.0.160
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'pve2' to cluster.

PVE2 側の ssh での作業はこれで終わりなので閉じてもかまいません。

再び PVE1 側にて確認してみます。

# pvecm status
Quorum information
------------------
Date:             **************** 2015
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          8
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.0.160 (local)
0x00000002          1 192.168.0.162
root@pve:~# pvecm status
Quorum information
------------------
Date:             ****************  2015
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          8
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.168.0.160 (local)
0x00000002          1 192.168.0.162

このようにメンバーの分も含めた情報が出力されます。この状態であれば、 WebUI でログインしたときにも他のノード情報が表示されるようになっていると思います。冒頭に出したスクリーンショットもこの時点のものを出しました。
proxmox-cluster-1

クラスタ構成でできること

クラスタの設定は HA の作業に必須となっています。上記だけでは HA の設定はまだです。
現時点でできることは、

  • 1つのWebUIログインで複数ノードの状態の確認&変更が可能
  • オフラインのVMであれば移譲が可能
  • コンテナであれば移譲が可能(オンラインでいけるらしい。未確認)

ここではVMの移譲について確認したいと思います。

この移動移譲はマイグレーションと表現されています。
Proxmox VE4.0 現時点ではローカルストレージにデータがあるものを参照しているVMは
オンラインでマイグレーションすることができません。
VMがシャットダウンされていれば、ローカルストレージに仮想マシンのHDDを設定していてもマイグレーションが可能です。

やり方は簡単で右クリックしたときのメニューで “Migrate” を選び、移動先のノードを選ぶだけです。
proxmox-cluster-2
proxmox-cluster-3
ここで実行すると以下の画面のようにマイグレーションが開始されます。
proxmox-cluster-4
成功すると pve 側にVMが移動しています。
proxmox-cluster-5

オンラインでマイグレーションさせるには共有ディスクを使うとできるらしいです。
NASなどの別ストレージで NFS 共有できるようにしておいて、PVEノード群にストレージとして登録させておくことでできるようです。
これについてはまた別途実験してみたいと思います。

クラスタから脱退

ノードの障害やメンテナンスなどで該当ノードをクラスタから切り離したいことがあると思います。
全VMを他のノードへ移動させた後でノードをクラスタから切り離します。

このノード内に VM がいない状態になったら、マスター側で作業を行います。
マスター側へ ssh でログインしてコマンドを実行します。

# pvecm delnode pve2

そして該当ノードを電源オフにした状態で、マスタの状態を確認してみます。

# pvecm nodes

Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve (local)

無事に切り離されたことが確認できました。
このとき PVE2 側が電源ONのまま稼働状態にあるとここに表示されたままとなってしまいます。切り離したのに表示されている、なぜだ?!と頭を悩ますことになるので注意しましょう。