トップ > DirectX

Secure coding は Microsoft からイノベーションを奪っているか？

Vista .NET XNA DirectX

Re: WPFでHLSLが使えることの持つ意味

id:tetsutalow せんせーのところより．

CPUの性能が伸びなくなってしまった今、GPUは当面の伸びしろとして期待されているわけですから、この動き自体は自然でしょう。ですが、一般的に言って、ネット越しに落ちてくるコードが高い計算能力を持つことは、それだけで凶器になり得ます。SilverlightのSandboxの細かい仕様をまだちゃんと調べていないので詳しいことは言えませんが、私の頭の中にはいくつかの、この技術を凶器として使うシナリオがあるので、その実現可能性をちゃんと調べないといけないなぁと思っています。そのことを忘れないうちにここに書いておきます・・・・他の専門家の方も、もしよろしければご検討願えませんか。

あー
Silverlight だとまだ当面 Shader は使えないんじゃないでしょうかね．というか Silverlight と WPF を比べると，Silverlight は VM (CLR) もサブセットなら描画エンジン (WPF) もサブセットなことを先に書いた方がよいのか．今 (Silverlight 1.0) も次 (Silverlight 2.0) も，2D 描画を含めて GPU を全然使っていない，つまり完全ソフトウェア描画な状況です．

Windows® Presentation Foundation (WPF) は XAML で 3D をサポートできますが、Silverlight は既定では 2D しかサポートしません。これは、マシン内にどのようなグラフィック プロセッサ ユニット (GPU) ハードウェアが含まれているかを気にしなくて済む方が、ブラウザ間の互換性をずっと簡単に実現できるからです。もちろん、突き詰めて考えれば、コンピュータ画面上の 3D は目の錯覚にすぎません。どのような操作が行われているにしろ、結局、モニタ画面に表示されているのは通常の 2D 多角形の集まりです。独自のコードで 3D 操作を実行してこれらの多角形の座標を計算する手間をかけるならば、ハードウェア アクセラレータを使用しない 3D レンダリングも可能です。数十個のポリゴンに限定すれば、パフォーマンスも許容範囲内です (主観的には、フレームのパフォーマンスは Alpha から Beta への移行により向上しています)。

この記述では普及の問題が理由に挙げられていますが (Silverlight のポジションを考えればこれは非常に説得力がある)，セキュリティリスク (もちろんこれは GPU サポートを後押ししない) の考慮がなかったかというとそうでもないんじゃないかなぁと．

DirectX Filter

少なくとも今現在，開発部門がブラウザアドインで GPU や DirectX に依存させるコンポーネントをリリースしたいと考えたとしても，それに反対する部門なり視点は確実に Microsoft 社内にあるはずです．
たとえば以前の Internet Explorer には，DirectX Filter という仕組みがありましたが，これが Internet Explorer 7 で取り除かれた話でも．
DirectX Filter は DirectShow 派生技術です．DirectShow には Filter と呼ばれる reconfigurable なコンポーネントの仕組みがあります．そして画像に対するフィルタは，ピクセル配列を受け取ってピクセル配列を返す関数とみなすことができます．「なんだこれってブラウザが扱っている画像の変換に使えるじゃん，It's Generative Programming!」てな感じで導入されたのがいつだっけ？ Internet Explorer 4 で Visual Filter が入って Internet Explorer 5.5 で DirectX Filter に拡張だったかな．まあそんな時代の，いかにも Microsoft らしい社内技術シナジーでした．
ただまあやっぱり CVE-2006-2383 のような問題は起きてますし (探せば他にもありそうな) ，案の定というか Internet Explorer 7 では取り除かれてましたとさ．これも取り除かれた直接の原因がセキュリティだったかどうかわかりませんが*1，その切り口から関係者に聞いてみると色々情報が出てくるんじゃないでしょうかね．

セキュリティの理由で取り除かれるコンポーネントたち

Windows Vista では，「Secure coding な時代以前に設計・開発された」という理由で取り除かれているコンポーネントがいくつかあります．私が情報に触れる機会の多い DirectX 系では，

が Vista から取り除かれています*2．

セキュリティの理由で DLL 化されるライブラリたち

他にも，セキュリティ上の理由という形で静的リンクから DLL 配布へ舵が切られ，アプリケーションの配布が困難になりつつあるという状況もあります．

  • Visual C++ の CRT (これは静的リンク版もまだ存在はしている)
  • D3DX (完全に DLL オンリーになってしまった)

これらについては，開発者サイドからは静的リンクを望む声が強いのですが，「セキュリティ上の理由」を盾に DLL 化が推し進められています．

