「 OpenGL 」一覧

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


Ubuntu で NVIDIA のボード&ドライバを使って試してみました。

NVIDIA のプロプライエタリドライバをインストール

今回使用したのが NVIDIA の Geforce 750 Ti だったのですが、
Ubuntu 15.10 の標準インストールで使える nouveau ドライバでは通常の描画からして異常で使い物になりませんでした。
そこでプロプライエタリドライバをインストールするに至りました。

ドライバのインストールは以下のようにして行いました。

このドライバをインストールしてもうまく動かないようならば、
最初の描画不正の点も相まってボード故障も疑うところでした。
実際のところ、ドライバのインストール後の再起動したあとからは正常に描画できるようになりました。

コマンドでインストールしましたが、GUIからもインストールは可能だと思います。
(Additinal Drivers 関連かSoftwareセンターからできるかと思われます)

プログラムの実行

X-WindowなしでのOpenGLなプログラムを実行してみました。
そもそもこのドライバ使用でも /dev/dri/card0 が出現していたので、
KMS有効であると考えて、先日のプログラムは動くのではないかと思った次第です。

しかし結果は drmOpen で失敗してしまうようで、動作確認に至りませんでした。
NVIDIA のプロプライエタリドライバでも/dev/dri/card0 へのアクセス可能なようでしたが、 drmModeGetResources で失敗してしまうようでした。もう一歩でうまくいきそうな感じがするだけに、残念です。

追記

どうやら KMS サポートしているという見え方がダミーだったようです。
/dev/dri/card0 あたりがすでにダミーデバイスノードとの情報を見つけました。
そのせいもあって、 weston も動作しないという情報もあるようです。

http://wayland-bugs.freedesktop.narkive.com/4zE7PwYd/bug-90323-weston-launch-drmmodegetresources-failed


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 ドライバでは動作しないと思われます・・・)


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 によるコード貼り付けで以下を説明していきます。 続きを読む


Ubuntu 15.10 に更新(on Proxmox)


先日インストールした Ubuntu ですが 15.10 (本家?)のアップデートのダイアログが出てきたのでそのまま更新してみました。

Ubuntu 15.10

気になる点を確認してみたのでそれらについてメモしておきます。

Mesa3D

無事に Ubuntu 15.10 になったようです。このときいろいろなパッケージが更新されたようで Mesa 3D もまた変わっていました。
あいかわらず Proxmox 上なのでグラフィックスボードが使えないため、llvmpipe をつかったソフトウェアラスタライザですが、Mesa のバージョンが 11.0.2 へと更新されていました。実行時のパフォーマンスについては数字上はやや低下していましたが、気にするほどの変化ではないかと思います。

es2info の結果を以下に載せておきますが、変化なしでした。

GCC

バージョンは 5.2.1 になっていました。

ついでにクロスコンパイラのパッケージも確認だけしてみました。

クロスコンパイラの方もまた gcc5 となるようです!


Ubuntu 15.05 on Proxmox


割と最近でたばかりの Ubuntu 15.05 を Proxmox の仮想マシンとしてインストールしてみました。しかしながら Ubuntu Desktop 日本語 Remix の iso をダウンロードしようとしたら、なぜか 15.04 という記載になってて混乱してます。
 単なる間違いだろうということであまり気にせず作業してみました。通常の Linux のインストールと同じように Proxmox の仮想マシンを構成してインストールを行いました。

そして起動後

普通に起動してきて問題はなさそうです。しかし環境の問題なのか非常に動作がもっさりとしています。top で見てみると、compizがおよそ 20% 常時持って行っていました。これについては初回なので様子見です。

openssh-server をインストールして ssh terminal で操作しているときには若干遅いかな、という程度でした。

OpenGL関連など

せっかく Ubuntu の新しいものをいれたので OpenGL に関係するところをちょっとだけ調べてみました。調査するのに必要なパッケージを以下のようにしてインストールしました。

この後に、Proxmox のコンソール上で es2_info を実行してみました。

このようになりました。インストールされた Mesa 3D は 10.5.9 であることがわかりました。またグラフィックスデバイスが使えないので、ソフトウェアレンダラーである llvmpipe が選択されています。ソフトウェアレンダラーでもこのくらいの GL拡張が使えているのは個人的に驚きでした。良い時代ですね.

そしてものは試しと es2gears を実行してみたところ以下のようにちゃんと動作しました。FPSとしては 160FPS 程度となってます。実際の見た目は Webブラウザ経由しているのでちょっとカクカクですが動作としては意外とまともに動いていると感じました。(N3150MのVM上であることも考慮して)。

その後

しばらくすると以下のように、 15.10 へのアップデートを促すダイアログが出てきました。今一番新しいのは 15.10 ということのようです。今現在の Ubuntu Desktop 日本語 Remix とのズレが多少あるということっぽいです。


OpenGL でデュアルディスプレイのフルスクリーン


なかなかやっている人も少ない OpenGL のフルスクリーンの話になります。さらにそれのデュアルディスプレイ版となるとほぼ皆無といっていい内容かと思います。ちなみに先日の Windows 10 では使えるのか?と試した話の延長です。

OpenGL では DirectX とは違い、それぞれの画面で OpenGL のコンテキストを作り、必要に応じてリソースを共有できるようにします。あとはコレを wglMakeCurrent で切り替えつつ描画を行う、といった感じで処理するので、別段難しいことはここにはないです。
フルスクリーン化するAPIは OpenGL にはないため、 Windows API で最前面で全画面をおおうウィンドウを作ります。

最大の問題点

