モニターももうすぐ三ヶ月です。
このクラスの同スペックな PC はたくさんあります。
基本的な PC 部分の性能はほぼ横並びでそれほど大きな違いはありません。
PC 部分はおそらくあまり他と変わらない感想になってしまうことでしょう。

だからこそ差別化が必要で、その点メビウスは強烈な個性を持っていました。
光センサー液晶パッドを搭載していることです。

タッチパッド部分が液晶画面なのです。
この液晶パネルがセンサーも兼ねているとのこと。
この不思議なデバイスは、各画素が光に反応し2次元のイメージとして取り込むことが
できるようです。
処理次第では全く制限のない入力装置になるかもしれません。

惜しむらくはこの個性とテクノロジーが、メビウス自体の魅力に思ったより
つながっていなかったということです。
この点過去の書き込みでいくつか考察してきました。

それでもレポート開始当初はかなり楽観視していました。
6月に開発キットが公開されるとの記事があったからです。

・ASCII.jp 謎のMebiusは光センサー液晶パッド搭載のNetbook！
　＞光センサー液晶パッドのアプリケーション開発に必要な情報や開発キットは、
　＞同社から6月くらいに提供される予定。ユーザーにより開発された独自アプリ
　＞ケーションの登場も期待される。

初物で使いづらい点があったとしても、もしかしたら自力で何とか出来るのでは無かろうかと。
レポートに書くネタにもなるし仕組みや出来ることに興味もあったからです。

でも結局開発キットは無し。
アプリケーションが一つ追加されたのみで、光センサー液晶パッドで出来ることは
残念ながら発売直後とあまり変わりませんでした。

●おすすめできる点

・手書き文字入力

パソコンで手書文字認識できる機能はよくあります。その扱いやすさを考えると
電子辞書のように手前に液晶パッドが付いているスタイルはたいへん理にかなっています。

タッチパネル付きの PC は少なくないですし、タブレット PC だって各種あります。
でもキーボードの奥の液晶画面まで手を伸ばして、そのままペンで書くのはたいへんです。
逆に液晶を折りたたんでタブレット形状にしてしまうとキーボード操作に難儀します。

メビウス PC-NJ70A は普段の PC スタイルながら、すぐ手が届く手前にタッチパッド
があり、いつでもペンを扱えます。キーボード操作も妨げません。
メイン液晶＋キーボード＋液晶パッド、といったスタイルは今のところメビウス
独自のものです。

もう少し動作が速くて気持ちよく操作できたなら、手書き以外の他の機能も
お勧めできたかもしれません。

●改良希望点

通常のタッチパッドと比べてまだ使いづらいところがあります。
独自の専用アプリケーションもまだまだ不足しているように思います。
このように 1つ 1つの細かい点は気になりますし、実際にレポートやアンケートで
報告させていただきました。
でも本当は、ソフトウエアで継続して更新していけるのが PC の良いところです。

結論として、今最も感じている足りないところは、発売＆モニターレポート開始から
3ヶ月経過してもほとんど変わってないところだと思います。

光センサー液晶パッドを使ったアプリが次々と出ていたり、アイデアをすぐに実現
出来る環境があったなら、今は多少不満があっても
「今後なんだか良くなっていきそうだ」 とか 「今後面白くなっていきそうだ」 といった
勢いや流れが見えていたかもしれません。
自分で何とか出来そうだ、と思えるだけでも十分だったと思います。

おそらく今一番危惧しなければならないのは、このまま変わらないのではないかと
思ってしまうことでしょう。

関連エントリ
・メビウス PC-NJ70A (8) タッチアプリとイルミスキャン
・メビウス PC-NJ70A (7) 一ヶ月後
・メビウス PC-NJ70A (6) ユーザーインターフェース
・メビウス PC-NJ70A (5) サブモニタ
・メビウス PC-NJ70A (4) 使用感
・メビウス PC-NJ70A (3) Windows7 RC を入れる
・メビウス PC-NJ70A (2) 初期セットアップとメモリ増設
・メビウス PC-NJ70A 液晶センサータッチパッド
・メビウス PC-NJ70A 画面解像度とタッチ