Secure coding は楽しいか？

これは私が開発部門の人と話していて断片的に感じたことなので，その内容からだけで判断するのはかなり危険ですが，どうも今の Microsoft の製品開発スタイルというのは，セキュリティを非常に重視し，規約やツールでがちがちに縛られているという印象を受けます．いや良いことなんでしょうけど．ただ何というか，今ひとつ「発想と直感を信じて勢いに任せた製品開発」という雰囲気が伝わってこないんですな．
なので例えば，開発部門の人が国内イベントに来ていたら，「CodePlex や MSDN Gallery，MSDN Blogs に載せるコードと，製品リポジトリにチェックインするコード，どっちが書いてて楽しいですか」みたいな質問で探りを入れてみたりすると色々面白い話が聞けるんじゃないでしょうか．

Secure coding は Microsoft からイノベーションを奪っているか？

確かに最近の Microsoft の製品は，昔に比べると大変セキュアになったと思います．製品設計時から開発・テストに至るまで，セキュリティを最優先した成果でしょう．その反面で，最近の Microsoft の製品からは，たとえばデスクトップをブラウザで置き換えようとか，そういった奇抜な製品が減ってきてしまっているのではないでしょうか．
実際，id:tetsutalow せんせーが懸念されているように，Flash Player 10 はまさに GPU をサポートするのですな*3．でも Microsoft がそれをやるとリスクが懸念されて，Adobe ならまあ Adobe だしですんでしまう．何かそう空気をみんなで読みあっているところがあんのかなと (Air が出てきた！)．

Microsoft は Singularity に何を夢見るのか？

昨年某所で mkusunok さんが Singularity の紹介をされていて，そのときに「製品開発でセキュリティにかけているコストを下げたいという目的がある」と言われていたのが印象に残っています．というかそのときはぴんと来なかったのですが，その後 1 年ぐらいの会話の中で何となく分かってきた気がします．
もちろん，「セキュリティコストの低減」が Singularity チームの真意かどうかは分かりません．研究開発プロジェクトでは思い付く限りの応用は言っておくものでしょうから．ただ，実際問題として，開発プロセスでセキュリティにかけているコストを簡素化できるというのは，自己場が無視できないような巨大企業に所属しているプログラマたちにとって，本当に切実なところまで来ていたりするのかな，と思うところはあります．
XNA にしても，XNA チームのがんばりのおかげで，我々はコードは「みなしセキュアー」という扱いを得ることができて (サンドボックスが防いでくれる部分に関してはレビュー不要)，コードレビューもなしにゲームを投稿できているわけです．これって本当はすごいことなのかもしれませんね．
「お前らとりあえず作ってて面白いと思ったコードに専念して良いよ」と．
(2008年7月31日追記)
現在およびこれまでにリリースされてきた XNA 実装に関して補足．
Xbox 360 上で実行する XNA ゲームの安全性は，XNA ゲームをユーザモードに隔離することで得られています．XNA CLR はコードの検証可能性をチェックしておらず，XNA CLR 自体はサンドボックスとして実効性を持ちません．詳細な実行モードについては詳しくは下記資料参考のこと．


Writing Secure Code第2版〈上〉プログラマのためのセキュリティ対策テクニック (マイクロソフト公式解説書)

Writing Secure Code第2版〈上〉プログラマのためのセキュリティ対策テクニック (マイクロソフト公式解説書)

  • 作者: マイケルハワード,デイビッドルブラン,Michael Howard,David LeBlanc,トップスタジオ
  • 出版社/メーカー: 日経BPソフトプレス
  • 発売日: 2004/12
  • メディア: 単行本
  • 購入: 2人 クリック: 10回
  • この商品を含むブログ (21件) を見る

Writing Secure Code第2版〈下〉プログラマのためのセキュリティ対策テクニック

Writing Secure Code第2版〈下〉プログラマのためのセキュリティ対策テクニック

  • 作者: マイケルハワード,デイビッドルブラン,Michael Howard,David LeBlanc,トップスタジオ
  • 出版社/メーカー: 日経BPソフトプレス
  • 発売日: 2004/12
  • メディア: 単行本
  • 購入: 2人 クリック: 14回
  • この商品を含むブログ (14件) を見る

*1:まあ残しておいてそれほど面白い機能だったとも思えませんけど

*2:さらに Windows 7 ではアレも取り除かれる方向で検討中とか