OpenGL APIでフルスクリーン化する機能を備えていないため、 Windows API で何とかする感じになっています。つまりは OpenGL はフルスクリーンについて何も考慮をされていないといってもよいでしょう(言い過ぎかもしれませんが・・・)
試しに近年の Windows OS でこれらの挙動を確認してみました。以下に示すようにデバイスとOSと依存して使えない環境もあるようです。
(機材の関係で、環境をそろえることが出来なかったり、ばらばらだったりしますがご了承下さい)。

OS デバイス 判定
Windows7 Geforce650Ti OK
Windows8 Geforce750Ti NG
Windows8.1Update Geforce750Ti OK
Windows10(build10240) Geforce750Ti OK

ここでの使えないというのは、他方のウィンドウに描画される内容がとても低フレームレートになってしまい、なめらかな描画更新ができないという状況を意味しています。
そもそもそれぞれの画面内をクリックするような操作を行うと、一瞬おかしな映像が見えてしまったりするのですが・・・。
試したドライバは、現在の最新版 353.30 でした。NVIDIA というと OpenGL 対応を積極的に行っているメーカーのような印象があり、うまく動くと思っていただけに今回の件は残念でした。

続いて AMD (RADEON) で同じことを確認してみました。

OS デバイス 判定
Windows7 RADEON HD 7750 未チェック
Windows8 RADEON HD 7750(14.4) OK
Windows8.1Update RADEON HD 7750(14.4) OK
Windows10(build10240) RADEON HD 7750(15.7) OK

こちらの場合にはそれぞれの画面内をクリックするような操作を行っても、一瞬おかしな映像が見えたりしませんでした.

まとめ

OpenGL でデュアルディスプレイのフルスクリーン対応は Windows8 が例外的な動きをするようなので、難しそうです。もしかしたらいつか NVIDIA ドライバが更新されて正常に動くかもしれませんが、今となっては比較的古い Windows8 なので見込みは薄そうです。


Windows10 で OpenGL 使えるのか?


Windows10 の正式なリリースが間もなくとなってきました。この Windows10 で DirectX 12 が使えるようになるというのは、各所で語られていて有名な話ですが、それと対を成す OpenGL は生きてるんだろうかと思って、まずは軽く調べてみました。

opengl-capture-win10

軽くといいつつ、デュアルディスプレイでそれぞれにフルスクリーンとなる OpenGL アプリケーションを動かしてみました。上記の図は その時の様子を PrintScreen でキャプチャしたものです。本来は同じクリアカラーおよび同じような位置で三角形を書いているのですが、なんかおかしなことになっています。実際のモニターでは2つの画面でこのようなズレはないので、不思議なところです。
ちなみに、2つのディスプレイ解像度が違うため、アスペクト比がずれているので全く同じ絵にはなりません。

このときの OpenGL コンテキストの情報を出してみるとこんな感じでした。

今のドライバだと NVIDIA で OpenGL 4.5 が使用可能なようです。ドライバが入っていなくて、OpenGL のエミュレーションというかリファレンスドライバで動く、なんて状況ではなさそうです。

まとめ

とりあえず NVIDIA ドライバでは OpenGL はそのまま使えそうです。他の AMD や Intel のほうで DirectX12 & OpenGL が両方サポートされるかどうかは、徐々に調べてみようと思います。
それと、 PrintScreen ってこんな挙動だっけと不思議な部分があるので、Windows7, 8.1 あたりで同じだったかも調査してみたいと思います。

その他

OpenGL でフルスクリーンは調べるとよく出てくるのですが、そこ止まりで、複数ディスプレイで OpenGL をやっている例を見かけませんでした。相当マイナーな部分なのでしょうか。こうも事例が見つからないと、たまたま動いているだけ感を感じます。


BC7について段階的にデコードしてみた


BC7のCPUデコーダーを作っている過程でおもしろいものが確認できたので記事にしてみました。当たり前の話ではあるのですが、視覚化されたケースって無いようなので。
BC7 はいわゆる第2世代のテクスチャ圧縮技術で、各ブロックごとに最適なモードを選択してデータを圧縮しています。このブロックがどんな風に割り当てられているかを、ブロックごとの色分けで塗ってみたら以下のような結果を得られました。

image_partition

この段階でも各ブロックの特徴によってモード選択されているのが確認できます。そのためおおよその画像の検討が付く程度にはなっています。これらのブロック種別を順番に展開してみます。 続きを読む


ASTCの圧縮ノイズを調べてみた


今回は期待のASTC圧縮のノイズを調べてみました。

ASTCについて

詳しいことは各所のサイトで触れられていますのでここでは簡単に。 Adaptive Scalable Texture Compression の略で、ARM が開発しました。DXTCがS3の特許関係で色々とあったためか、 ASTC はロイヤリティフリーなことも取り上げられています。
基本的には他の現世代のテクスチャ圧縮と同じくブロックごとのモードを多数持っていることが特徴です。ASTC 固有の特徴は、なんといってもブロックサイズの変更ができるということではないかと思います。

実験

ASTCではブロックサイズを変更することができ、許容できる範囲で BPP を落として削減することができます。試行錯誤の余地があるといえます。
ここでは BC7 や PVRTC への対抗と考えて、それと同じレベルの BPP でチェックをしてみたいと思います。

圧縮のためのツールとしては Mali Texture Compression Tool を用いています。圧縮品質としては最大の品質レベルを選択してデータを作成しました。

ASTC 8BPP(4×4)での結果

8BPPとなるように 4×4 ブロックで圧縮を行いました。この場合は以下のような結果となりました。次の規格レベルだけあって予想通り綺麗に圧縮できていると思われます。左右に並べたくらいではちょっとわかりません。

compare_std_astc_sample01

compare_std_astc_sample02

ツールのほうでは圧縮前後でノイズ具合も表示できるのでこちらの画像も掲載しておきます。
ノイズは割と控えめな感じかと思われます。 [続きを読む]