今まで全く使っていなかったので、やはりいろいろな面でつまずいたりします。
特に操作に慣れておらず、初歩的なキーボードやマウスの設定が落ち着くまでも
結構かかりました。以下そのメモです。

●キーボードの配列

Windows 用キーボードを USB 接続で使っています。
システム環境設定のキーボードショートカットから Ctrl キーの配置変更ができます。
でも ESC キーの入れ替えがありません。
ソフトウエアでの入れ替えだとアプリケーションによってキーボードの認識に差が
生じる可能性もあったのであきらめました。

結局ハード的にキーの入れ替え機能を持ったキーボード (DHARMAPOINT DRTCKB91UBK)
に交換して、キーボード側で Ctrl/ESC の位置を置き換えています。
Mac 標準の日本語キーボードだと最初から Control キーが A の左に配置されて
いるので、これで良かったのかもしれません。

●日本語変換のキーカスタマイズ

標準の日本語変換だと設定項目が少なくキー操作の変更ができませんでした。
Windows の場合、MS-IME でも変換操作のキーを自由に変更することができます。
たとえば日本語入力中の文節移動や文節伸縮の操作を全部ホームポジションから
操作できるように設定できます。

ATOK2009 を導入しました。
web にはこの辺の情報が無くカスタマイズができるかどうかわからなかったのですが、
Windows 版では出来ているので入れてみました。
結果当たりでした。Windows 版同様にキー操作を変更できます。
カーソル移動や文節伸縮などを任意のキーに割り当て使っています。

●マウスの挙動

最初は気にならなかったのですが、使っていてどうもマウス挙動に違和感を感じる
ようになりました。カーソルが移動が遅いので、速度設定をあげると微調整が
スムーズにできなくなります。小さいボタンがうまく押せない感じ。
当初マウスの問題かと思って、新しいマウスに取り替えたり電池を替えたり
マウスパッドを用意してみたり、ワイヤードマウスにしたりといろいろ試しました。
下記のページによると OS 側の問題だったようです。

・MacOS Xのマウス挙動 Pert2 (absurd-wings)
・Mac OS X のマウス加速問題

Microsoft 製のマウス (Explorer mini) と、マウス付属のユーティリティソフト
Microsoft IntelliPoint を導入することで使いやすくなりました。

OpenCL で扱える SIMD の vector 型は、float4 や int4 といった型名表記に
なっています。この点は HLSL と同じです。
GLSL では vec4 や ivec4 等の独自の型が用いられていました。

また GLSL の場合 1コンポーネントの vec1 型は無く vec2～vec4 のみ。
OpenCL の仕様をよく見ると、最大 16要素まで扱えるものの使える組み合わせは
2, 4, 8, 16 だけです。つまり float1 も float3 もありません。

GLSL       (float)  vec2     vec3     vec4
OpenCL     (float)  float2   -        float4   float8   float16
HLSL       float1   float2   float3   float4

Compute Shader で用いられる HLSL では float1～float4 すべて使えます。
もともと vector<> の別名にすぎず、1～4 まで任意の数値を与えることができます。
つまり下記の定義と同じです。

typedef vector float4;

また float v; と宣言した場合の v.x が許されるのも HLSL 独自かもしれません。

OpenCL は要素数が増えているため、swizzle も xyzw だけでなく s 表記が
追加されています。(rgba は無し)

float16  v;
  v.s0 // == v.x
  v.s1 // == v.y
  v.s2 // == v.z
  v.s3 // == v.w
  v.s4
  ～
  v.se
  v.sf

例えば v.xy は v.s01 と記述可能。float16 の全要素代入を明示的に書くなら

float16  d, s;
d.s0123456789abcdef = s.s0123456789abcdef;

逆順にするなら

d.s0123456789abcdef = s.sfedcba9876543210;

float16 を 4×4 matrix とみなすなら Transpose (転置) は

d.s0123456789abcdef = s.s048c159d26ae37bf;

と書けます。
値数は括弧表記で、コンストラクタではなくキャストが付きます。

float16  d= (float16)(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);

すべて同じ値ならスカラーからの変換が使えて d= (float16)(0); と書けます。
スカラー以外は個数が一致する必要があります。