*3:Flash Player 10 の GPU サポートについては，『[http://weblogs.macromedia.com/akamijo/archives/2008/05/flash_player_10_1.html:title=Flash Player 10 の GPU サポート機能について - akihiro kamijo]』に詳しいです．

WPF に HLSL がやってくる

.NET DirectX Vista

WPF Performance Improvements

.NET 3.5 SP1 includes several significant performance optimizations and improvements to WPF. Some of the specific graphics improvements include:

  • Smoother animations
  • Hardware accelerated rendering of Blur and DropShadow Bitmap Effects
  • Text Rendering speed improvements - especially with VisualBrish and 3D scenes
  • 2D graphics improvements - especially with z-index scenarios
  • A new WriteableBitmap class that enables real-time and tear-free bitmap updates. This enables custom "paint"-style applications, data visualizations, charts and graphs that optionally bypass the default WPF 2D graphics APIs.
  • Layered window performance improvements

SP1 also adds support for better data scalability in WPF. The ListView, ListBox and TreeView controls now support "item container recycling" and "virtualization" support which allows you to easily achieve a 40% performance improvement with scrolling scenarios. These controls also now optionally support a "deferred scrolling" feature which allows you to avoid scrolling in real time and instead wait until a user releases the scroll thumb (the default scrolling mode in Outlook). This can be useful when scrolling over very large data sets quickly.

やっと「GPU の機能を活用」とか言えるようになってきた！ 今までの WPF って VRAM が大きいだけの Direct3D RM だったのは公然の秘密だよね！

WPF Extensible Shader Effects

.NET 3.5 SP1 adds support in WPF for a new shader effects architecture and API that allows extremely expressive visual effects to be created and applied to any control or element within WPF. These shader effects support blending multiple input compositions together. What makes them particularly powerful is that WPF executes effects (including custom effects you build yourself) using the GPU - giving you fully hardware accelerated graphics performance. Like almost everything in WPF, you can also use WPF databinding and animation on the properties of an effect (allowing them to be fully integrated into an experience).

HLSL で拡張可能！
HLSL は良い言語だよ！*1 コンパイル時に階乗計算とかできちゃうし！ 属性使った宣言型プログラミングもできちゃうもんね！ (でも WPF であのすばらしい D3DX Effect System と相互運用できるのかまだちゃんと調べてない) Reactive Programming と Shader はきっとおもしろいよ！マンデルブロ集合も計算できちゃう！
続きは『A Series on GPU-based Effects for WPF - Greg Schechter's Blog』で！
WPF 向け Shader 本のチャンス！ (主に今給黎さん？)

WPF Interoperability with Direct3D

.NET 3.5 SP1 adds support to efficiently integrate Direct3D directly into WPF. This gives you more direct access to the hardware and to take full advantage of the Direct3D API within WPF applications. You will be able to treat Direct3D content just like an image within an application, as well as use Direct3D content as textures on WPF controls.

For example, below are three samples from the Direct3D SDK:

We could either load them in as image surfaces within a WPF application, or map them as textures on WPF controls.  Below is an example of mapping them as textures onto cubes in a WPF 3D application:

Note: the Direct3D integration isn't today's SP1 beta release.  It will appear in the final SP1 release.

そして極めつけ． Direct3D WPF 登場時からずっと期待され続けてきていたことがついに実現．
ハードウェア環境もようやく普及期に入った感じですし，いよいよですね．Democratizing the GPU!

追記

川西さんのところにも簡単な紹介が．

頂点シェーダは使えないっぽい(でもまあ Direct3D サーフェイス流し込めるならなんとでも)．
あと，Channel 9 のこのムービーも面白いっぽい．

http://mschnlnine.wmod.llnwd.net/a1809/d1/ch9/0/WPF35SP1Graphics_s_ch9.wmv

*1:そういえば HLSL の出自についておもしろい話を MVP Summit かどこかで聞いたような．あれはひげねこさん経由とかだったかなぁ？

DirectX SDK November 2007, CustomUI.cpp は未修正

DirectX

DirectX SDK November 2007
ダウンロードセンターに上がっていたので見てみました．
CEDEC 2007 でお伝えしたとおり，August 2007 バージョンの CustomUI.cpp は，IMM32 API 使用時の漢字変換で候補ウィンドウの非表示化に失敗するのですが，この問題は November 2007 版でも修正はされてないようです．というわけでおすすめは依然 June 2007 と．
また，masafumi さんも書かれてますが，今回の SDK が Visual Studio 2003 をサポートする最後のリリースになるようです．次回 March 2008 版は，Visual Studio 2008 のサポートが追加され，Visual Studio 2003 のサポートが終わるとのことです．
さらに，今回のリリースでは，以下のコンポーネントが SDK から取り除かれました．これらの開発を行うには，August 2007 SDK のファイルを使用する必要がありそうです．

  • Direct3D8 and all of the earlier versions
  • Direct3D RM
  • DirectAnimation
  • DirectMusic
  • DirectInput7 and all of the earlier versions
  • DirectPlay
  • DirectPlayVoice
  • DirectX8-era HRESULT conversion routines
  • Managed DirectX samples and documentation

D3D9 as a 2D drawing foundation

DirectX

6uNで導入された機能のなかでも特にWindowsプラットフォームでの性能向上が見込めるものがDirect3DベースのJava2Dパイプライン機能だ。これはWindowsプラットフォームでデフォルトで有効になる機能で、ハードウェアがPixel Shaders 2.0の必要最小限の機能をサポートしている場合に、Swingコンポーネントにおける透過処理、傾き処理、任意の変換、そのほか2D描画機能に対してハードウェアアクセラレーション機能が活用される。

時間ができたら PIX for Windows で眺めてみたいんですが，中々時間が……ってソースを読めばよいのかな？


ちなみに Direct3D による 2D アクセラレーションというのは誤解されやすいので気をつけたいところ．
内部では (多分) こんな順序で描画しています．

  1. 適当な描画単位 (パーツ) ごとにメインメモリ上に CPU 描画
  2. パーツごとにテクスチャにキャッシュ
  3. バックバッファの上に DrawPrimitive でパーツを合成していく (アフィン変換, アルファ合成，PixelShader によるエフェクト)

とまあ結局転送元画像はソフトウェアレンダラで描くのが一般的です．この辺の事情を見ても，Windows Vista での GDI 完全ソフトウェア化はいいタイミングだったと思います．結局単独の図形を低レイテンシで作るのであればソフトウェアレンダラがベストというのが昨今の Windows の 2D 描画事情です．
最近 Direct3D による 2D アクセラレーションなんて言っているグループが，どこもそれなりに体力と歴史のあるグループというのは，偶然ではありません．まず CPU によるベクタベース 2D レンダラを完成させて，次に VRAM へのキャッシュと DrawPrimitive 時の自由度による高速化を目指す必要があるわけで，その域に達するのは割と大変です．
WPF にしても 4〜5 年ぐらいコードをいじっていたんじゃないでしょうか？ その WPF もソフトウェア描画で GDI+ のコードベースをかなりを流用しているそうですし*1，GDI+ まで遡れば 10 年近く続く一連のプロジェクトと言えるかもしれません．


しかしなんだかんだで Shader Model 2.0 という区切りは相当長生きしそうですね．Pixel Shader 2.0 対応のハードウェアの初出が 2002 年末から 2003 年頭にかけてなので*2，登場から既に 5 年経っている訳ですが，今ちょうどソフトウェアがその辺で線引きにかかっていると．
API セットは当面これで十分で，後は VRAM 容量がいい感じにスケールしていけばいいというのであれば，あと 5 年たってもそれなりに Direct3D9 は現役かもしれませんね．

関連過去記事

*1:[http://blogs.msdn.com/timothyc/archive/2006/06/16/634638.aspx:title=WPF Graphics Performance Q & A - Q: Adding seemingly simple tweaks (e.g., clipping, bitmap effects) to our scene causes us to fall back to software, and software rending in WPF is slower than GDI+ software rendering.]

*2:[http://dench.flatlib.jp/dxlist.html:title=DirectXの歴史]

コピペの件

Vista DirectX

セッションではちらっとしか言いませんでしたが，この SDK のバグ自体，Microsoft の中の人がサンプルを作るときにコードの切り貼りで作ったっぽいバグです．

case WM_IME_SETCONTEXT:
    DXUTTRACE( L"WM_IME_SETCONTEXT\n" );
    //
    // We don't want anything to display, so we have to clear this
    //
    lParam = 0;
    return false;


DXUT のサンプルコードに，IME についてとても詳しい人が関わっているのは間違いないです．日本語 IME だけでなく，中国語の IME や韓国語の IME 固有の処理も念入りに書かれていて，特に中国語 IME の古いバージョンへの対応の執念などはすさまじいものがあります．
それだけに，こんな単純なミスがあるというのはどうも腑に落ちないんですね．
むしろ誰か別の人が移植中に，あるいは本人がリファクタリング中に (まるまるコピペではなく) 切り貼りコピペでこのバグを入れてしまったと考えると考えた方がしっくりくるというわけです．つまり，元々正しく動いていたコードから，以下の部分だけをまずコピペし，

case WM_IME_SETCONTEXT:
    DXUTTRACE( L"WM_IME_SETCONTEXT\n" );
    //
    // We don't want anything to display, so we have to clear this
    //
    lParam = 0;

次に，DefWindowProc に渡さないとねーと return false を書き足します．
そして Windows XP で動作確認すると“無事に”動いているのでああ問題ないなと思うわけです．
とまあ Microsoft か DXUT の作者が 10 年単位で枯らされた IME 対応コード資産を持っていて，それをぺたぺた切り貼りしながらフレームワークを IME 対応させたのだとしたら，今回のようなバグはあってもおかしくないよなぁと．まあ推測ですけどね．
って，そいういえば DXUT は元々外部で作られていたサンプルフレームワークを Microsoft が取り込んだとかそういうの話もちらっと聞いたような憶えが．もうちょっと調べてみるか……

CEDEC 2007

DirectX Vista

『R23 Windows Vistaゲーム開発』無事終わりました．お越しいただいた皆様，ありがとうございました．

フォローアップ 1

最後に D3DX ランタイム有無の起動時チェックの質問をいただいて，「最近の DXUT サンプルは D3DX の遅延ロードを使っているようなので，もしかしたら何か対策を取っているかも？」という回答をしましたが，あのあと少し調べてみました．
結論から言えば，最近のサンプルでも，昔 CodeZine に記事を書いた 時とほとんど変わっていませんでした．DLL が見つからなければ，見慣れたダイアログが表示されるかと思います．
セッションでも紹介した DirectX SDK August 2007 の CustomUI のソースを追いかけてみましたが，グローバル変数のコンストラクタ内で D3DX の関数を呼び出してしまっているので，D3DX DLL の遅延ロードを指定しても WinMain 以前に d3dx9_35.dll がロードされるという結果になります．例えばCustomUI.cpp の先頭部分．

CModelViewerCamera      g_Camera;

そして DXUTcamera.cpp より．

//--------------------------------------------------------------------------------------
// Constructor 
//--------------------------------------------------------------------------------------
CModelViewerCamera::CModelViewerCamera()
{
    D3DXMatrixIdentity( &m_mWorld );

遅延ロードの ヘルパ関数 を上書きすると WinMain 以前であっても DLL 遅延ロードをフックできるのですが，CRT の初期化フェイズにあるためあんまり無茶なことはやらない方が良いような気がします．
グローバル変数のコンストラクタで D3DX を使うような場面では，素直に exe を 2 つ作って多段階の起動にするのがベターでしょう．

フォローアップ 2

実は時間があったら IMM32 の解説も考えていたのですが，そこまで必要そうな雰囲気でもなかったのでばっさりカットした部分があります．
んでその発表資料が手元に残っているわけですが，とりあえず置いておきます．誰の役にも立たなさそうですが，むしろ自分でそのうち使うかもしれないので，みたいな．

Gamefest Japan 2007, Runtime Library

DirectX XNA

Gamefest Japan 2007，申し込んでたのに忙しくて行けませんでした……
でまああちこちの報告を見ながら「ええのぅ」と思ってるわけですが……ちょっと気になる点もいくつか．(追記) →修正されたようです．

Xbox LIVE アーケードでリリースされたタイトルはマーケットプレースから購入しただけで即プレイ可能だが、そうではないアマチュアが作成したXNA GSベースで開発したゲームをプレイするのがかなり面倒であることが改善されていない。

まず、PCが必要で、そのPCにC#環境とXNA環境をインストールして、初めてネット等からダウンロードしたゲームが実行可能になる。ゲームがどんなにカジュアルでわかりやすい内容であっても、ゲームが遊べるようになるまでのプロセスがヘビーなのだ。ランタイムが再配布できれば、Windows環境下で一発単体実行というのも可能なのだが。

西川さん，もしかして XNA Framework の再配布ファイルが公開されていることに気づいてない？ (追記)現在記事は修正されて再配布ファイルにリンクが張られています．

ということはその辺の話は全然なかったのかなー
ついでに思い出したんですが，開発者に D3DX 等の DLL を起動時チェックを実装するよう，いい加減 Microsoft から働きかけて欲しいような．Gamefest みたいなイベントは良い機会だと思うんですけどねぇ．

ブートストラップを工夫するなり DLL の遅延ロードなりでこのエラーを潰しておかないと，このダイアログを読んでユーザーが意味を理解できるわけないでしょうと．Raymond Chen も同じことを言うと思います．

過去のエントリ