携帯電話のイヤホンマイク端子

W-ZERO3[es]もそうですが、最近の携帯電話についているイヤホンマイク端子は
ほとんど平型です。以前はイヤホンマイクといえばミニミニジャックの丸型で、
たしか昔使ってた J-PHONE の J-SH51 も丸型でした。

平型端子には通常ステレオヘッドホンやらマイクつきのモノラルイヤホンが
つながります。だけど SHARP の携帯ではそれ以外にもさまざまな周辺機器が
ここ につながります。

例えば V905SH は

・アナログ変換ケーブル
・マイクつきイヤホン
・光デジタル変換ケーブル
・マイク付き液晶オーディオリモコン
・ビデオ力ケーブル
・TVアンテナ付きステレオイヤホンマイク

などのオプションがあるようです。
機能だけまとめてみると

・ステレオ音声出力
・ビデオ出力
・マイク入力
・音声入力
・デジタル音声入力
・液晶リモコン用信号
・TVアンテナ

…このコネクタは一体何なのだろうか。と思って少しだけ調べてみました。
「JEITA(EIAJ) RC-5240 携帯電話用角型コネクタ」という名前らしいです。

こちらの
通信用語の基礎知識 RC-5240 にピンアサインが載っています。

やはりステレオ音声出力とマイク端子しかないので、それ以外の信号は結局
SHARP 独自仕様なのかもしれません。

続 GeForce8800GTX と SM4.0 の整数演算

D3D10 でなくても OpenGL の NVIDIA 拡張ならできるということをすっかり忘れて
いました。
http://developer.nvidia.com/object/nvidia_opengl_specs.html

しかも CUDA という新しい GPU 向けプログラミングキットまで出ています。
一般的な C言語を使って GPU 向けプログラムが書けて、演算用のストリーム
プロセッサとして活用できるようです。マルチコア CPU でもせいぜい数個のスレッド
が走る程度ですが、CUDA では数千というスレッドが可能とのこと。
http://developer.nvidia.com/object/cuda.html

描画向けパイプラインを流用して演算させる手間が要らず、ハードにあわせた専用の
シェーディング言語を用いなくても良いわけです。ShaderModel4.0 の仕様になって
非常に汎用性が高く、一般の計算用途に活用できる構造になりました。
CUDA はさらにその先を行ってるわけです。

あらためて仕様を見てみると、D3D10 の ShaderModel4.0 HLSL でも演算可能な
32bit int の整数型が追加されています。整数型が追加されたことで、bit 演算や
シフト演算子も使えるようになっています。

D3D10 ではアセンブラによるシェーダープログラミングはなくなっており HLSL のみ
のサポートです。マニュアルにもアセンブラについては書かれていません。

その代わり上記リンクにある資料から OpenGL の NVIDIA 拡張命令で 4.0 相当の
アセンブラ命令を見ることができます。これまで存在しなかった AND, OR, XOR,
NOT, SHL, SHR, I2F, PK/UP~ の整数系命令が並んでいることがわかります。

int 型整数の乗算は 32bit 分の演算が必要なので、浮動小数点演算よりも負担が
高くなります。整数乗算の制度を 24bit に制限するオプションがあり、これで
浮動少数点相当の演算コストで高速に乗算できるようになっています。

また整数乗算では 64bit 相当の演算を行った後、上位 32bit のみ受け取ることも
できます。上位と下位を同時に受け取れないので結果を 64bit で受け取りたい場合
は乗算が 2命令必要になります。

比較は結果をレジスタに bool 値で代入できる専用の命令もありますが、演算や
代入と同時に結果をフラグに反映させることができます。これも汎用 CPU と同じ
ように、zero, carry, overflow, sign の4つの flag が揃っています。

フラグの更新と参照は依存関係を持つためパイプラインストールに原因になりがち
です。これを CC0 と CC1 の2セットのフラグレジスタを使い分けることで回避
しているようです。

VertexShader → GeometryShader はそのまま直接値を渡すことができますが、
VertexShader/GeometryShader → PixelShader の場合は間にラスタライザが介入
します。この場合の補間は float で行われます。補間を行わない場合は任意の型で
渡すことができるようです。

W-ZERO3[es] USBキーボード活用

USB外付けキーボード利用時の便利な操作をまとめたメモです。
ELECOM TK-UP84CP にて確認しています。

■一般操作

[ALT]+[半/全 漢字]
  IME ON/OFF

[F1]
  ソフトキー1 (左-)