float4	 a= (float4)( 1.0f );
float16  d= (float16)( a, a, a, a );
float16  e= (float16)( (float8)(1.0f), (float8)(2.0f) );

一つ下のサイズの vector を取り出す suffix もあります。odd, even, lo, hi

float16  a= (float16)(1);
float8   b= a.odd; //== a.s13579bdf
float4   c= b.odd; //== b.s1357
float2   d= c.odd; //== c.s13 == c.yw
float8   l= a.lo;  //== a.s01234567
float8   h= a.hi;  //== a.s89abcdef
float4   ll= a.lo.lo; //== (a.s01234567).s0123 == a.s0123

おそらく特定の swizzle の別名です。
s 表記でも書けます。a.s01234567.s1357.s01 (== a.lo.odd.lo)

opencl-1.0.43 には 4×4 Transpose の応用例が載っています。

・KHRONOS GROUP OpenCL
・Khronos OpenCL API Registry

opencl-1.0.43.pdf page 134

//transpose
t.even = x.lo;
t.odd = x.hi;
x.even = t.lo;
x.odd = t.hi;

x t はどちらも float16。
展開してみます。

t.s02468ace = x.s01234567;
t.s13579bdf = x.s89abcdef;
// t: 0 1 2 3 4 5 6 7    <= x.lo
//     8 9 a b c d e f   <= x.hi
// t= 08192a3b4c5d6e7f

x.s02468ace = t.s01234567;
x.s13579bdf = t.s89abcdef;
// x: 0 8 1 9 2 a 3 b    <= t.lo
//     4 c 5 d 6 e 7 f   <= t.hi
// x= 048c159d26ae37bf

なんだか SSE のプログラムを見ているようです。
1行で記述できるのにこのような例が載っているということは、
Larrabee のプログラミングはこんな感じなのかもしれません。

GPU べったりのシェーダーとはまた違った印象です。

関連エントリ
・ATI Stream SDK 2.0 beta と OpenCL

Windows 版 vim を使っています。
といってもちょっと便利な vi 程度にしか使っておらず、カスタマイズは最小限で
済ませています。コマンドシェルから gvim を起動してファイル毎に別のエディタを
開くスタイルです。
shell + gvim の組み合わせは X68000 の Ko-Window 上で vi (stevie) を使う
場合とよく似ています。shell と別ウィンドウでいくつでも開けるからです。
ほとんど同じ感覚で使用しています。

vim は vi 系のテキストエディタです。
コマンドシェルからヒストリを使ってエディタを呼び出していると、すでに開いている
ファイルなのに、つい多重で開いてしまうことがあります。
同じファイルを複数のエディタで同時に開くのはまずいです。
最後に保存した方の更新しか残らないからです。
stevie の時はよくミスしがちでした。

幸い vim の場合はあまり困ったことにはなりません。
ファイルを開くと .swp ファイルが作られるので、そのファイルがすでに編集中なのか
わかります。すでに .swp ファイルがあるなら、このまま開くか ReadOnly
で続けるか、起動を中止するか確認してくれます。

便利な反面、衝突するたびに動作を選択して中止し、起動中のウィンドウから
目的のものを探し出すのはだんだん面倒になってきます。
そこで、下記のようなプログラムを作って使っていました。

・指定したファイルがすでに gvim で開いているかどうか調べる
　　・もしすでに存在していたら、そのウィンドウをアクティブにする
　　・無ければ新たに gvim でそのファイルを開く

もしかしたら vim 自体に何らかの設定があったり、最初から似たような機能が付いて
いたり、または同等のものが存在しているのかもしれません。
必要あるかどうかわかりませんが置いておきます。

・runvim100.zip

使い方

runvim [option] [＜ファイル名＞]

　-e＜起動するgvimのパス＞

たとえば alias や shell の関数定義で下記のように定義しておきます。
(gvim のパスは任意)

alias vi='runvim.exe -eC:/app/Vim71/gvim.exe'

上記定義した後「vi ファイル名」で起動すると、すでに開いていれば対応する
gvim を最前面に持ってきて入力フォーカスします。
無ければ gvim を通常起動します。

