OpenGL一覧

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

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


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

今回は OpenGL ES 3.0 以降で使えるようになった ETC2 について試してみました。アルファチャンネル入りでの圧縮形式として標準的に使えるようになった形式です。基本的な実装方針は ETC1 の拡張したイメージになっています。

データの作成は Mali Texture Compression Tool を用いて行っています。品質は最高品質を選んでいますが、待てないほどではないにしろ割と時間がかかるかなという印象です。その分画質はどうなっているか確認してみたいと思います。

左がオリジナル、右が ETC2 圧縮したものですがどうでしょうか。違いはぱっと見た感じでわかるでしょうか?

compare-etc2-sample01
compare-etc2-sample02

個人的には ETC1 のころと違ってよく綺麗に圧縮できているのではないかと思っています。そこで今度はこれらの一部分を拡大して確認してみたいと思います。 続きを読む


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

今回は PVRTC2 の圧縮について、どのくらいの劣化が起こるのかを調べてみました。 PVRTC2 って有名なようでイマイチな感じで、これを検索キーワードにしても PVRTC1 の 2BPP モードがヒットする感じです。 PVRTC-I, PVRTC-II という表記の方がいいのかもしれませんが、 imgtec のブログでは PVRTC, PVRTC2 という記述をされているようです。

PVRTC2について

PVRTC2 は PVRTC をさらに拡張した形式となっています。基本的なブロックフォーマットはそのままに、ブロックごとの2色を記している最上位ビットに別の意味を持たせた感じにしています。それぞれに Opaque なビットは不要、他方から判定すればよし!というのは納得がいきます。
この別の意味を付与されたビットを HardBit と呼んでいます。これにより最近流行のブロックのモードを追加するということを実現しており、追加されたモードは Non-interpolated(非補間), Local palette(ローカルパレット) モードの2種類となっています。これらの仕組みから PVRTC2 は画質の向上のために用意されているようです。

参考: PVRTC,PVRTC2についての Imagination Technologies のブログ

実験

以前の BC7 のノイズ検証でも使ったデータを利用して確認してみます。PVRTC2 データの作成ついては、今のところ PVRTexTool で行えます。
このツールは前後でのノイズ(エラー)も表示させることが可能なため、以前のように別アプリで処理しなくても簡単に確認できます。ここではそのスクリーンショットを載せることで見ていきたいと思います。
注意事項としては、 BC7 と PVRTC2 を単純に比較してはいけないということです。お気づきかと思いますが、 BC7 は 8bit per pixel(BPP) であり、 PVRTC2 は 4BPP であるということです。つまり PVRTC2 が BC7 よりも2倍圧縮率が高いということで、すなわち BC7 より見た目が悪くても当然ということです。

pvrtc2-noise-sample01

pvrtc2-noise-sample02

よく言われていることではありますが、PVRTC系はアルファチャンネルも持たせられるがその場合カラーの品質が落ちる、というのが今回も健在のようです。最初の例ではアルファ抜きの部分にもノイズがありますし、アルファが変化するブロックにあるカラーブロックがひどいノイズとなっています。
アルファ不要のケースにおいてはノイズは階調が変わる輪郭部分に大きく発生していますが、等倍の目視ではあまり感じられないかと思います。 続きを読む


BC7の圧縮ノイズについて調べてみた

優秀だという BC7 圧縮の品質がどんなものか調べてみました。
そのためにはそこそこの品質以上の画像データが必要だったので友人に協力してもらい画像を使わせてもらっています。
この場を借りてお礼申し上げます。

BC7への圧縮については Codeplex からダウンロードできる Microsoft の TexConv を使用しています。この最高品質となる CPU で処理した結果ではなく、 GPU を用いた速度とのバランスがとれているであろうモードを選択しています。

比較

いきなりですが圧縮前後の画像を比較してみます。
左が圧縮前、右が圧縮後のデータです。圧縮ノイズなどは確認できるでしょうか?自分では等倍でぱっと見た感じわかりませんでした。心持ち髪の毛曲線部とアルファの部分でノイズが気になるかも程度です。
compare_std_bc7_sample01
compare_std_bc7_sample02

続きを読む