「 2013年07月 」一覧

OCNモバイルエントリーd LTE 980に変えた


日本通信のb-mobile Fair 1GBを使ってスマホ端末を使用していたのですが、今最強ともいえるOCNモバイルエントリーd LTE 980 を購入したのでこちらのほうに切り替えてみました。

このSIMですが、現在はLTEとFOMA(3G)と両方に対応しているようです。
自分の端末がGalaxy S2 のため、このSIMが使用できない!と報告があったりして非常にドキドキしましたが現在の状況ではちゃんと使用できています。

パッケージにも 「NTTドコモXi端末・FOMA端末」と書いてありましたし、現在は悩まなくてもよかったのかも。

自分が動いている環境は、Galaxy S2 国際版, Android 2.3.4 です。今となっては古くてキャリアからも対応リストから外れているので、ここで情報をあげてみました。

余談ですが、nanoSIM版を購入です。ゆくゆくは他の端末に乗り換えたいな~と思っているので、今はアダプタをかませて使っていこうと思います。

今回焦ったポイントは2つです。
1つは、過去の情報で3Gのみ対応端末では使えないんじゃ…と気に病んだこと。
2つめは、amazonで注文して3週間弱かかってしまったこと。b-mobile側の残容量がなくなる寸前だったので間に合うか心配になってました。
amazonで注文する際には余裕を持った方がよさそうです。


エクスプローラサムネイル画像のシェル拡張を作成中です


Windows エクスプローラーシェル拡張としてのサムネイル画像を生成するプログラムを作成中です。今まで解析した画像関連のデコーダーをこのプログラムに集約させてみようかと思っています。

作成を始めたばかりですが今のところ、このような感じになっております。一応表示できているものはできてます。

そして、サムネイル画像を生成したらプレビューの方にも反映されるようで、こんな感じに表示できています。これにはちょっと驚きです。プレビューハンドラを作成して登録しないと、表示できないと思っていました。

見てわかるとおり、ATITC方式で圧縮されたDDSフォーマットに真っ先に対応してみました。その流れでDXT圧縮にはひとまず対応です。DDSは格納できるフォーマットが多く、これらを対応していくと大変そうですが徐々にがんばっていこうと思っています。

なお、このATITC形式は、AMDから公開されているツール TheCompressonator を使用して作成しました。


OpenGL 4.4が発表されたらしい


Siggraph開催中に、OpenGL 4.4 が発表されたらしい。

http://news.mynavi.jp/news/2013/07/24/093/index.html

また、Tegraのほうも進化したようで・・・モバイルなのに標準のOpenGLつかえるとか。今後のTegraはすごそうです。Keplerベースになるっぽいです。

http://pc.watch.impress.co.jp/docs/news/20130724_608921.html

OpenGL 4.4のほうは、いくつかの拡張機能が盛り込まれるようです。
「Direct3DからOpenGL 4.4への移植を簡単にするための機能が追加されている」とのことですが、
より詳細な情報が各方面から出てくるのが楽しみですね。


Let’s note R5にWindows7を入れてみた


R5にWindows8をインストールしてこれで使っていこうと思っていた矢先、どうにも不安定&遅い感じがしたので結局のところWindows7をインストールすることにした。

異常に発熱している気がしたので、分解してCPUのグリス塗り直ししてみたけど、多少効果が見られたものの時間稼ぎでしかなかったようでした。また増設メモリを取り外すことでマシにはなるのですが、これでは動作が重すぎてWindowsUpdateすら適用できない状況なので、採用は見送りです。

こういった結果、Windows7を入れることにしました。やってみるとWindows8の手順よりは遙かに楽で、工場出荷状態XP SP2からすんなりWindows7はインストールできますし、各種ドライバもVista対応キットのものが使えるし、導入はすんなりできました。

結局発熱は無線LANの影響によるものが大きそう。使うときだけONという運用でしばらくやってみようかと思います。
しかしそろそろR5も動作速度という点で非力さが目立ってきました。B5サイズでいい感じのものが出ないのかなと思っていますが、Ultrabookというものが何となくバッテリ持ちという点では競合になるし、コンパクトさより薄さ、な現在では難しそうに感じます。。。

前回のLet’s note R5にWindows8を入れてみた


Let’s note R5にWindows8を入れてみた


