A Relational Debugging Engine for the Graphics Pipeline

by syoyo

A Relational Debugging Engine for the Graphics
Pipeline
to appear, SIGGRAPH 2005
http://duca.acm.jhu.edu/research.php

今年の SIGGRAPH 2005 採択論文。グラフィックスパイプライン(つまりは CG の描画、ひいては GPU)、

に対するデバッグ手法の提案です。なかなかあるようであまり提案のなかった分野です。

デバッグ手法には、クエリベース(SQL)のデータベース的な方法論を用いています。 

たとえば論文での例を挙げると、

SELECT normal:37 FROM SFrags
WHERE dot(normal:37, (0,0,1)) < 0

という操作で、フラグメントシェーダの 37 行目において、
法線とベクトル (0, 0, 1) との内積がゼロより小さいものを選択、ということができます。

lucille を開発するときも、”良い” デバッグのしかたにはいつも悩まされました。

CPU のデバッグとは違い、レンダリング処理は必ずしもシーケンシャルにコードの
実行が行われることはありません。
たとえばあるピクセルだけでさらなるレイトレの処理が
トリガーされたり、ある領域のピクセルで、ある法線方向だけ向いてる部分の情報を
調べたいなどという要求は常にあります。

本質的に GPU のデバッグは並列プログラムのデバッグということになるかと思います。

CPU における並列プログラムのデバッグ方法はそれなりに確立しつつあるようですが、
グラフィックスパイプラインのデバッグというのは、よくて頂点シェーダとフラグメントシェーダの
パフォーマンスや帯域程度しか調べられなかったのではないでしょうか。

グラフィックスパイプラインでは、ラスタライザには 3 頂点が渡され、これが 1 つの
ポリゴンの情報となり、ポリゴンがラスタライズされて膨大な数のフラグメント(ピクセル)
が生成されます。このようなデータの流れからして、すでに複雑な並列度を
持っており、通常の CPU における並列プログラムのデバッグ方法をそのまま適用するのが
難しいと思います。

Mac OS X では、OpenGL の関数にブレークポイントを仕掛けたり、実際に OpenGL の
関数にどの値が渡されたか(たとえば引数が変数になっている場合がこれに相当)、
などを調べることができますが、たとえばある位置 (x, y) の法線の値などを
調べたりはできません(そういうフラグメントシェーダを書くという手もある)。

本論文では、OpenGL の API にフックをかけて、
グラフィックスステートのストリームを取り出す仕組みになっています。
このため、ユーザから見ると、再コンパイルすることなくアプリケーションを
デバッグすることが可能になっています。

このような背景において、本論文のデバッグ手法の提案は、これからの
シェーダリッチな GPU の利用用途においてきわめて有益であると思います。
(問題はデバッグすべきデータのストリームが膨大になりそうなので、
それの対処をどうするかになるか、でしょうか)

 

Advertisements