以下 vim (7.1) の個人的な設定です。
Vim 自体は本家 vim.org からダウンロードしたパッケージをそのままインストール
しています。

" $HOME/_vimrc
se ai columns=80 lines=46 hls nobackup ruler
se guifont=ＭＳ_ゴシック:h8:cSHIFTJIS
se linespace=0
se guioptions=grLt
se mouse=a
se iminsert=0 imsearch=0
se enc=cp932
se guioptions-=a
se statusline=%<%f\ %m%r%h%w%{'['.(&fenc!=''?&fenc:&enc).']['.&ff.']'}%=%b\ %B\ %l,%c%V%8P
lan en
lan cty en
lan mes en
lan tim ja
syntax enable
hi Constant	guifg=#a03800
hi PreProc	guifg=#008010
hi Folded	guifg=#808000 guibg=#fffffe
hi FoldColumn	guifg=#808000 guibg=#fffffe
so $HOME/format.vim
let format_join_spaces=2
se foldmethod=syntax

実はフォントは難ありで、この設定だと小文字のエル=l と大文字のアイ=I の区別が
付かないけど慣れました。このままプログラム書いてます。

format.vim は日本語で join したときに空白が入らないようにするため使用しています。

doxygen syntax を追加しています。
Vim を install したフォルダ内の filetype.vim を書き換えます。
"setf cpp" や "setf c" と定義されているところを全部 "setf cpp.doxygen"
のように変更します。".doxygen" を追加するわけです。
これで syntax として cpp が選択されると同時に doxygen のキーワードハイライト
が有効になります。

折りたたみ機能も利用しています。
そのまま folding を有効にすると C ソースコードのブロックも折りたたまれて
しまうので、その設定は削除。その代わり doxygen のコメントを部を折りたためる
ようにしています。

(1) syntax/c.vim の中の syntax ～ fold ～ と書かれた行の "fold" を全部削除
　　たとえば下記のように (syn ～ で始まる場合もあり)

syntax region	cBlock		start="{" end="}" transparent fold
　↓
syntax region	cBlock		start="{" end="}" transparent

(2) syntax/doxygen.vim に下記の 2行を追加

syn region myDoxFold start="/\*!" end="\*/" transparent fold keepend
syn sync fromstart

折りたたみ操作は vim 上で zr または zm です。

.hlsl や .fx 等、自分が使うファイルの syntax も追加しています。
専用の syntax ファイルが無くても、C言語系なら c や cpp を割り当てるだけで
見やすくなります。
たとえば filetype.vim を書き換えてこんな風に。(fsc は自前の C言語スクリプト)

" filetype.vim
au BufNewFile,BufRead *.fsc			setf cpp.doxygen

Vim の syntax や script ファイルは下記ページで検索できます。

・vim.org Scripts Browse all

関連エントリ
・vi の話

まだ未対応らしく Windows7 にはうまくインストールできませんでした。

・ATI Stream Software Development Kit (SDK) v2.0 Beta Program

インストーラが正常終了しても Program Files の ATI Stream フォルダが
空のままです。
とりあえず Vista で展開したのちパスを通せば使えなくはないようです。
よく見ると OpenCL は GPU 未対応で CAL も無くなっています。
Intel CPU (+GeForce) でも動きました。

CL_PLATFORM_PROFILE    = FULL_PROFILE
CL_PLATFORM_VERSION    = OpenCL 1.0 ATI-Stream-v2.0-beta2
CL_PLATFORM_NAME       = ATI Stream
CL_PLATFORM_VENDOR     = Advanced Micro Devices
CL_PLATFORM_EXTENSIONS = 

CL_DEVICE_TYPE = 2
CL_DEVICE_VENDOR_ID = 4098
CL_DEVICE_MAX_COMPUTE_UNITS = 8
CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS = 3
CL_DEVICE_MAX_WORK_ITEM_SIZES = 1024 1024 1024
CL_DEVICE_MAX_WORK_GROUP_SIZE = 1024
CL_DEVICE_EXECUTION_CAPABILITIES = 1