ずいぶんと前のPCになるのですが、Let’s note R5にWindows8を入れてみました。もともとはXPが動いていましたが、動作も遅くなってきたし、Win8では低スペックのPCでも動作できるという噂を聞いたのでチャレンジしてみました。

基本的にはWindowsVista や Windows7 をインストールする手順と変わらないようです。
これらについては、偉大な先人達がネット上に情報をあげてくれているためそれを参考にしました。

その情報に従い、下記の手順を実行しました。

  1. ノートPCの状態を工場出荷状態に戻す
  2. BIOSのアップデート
  3. USBメモリからWindows8をインストール
  4. Panasonicから入手したドライバ群をインストール

工場出荷状態に戻したのには理由があって、空き容量がどうしても確保できなかったためです。
またUSBメモリからインストールする際には、XP SP3がインストールされている必要があり、またUSBメモリに必要なデータをコピーしておくために、 Windows 7 USB/DVD DOWNLOAD TOOL を用いました。

また工場出荷状態ではXP SP2の状態でしたので、XP SP3への更新に時間がかかってしまいました。
WindowsUpdateでなぜか正常に実行できなかったので・・・。オフラインインストールでSP3に更新です。

Windows8がインストールできた後のドライバのインストールでは、Panasonic Miscドライバと HotKeyドライバを入れるのですが、実はこれらはR5用ではなく、R8用のものを入れる点にも注意が必要です。
R5用のVista対応キットに含まれている物ではインストールすることが出来ません。

