ちょっと最近,HLSLとCg,GLSLの３つのシェーダ言語を使ってマルチプラットフォームで開発することについて色々と考えていたり調べたりしていたのですが,Unityの技術blogにUnityのマルチプラットフォームでのシェーダの扱いに関しての興味深い記事がありました.
Shader Compilation for Multiple Platforms
http://blogs.unity3d.com/2010/10/20/shader-compilation-for-multiple-platforms/
Unityではモバイルプラットフォーム(iOSデバイスやAndroid)をサポートするまではCg/HLSLでシェーダを記述するのが基本みたいで、オプションの設定をすればGLSLが書けるということだったみたいです.
ただ,これだとマルチプラットフォームで動かす場合,特にOpenGL ES 2.0では動かせないので,かつてATIが公開していたオープンソースツールのHLSL2GLSLをフォークさせて新たなツールを作って自動トランスコードをやったみたいですね（名前が微妙なのは認めてるようだ）.
ちなみに,hlsl2glslforkを使う際の注意点ですが,HLSLやCgのコードに#includeやプリプロセッサが使われているとうまくトランスコードすることができないのでそういうのは１つのファイルに展開する必要があります.このあたりはトランスコードの前準備のためのツールとか欲しいですね.
hlsl2glslforkプロジェクト
http://code.google.com/p/hlsl2glslfork/
これで解決…と思ったらこのhlsl2glslforkでモバイル向けにGLSLを出力した場合,最適化がうまくいっていないようで,実際に出来上がるコードは激遅なようですね.そこでその問題を解決するために色々と調査したところMesa3Dで開発しているGLSLコンパイラがなかなかいい感じだったみたいで,そこからglsl-optimizerというのを作ったみたいですね.これでパフォーマンスの問題はかなり改善したようですね.
glsl-optimizer
https://github.com/aras-p/glsl-optimizer
このblogは2010年の10月の記事ですが,この段階では次のステップとしてOpenGL ES 2.0のシェーダにある精度まわり（lowp/mediump/highp）のトランスコードもうまくやりたいようですね.Cgなんかだとhalf型なんかがあって,half型を使うとサイクル数が減少する環境もあるのでそうしたものを考慮するってことなんでしょうね.
昔はシェーダはHLSLやCgでだいたい用事が住んでいたのですが,コレにぜんぜん違う構文のGLSLが加わってくると色々とシェーダの使い回しや記述、管理に頭を悩ませることが増えると思うのですが自動トランスコードと自動最適化でGLSLは人間が書かないという発想はいいかもしれませんね.