Core i7 の結果です。
CL_DEVICE_TYPE の 2 は CPU (CL_DEVICE_TYPE_CPU) を表しています。
CL_DEVICE_MAX_COMPUTE_UNITS は 8個。
Core2 Duo で走らせると CL_DEVICE_MAX_COMPUTE_UNITS = 2 となります。

Device Type は下記の通り 3種類定義されています。

2 CL_DEVICE_TYPE_CPU
4 CL_DEVICE_TYPE_GPU
8 CL_DEVICE_TYPE_ACCELERATOR

Compute Shader は GPU 上で走るプログラムを共通化するのが目的でした。
OpenCL は CPU/GPU やその他を含めた、より幅広いプロセッサを対象として
作られているようです。

Direct3D の Compute Shader も CPU でエミュレーションできれば同じですが
現状だと WARP (10.1) も対応しておらず、Reference でしか動作しません。
エミュレーションできても GPU, CPU 混在しての利用は想定されていないといって
良いでしょう。

CL_DEVICE_EXECUTION_CAPABILITIES は CL_EXEC_KERNEL のみセットされています。
CL_EXEC_NATIVE_KERNEL が無いので、clEnqueueNativeKernel()
は実行出来ないようです。

バッファの転送や実行は Command Queue を生成して非同期に監視します。
GPU の描画操作に似ています。
異なるのは Out of order で実行可能なこと。
そのままでは実行順の保証が出来ませんが、その代わり各コマンドに依存関係を
設定できます。特定のコマンドの完了を待ってから実行できるわけです。

Direct3D11 でも DeviceContext が分離され、Command List (Queue) に
蓄えられる GPU 命令と、そうでないものを区別できるようになっています。
ただこちらは、複数のスレッドで作成したコマンドを単一のコンテキストで実行する
ための仕組みです。コマンドバッファ内の実行順は決まっているため、
スケジューリングは呼び出す側に委ねられています。

OpenCL の kernel の記述言語は glsl とは別もので、より C言語に近いものです。
long は 64bit。vector も 16個まで扱えるようです。
4コンポーネントを超えた場合、各要素は16進数指定で s0, s1,～ sf といった表記
になっています。

D3D の Compute Shader はデバイスやリソース管理等を D3D のコンポーネントに
委ねています。Direct3D の一部であって言語も hlsl そのまま同じものでした。

OpenCL の場合完全に独立しており、リソース管理も言語も OpenCL の世界で作られています。
コマンドをいくつか拡張してレンダリング向け補助機能を追加すれば、新しい
3D API セットができるのではないかと思うくらい。
その分 ATI CAL とか、独自 SDK と比べると複雑になった印象を受けるかもしれません。
リソースは描画と共有可能で、D3D や OpenGL からも OpenCL のバッファを作成
出来るようになっています。

const int THREAD_SIZE= 32;
cl_int	  status= 0;
cl_uint	  nums;
cl_platform_id	pid= 0;
cl_device_id	device= 0;

status= clGetPlatformIDs( 1, &pid, &nums );
status= clGetDeviceIDs( pid, CL_DEVICE_TYPE_CPU, 1, &device, &nums );

cl_context  context= clCreateContextFromType( NULL, CL_DEVICE_TYPE_CPU, NULL, NULL, &status );
cl_command_queue   command= clCreateCommandQueue( context, device, CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE, &status );

cl_mem	mem= clCreateBuffer( context, CL_MEM_READ_WRITE, THREAD_SIZE * sizeof(cl_float), NULL, &status );

const char*   src=
    "__kernel void main( __global float* op )\n"
    "{\n"
    "   unsigned int   tid= get_global_id(0);\n"
    "   op[tid]= tid * tid;\n"
    "}";
size_t	srcsize= strlen( src );
cl_program  prog= clCreateProgramWithSource( context, 1, &src, &srcsize, &status );

status= clBuildProgram( prog, 0, NULL, NULL, NULL, NULL );

cl_kernel  kernel= clCreateKernel( prog, "main", &status );

status= clSetKernelArg( kernel, 0, sizeof(cl_mem), &mem );

size_t	gthread= THREAD_SIZE;
size_t	lthread= 1;
cl_event   event;
status= clEnqueueNDRangeKernel( command, kernel, 1, NULL, >hread,