[F2]
  ソフトキー2 (右-)

[Win]+[F6]
  (OK)ボタン相当

[Win]キー
  スタートメニュー

[ALT]+[カタ/ひら/ローマ字]
  ローマ字入力、JISかな入力の切り替え(MS-IMEのみ、ATOK不可)

[SHIFT]+[CapsLock/英数]
  CAPS LOCK On/Off

■Today画面のみ

[F6]/[F7]
  ボリューム Up/Down

nVIDIA GeForce8800GTX 出ました!!

一日中、暇があれば GeForce8800 の記事ばかり眺めていました。
D3D10 世代、ShaderModel4.0 世代の GPU の発表です。
http://www.nvidia.com/page/geforce8.html

GeForce8800 はアーキテクチャ自体が完全に異なるフルモデルチェンジです。
nVIDIA の GPU はだいたい2世代ごとに完全に生まれ変わります。

NV3    RIVA128, RIVA128ZX
NV4    RIVA-TNT, RIVA-TNT2
NV10   GeForce256, GeForce2   hwT&L
NV20   GeForce3, GeForce4     SM1
NV30   GeForceFX5800         SM2
NV40(G70) GeForce6800, GeForce7800 SM3
G80    GeForce8800         SM4

失敗作(?)だった FX を除いて大幅なアーキテクチャの刷新と、マイナーバージョン
アップによる高速化を繰り返しています。なので 7800 を買っても機能的には 6800
とほとんど同じだけど、8800 は完全に違います。速度ではなく機能を求めるプログ
ラマ的には今が買いです。

アーキテクチャの改変時は、機能が大幅に増える代わりにあんまり速くなっていない
ことが多々ありました。新しい機能を使えばもちろんパフォーマンスというかできる
ことは比較にならないのですが、例えば DX7 未対応のアプリケーションでは
GeForce256 より TNT2 の方が高速でした。

しかし 8800 は、新しい Shader4.0 を使わなくても従来の 3.0 アプリケーション
でも 2倍の速度で動くらしい!! これで D3D10 のアプリケーションが走ったら、
一体どこまでできるのやら。本当はすぐにでもほしいんだけど、

もしかして Vista が出るまで D3D10 は待ち?
もしかして DirectX10 SDK のリリースまでおあずけ?
もしかして Vista 用の 88 対応ドライバがまだ?

全部揃うまでもうちょっと我慢がいるみたいです

CLI(4) シェーダーのバイトコード

http://ch09144.kitaguni.tv/e310975.html の続き
GPU でもプログラミング言語が走るようになって怒涛の勢いで進化しています。
ですが、PC でいう x86 や組み込み機器でいう ARM やゲームコンソールでいう
PowerPC のようにバイナリレベルで何らかの共通化が行われているわけではありません。
(もちろん ARM や PowerPC は結果そうなっただけなのですが)

nVIDIA の GPU や ATI(AMD) の GPU では、ほぼ同じシェーダーの機能を使うことが
できるものの、内部のバイトコードは全く別物だと考えられます。

HLSL で書かれたシェーダープログラムは、vsa, psa, fxc や D3DX によって
Direct3D の仕様として決められた仮想 GPU のバイトコードに変換されます。

このバイトコードは D3D のアセンブラ命令とそのまま対応しており、D3D の仕様
そのものでもありました。

ビデオカードのドライバは、D3D のバイトコードを受け取ってから実行前にそれぞれ
のネイティブのバイトコードへ変換が行われます。

もしかしたらほとんど D3D の仕様とそのまま同一なのかもしれませんし、メーカー
ごとにもっと大胆な最適化が行われていて非常に異なったコードに変換されている
のかもしれません。

ですが HLSL のコンパイラは D3D の命令への変換だけ考えればよく、最適化もこの
共通コードに対して行われます。

この仕様のおかげでドライバは独自の最適化を行うことができて、かつ命令セット
アーキテクチャ ISA にとらわれずに機能の向上が図れるのだと考えられます。

そう考えると .NET Framework に搭載されている CLR はいわば、CPU のための
デバイスドライバなのかもしれません。

CLI という統一された仕様の MSIL のバイトコード上ですべての処理を考えておけ
ばよく、実際にプログラムが走るときはデバイスドライバが勝手にネイティブのコード
に最適化を行います。CPU 毎の差を吸収できるので、GPU のように ISA レベルの
互換性にとらわれずに性能の強化を図れる・・のかもしれません。