そして、グラフィックスドライバもちょっと厄介でした。
Windows標準ではドライバが入らず、R5用グラフィックスドライバではブルースクリーンor応答停止を繰り返す、という状況になってしまいました。
 そのためウチの環境では、Intelからダウンロードしたちょっと古いドライバですがこれを使用することにしました。(http://communities.intel.com/docs/DOC-19647 から、win7_1512754.exe をダウンロードしました。)

このままではスタートボタンがなくなっているWindows8のため、StartMenu 8を入れて使用開始です。


なんでもSSEのほうが早いとは限らない


SSEを使用するプログラム作成に今、ハマってます。というかちゃんと勉強を始めてみたところなのですが、意外とシンプルなアルゴリズムでもSSE2などを使ったからといって必ずしも早くなるとは限らないというのを体験しました。

やってみたのは、32bitのARGBの色並びをRGBAに並び替えるというものです。

普通にCPUでやると、 色を左8ビットシフト、アルファを右24ビットシフトを合成すれば並び替えは終了します。
この操作をよく見てみると実は、同じ色を並べてシフトするだけで実は並び替えが完了するということに気付き、せっかくなのでコレをSSE2でやってみた次第です。

AARRGGBB AARRGGBB –> RRGGBBAA RRGGBB00 (左に8ビットシフト. 左のブロックが並び替えが終わっている)

また初期のものをそのままSSE2で書いてみたものも用意して、これらを速度比較してみました。
最近のi7のCPUでは差が見えないだろうと思ったので、Pentium E6500 で実験してみました。

1024×1024画像で
標準 2.79 ms
SSE2(1) 3.29 ms
SSE2(2) 2.84 ms

意外と標準状態のものが高速でした。
画像データがアライメントされていない状態でやっているためにSSE2にとっては不利だったかもしれません。
(速度を最速目指すと言うよりは、来たデータに対して最速を目指すというルールのため)

ちょっとコードがふくれてもSSE2にしたほうが高速だったりするケースもあるようですし、まだまだ勘所がわからないなと思います。

追記

32bit整数のビットシフトで扱わずに、バイト単位での入れ替え操作を記述している場合は、一番動作が遅かったです。


GL_NV_Path_Renderingを試す その3


一応、ASCII文字は表示できたので今回は日本語文字列を表示させてみたいと思います。
日本語はUNICODEリテラルとして設定して、UNICODEにおけるBMP領域しか使わないものとして(UCS2範囲で)扱うので、UTF-16タイプでセットすることで描画できることが確認出来ました。

まずはこのように、使用するフォントを登録します。この場合は MS明朝 > Arival > Missing という優先度でフォント検索が行われます。
また使用する文字コード範囲分グリフのパスを準備しておきます。

続いて前回同様フォントメトリクスを取得

文字列の指定に、GL_UTF16_NV を使用しているところと、文字列長に合わせてオフセット配列を取得するように変更しています。
この後、前回と同様に文字列描画コードを書くと(GL_UTF16_NVを使うようには修正が必要ですが)日本語でも表示させることが出来ました。
こんな感じの結果が得られました。

プロジェクション行列で文字列の描画矩形分で設定しているため、文字の縦横アスペクト比がちょっとおかしいです。


GL_NV_Path_Renderingを試す -その2-


前回は図形を書いてみたので今回は文字列を書いてみます。これもまたサンプルにあったほぼまんまのように見えますが、任意の英数文字N個に出来るよう改良しています。

初期化ブロック

初期化部分です。任意の文字数と言った割には、配列サイズを大きめにとっているだけだったりします。

描画部分

文字列を書いている部分です。
やっぱりこちらも前回のパス描画と同様にステンシルに書いて、範囲をフィルすることでパスを描画している感じになっています。

実は一番最後の glPathColorGenNV が大切だったりします。これを忘れるとここでやったグラデーション設定が他の部分にまで適用されてしまい思うような描画結果になりません。

これを実行して得られた画像が以下のようになります。

描画するまで手間ではありますが、他のリソースを用意したり複雑な管理機構を作らなくても良さそうな点から、これを用いて文字列描画を行うようにするのは意外とアリな感じもします。


GL_NV_path_rendering を試す -その1-


今回からちょっとしばらくは、NVIDIAのPath Rendering拡張をいじってみます。
これはベクターグラフィックス描画をNVIDIAのドライバがやってしまうという拡張で、GPU支援が受けられるため従来のCPUレンダリングと比べると圧倒的に高速に動作するようです。
 今のところは、NVIDIAのグラフィックスボード搭載機種でOpenGLを使ったときに動作させられるようです。

流れ

具体的にはパスを描画して塗りつぶし、輪郭(アウトライン)の描画、という2ステップで行うようです。どちらのステップもOpenGLで描画の際には、ステンシルバッファを使用して、ある矩形をステンシル参照しつつ塗りつぶすという動作をしているように見受けられます。
 また、このパスレンダリングは従来のグラフィックスパイプラインとは別のパイプラインを通るようです。

サンプル提供されているチュートリアルそのままですが、これから紹介していきたいと思います。

まずパス用のオブジェクトを用意して、そこにSVG形式での文字列(コマンド)をセットします。ちなみにPostScript形式も扱えるようです。

まずパスにより塗りつぶしを行い、その後輪郭を書くという処理を行っています。これらを適用するとこんな絵になります。


GL_AMD_pinned_memory を試してみた


以前から気になってはいた GL_AMD_pinned_memory 拡張を試してみました。自分の環境は、APUではない通常のRADEONボードをさした環境であるので、一応動くには動くだろうと思って試してみました。ただ動いたとしても本当に効果を発揮するのは、GPU,CPUともに同じメモリを使用するAPU環境だと思います。

使い方は簡単で、通常のバッファ作成のところ(glGenBuffers周辺コード)のところを変更するだけです。

コードを見ておおよそわかると思うのですが、説明すると以下のような感じです。

  1. バッファを作成する
  2. バッファを GL_EXTERNAL_VIRTUAL_MEMORY_BUFFER_AMD でバインドする
  3. メインメモリ上にデータ元となるバッファを用意する。このときにアラインメントを考慮する必要がある。
  4. アライメントされたバッファにデータを詰める。
  5. アライメントされたデータを元に glBufferData で転送する

次に、毎フレーム実行される部分で、先ほどのアライメントされたバッファの中身をいじってみます。

この状態で描画を行うとこんな感じになります。

OpenGLを使い慣れている人は、この動作にびっくりするはずです。
通常だと、VBOを使用して頂点データを扱いますが、これを更新するには glMapBufferやglBufferDataといった関数を用いて、更新されたデータを1度転送する必要がありました。
 しかし、この拡張を使用すると、メインメモリのバッファを書き換えただけで描画のデータも反映されている!ということに。実際のところは同一のデータを使うため拡張なので、同期というのがメインではないのですが。

当然ながら、target変数に GL_ARRAY_BUFFER を設定してデータを作成してみるとこのようには動かず、単に四角形がスタティックに描画されるだけの状態となります。

動作環境

Windows7 SP1
RADEON 6850 (Catalyst 13.4)