Cell Broadband Engine (Cell/B.E.) プロセッサーは、ゲームやネットワーク・データ処理に関わるアプリケーションが、流行のものとしてたくさんの注目を集めています。しかし間違いなく、この技術には他にももっと面白い使い方があるはずです。

この連載記事では、既製の PLAYSTATION 3 (PS3) に内蔵された Cell/B.E. プロセッサーを使って Linux ベースの実験装置、すなわち簡易オーディオ帯域スペクトラム・アナライザー兼ファンクション・ジェネレーターを構築します。

第 1 回の記事では、このプロジェクトの設計意図を説明し、ユーザー・インターフェース実装の詳細を掘り下げます。

準備

この記事で使用するハードウェアとソフトウェアの組み合わせは、Yellow Dog Linux 5.0 (YDL) を実行する 60GB の PS3 です。出力装置には標準 NTSC テレビを使い、標準的な USB キーボードとマウス、そしてGriffin iMic をシステムに接続します (周辺装置については後で詳しく説明します)。

この記事の内容はすべて、20GB の PS3 や他のほとんどすべての互換性のある Linux ディストリビューションにも適用できるはずです (記事の作成時点では、他のディストリビューションのうちで動作することがはっきりしているのは、PowerPC® 対応 Fedora Core 5 のみです)。YDL を選んだ理由は、最も楽な方法だからにすぎません。Terra Soft が PS3 用としてアセンブルおよび認定した YDL には、この開発プロセスと使用する予定のハードウェアを組み立てて実行するために必要なすべてのものが組み込まれています。

他の PowerPC Linux ディストリビューションのほうが使い慣れているというのであれば、遠慮なく使ってください。ただし、ここでははっきりと触れてはいませんが、追加のコンポーネントをダウンロードする必要が出てくるかもしれません。iMic を選んだ理由も PowerPC Linux で十分にサポートされることがわかっているからで、これについても同じくお望みの USB オーディオ入力装置に置き換えて構いませんが、ドライバーを見つけるのが読者の課題となります。ちなみに、PS3 ゲーム・コントローラーを購入する必要はありませんのでご注意を。Sony オペレーティング・システムは USB キーボードで操作できます (少なくとも、Linux をインストールするには USB キーボードで十分です。Linux のインストール後は、再度 GameOS を操作する必要は一切ありません)。

この記事に記載する製品へのリンクは、「参考文献」セクションを参照してください。サンプル・コードに従ってビルドとテストを行うつもりなら、まずは PS3 に Linux をインストールする方法が書かれている Jonathan Bartlett の記事を読み、その手順に従う必要があります (「参考文献」を参照)。この記事は比較的わかりやすく説明されていて、他の説明と比べても至って簡単に Linux のインストールを行えますが、DVD を挿入して「Go」をクリックすればいいというほどではありません。何らかの手引きは必ず必要になります。

PS3 にお金をかけたくないのであれば、ほとんどのコードは Cell シミュレーター内で作成できます。しかし、(おそらく .WAV ファイルを使用して) オーディオ入出力装置とグラフィカル・ディスプレイをシミュレートするフロントエンドを作成するのも厭わないというのでない限り、Cell シミュレーターでコードを作成してもあまり意味はないと思います。

上に戻る

論理的根拠

ここで、読者はこのようなアプリケーションで Cell/B.E. プロセッサーを使用する論理的根拠があるのだろうかという疑問を感じるかもしれません。最近ではたいていの場合、エンジニアが PC からテスト装置を制御し、取得したすべてのテスト・データをコンピューターに入力して Mathcad や Matlab などの分析ソフトウェアにインポートすることになります。計測機能がますます複雑になって PC 中心になるなか、最近の事実上すべてのスタンドアロン実験装置で一般的傾向となっているのが、組み込み PC を中心に構成し、カスタム化した機能をフロントエンドに組み込むことです。

例えばデジタル・オシロスコープで考えられるのは、かなり低価格のプロセッサーを組み込んで汎用オペレーティング・システムを実行させることです。このプロセッサーで、ユーザー・インターフェース、ネットワーク、大容量ストレージなどを処理し、高速 A/D コンバーター (ADC) と結合された 1 つ以上の DSP (デジタル・シグナル・プロセッサー) で信号の捕捉および前処理、トリガー生成などを実行します。

1 つにパッケージ化された機能

Cell/B.E. プロセッサーでは、ほとんどの機能を単一のチップにラップできます。基本アーキテクチャーにはすでに活発なメインプロセッサー (PPE) と DSP のような 8 個のコプロセッサー (SPE) が用意されています。さらに、別途ハードウェアを設計しなくても、このチップには DMA データをバイト・サイズごとに移動させるために必要なすべての構造基盤が組み込まれています。

全体的な意図としては、ソフトウェア開発者が、PPE を使って入力ストリームからのデータ・ブロックを SPE に集めるようにするということです。この SPE で実際の演算処理が行われ、データが出力装置に戻されます。

お馴染みのツール

ソフトウェア開発チームが、驚くほどなだらかな学習曲線で SPE プログラミング・インターフェースを一度理解してしまえば、早速、使い慣れたツールでシステム全体を開発できます。つまり、最終的な実験装置の特性を定義するのはほとんどすべてと言っていいほどソフトウェア次第です。特殊な用途の DSP ツール群や厄介な DMA アーキテクチャー、ASIC、それに FPGA プログラミングに関わる必要はまるでありません。

多少のカスタマイズ

Cell/B.E. ハードウェアを一から設計するのはもちろん簡単な話ではありませんが、実際に使える Cell/B.E. 参照設計から特殊なアプリケーションを開発するのであれば、ハードウェアに必要なカスタマイズは比較的少なくて済みます (装置の重要な属性のほとんどは、ソフトウェアに実装できるからです)。これが意味することは、重要な機能のアップグレードでも新しいハードウェアの開発や認証を行う必要なく、単なるソフトウェア更新としてエンド・ユーザーに販売できるということです。

このような Cell/B.E. プロセッサーの一連のメリットは大きな魅力となるはずです。近い将来、Cell/B.E. ベースのスペクトラム・アナライザーや波形シンセサイザー、それに基地局シミュレーターなどの複雑なテスト装置が登場したとしても当然のことでしょう。

上に戻る

例

この特定の例ではまず、知っておかなければならないこととして以下の事項について説明します。

• Linux の位置づけ
• ボックスの炎上を防ぐための注意
• ディスプレイへの対処
• テキストをレンダリングするためのコード

内部 Linux の位置づけ

PS3 を中心としてアプリケーションを構築する場合、PS3 のハードウェアおよびソフトウェア設計によってかなり厳しい制約を受けることになります。とりわけ厳しいのは、Sony ではハードウェアの大部分とは別のところにサンドボックス化した Linux が存在しているという点です。それに比べると、完全なカスタム設計、あるいは一般的な Cell/B.E. メインボードにデータ収集/出力ハードウェアが含まれるカスタム PCI Express カードを備えるだけでも、かなりの柔軟性があることになります。

ただし、この連載では iMic の適度な機能に合わせ、2 つの平行する (ステレオ) 44.1kHz 16 ビットのデータ・ストリームを操作することを目的とします。つまり、オーディオ帯域は 22.05kHz ということになります。

高温にご注意

作業を始める前の重要な注意事項として、PS3 ハードウェアは作業台上に置くのではなく、TV の上や娯楽施設に設置するように設計されています。そのためハードウェアが発する熱は、ファンによってブルーレイ・ドライブ近くの装置の端と背面から放出されます。

私は最初、開梱した装置をラップトップの隣にある作業台上で動作させたので、PS3 のファンの熱風がラップトップの排気口に吹き付ける形になり、最終的にはラップトップが熱によってシャットダウンする結果になってしまいました。このことから、PS3 は「垂直に立てて」実行するようにアドバイスします (PLAYSTATION 3 の文字の右側が上になるようにします。装置の底には、この設置方法を支えるための脚が付いています)。このように設置すると、動作温度が最も低くなるようです。

何千行ものコードに値する 1 つの画像

以上の注意事項を踏まえて Linux をインストールしたら、最初に取り組まなければならないタスクとしてディスプレイに対処します。PS3 の Linux インストールでのデフォルト・ディスプレイ構成は、どれだけ正確に Linux をインストールしたかによります。通常の NTSC または PAL TV のセットで実行する場合 (HDTV または VGA コンバーターをモニターに接続する代わりとして)、YDL のグラフィカル・インストール・モードは使えません。このモードでは、プログレッシブ・スキャン解像度のいずれかを設定しようとするからです。

そのため、デフォルトの Linux インストールでは X を使用しない TV 解像度の画面が設定されていますが、この動作は /etc/kboot.conf を編集することで変更できます。この連載の目的に従うには、RGB モードのいずれかで実行してください。NTSC ユーザーの場合は 480i、PAL/SECAM ユーザーの場合は 576i に設定します。どちらの設定にしても、フレームバッファー装置は画面サイズを 576x384 ピクセルとレポートします。これについては後で詳しく説明します。

ブート時の特定のフレームバッファー・ビデオ・モードは、ブートローダー kboot がカーネルに渡すパラメーターによって設定されています (このビデオ・モード設定はカーネルのパラメーターなので、ps3fb フレームバッファー装置がロードしてからでないと調べられません)。電源を入れた瞬間から ps3fb 装置が初期化を行う瞬間までのビデオ・モードは、Sony GameOS メニューでの設定に従います。デフォルトでは、PS3 を購入した地域に該当するインターレース方式の SDTV 解像度となります。kboot の設定値は /etc/kboot.conf に保存されます。私のシステム構成を以下に示しますが、その大部分は YDL インストーラーが生成した構成そのままで、ビデオ・モードが変更されているだけにすぎません。

default=ydl
timeout=10
root=/dev/sda1
ydl='/dev/sda1:/vmlinux-2.6.16-20061110.ydl.2ps3 
initrd=/dev/sda1:/initrd-2.6.16-20061110.ydl.2ps3.img root=/dev/sda3 
init=/sbin/init video=ps3fb:mode:33 rhgb'

kboot.conf に加えた変更は、次に再ブートした時点で直ちに有効になります。つまり、新しい構成をブートローダーに伝えるために特別なことを行う必要はありません。

ヨーロッパ内で TV セットを使用しているとしたら、おそらくモード 38 で実行することになりますが、その場合は上記のリストで単に mode:33 を mode:38 に変更してください。ちなみに、選択可能なすべてのモードは、ps3videomode -hコマンドで一覧表示できます。さらにps3videomode -v <number> を実行して、それぞれのモードをその場で試してみることもできます。

それではいよいよ、まっさらな新しい何も書き込まれていない状態のビデオ・メモリーにピクセルを書き込む作業に取り掛かります。

「ハイパーバイザー」である Sony GameOS は、PS3 ビデオ・サブシステムを厳重なファイアウォールで Linux から保護しています。その理由が、誰かがいつかどこかで PS3 ゲームをコピーしたり、HD ビデオ・コンテンツの暗号化されていないコードを見たりしないかという普遍的な危惧によるものなのか、あるいはただ単に、Sony では GPU に登録されるようなドキュメンテーションを公表せずに Linux に対してビデオ・インターフェースを公開するメソッドを開発する必要があっただけに過ぎないのかはわかりません (後者の場合、nVidia との秘密保持契約の対象であるコードを一般に公開しなければならなくなるなど、GPL のあらゆる種類の副次的な影響がもたらされる可能性があります)。

動機が何であれ、ps3fb ビデオ装置は良くも悪くも他の Linux フレームバッファーとは異なる動作をします。どのように動作するかについては、Sony がかなり詳しく説明した優れた文書を公開していますが (「参考文献」セクションを参照)、この文書では少なくとも、ある苛立たしいバグについては触れていません。以下に、注意すべき点を簡潔にまとめます。

• 通常、フレームバッファー装置ではビデオ・カードのメモリーに直接アクセスできるようになっています。
• ps3fb 装置を使用する場合、アプリケーションはメイン・メモリーの (オフスクリーン) バッファーに書き込みます。すべての垂直ブランクでハイパーバイザーはこのバッファーを GPU メモリーに直接アクセスさせ、GPU の表示ページを垂直ブランク信号と同期した新しいデータに切り替えます。
• このシステムの利点は、画面コンテンツをフレームの途中で更新することによって動画に発生する「ティアリング」の影響をまったく心配しなくてもいいことです。
• ps3fb も同じく ioctl を公開するので、画面をある種の単一バッファー・モードで実行できます。このモードでは、アプリケーションが適切と判断したときに (もちろん、ハイパーバイザーを通すことには変りませんが) 定期的な割り込みを停止し、新しいビデオ・データを GPU に明示的にダンプします。X が使用するのはこのモードです。

前述した苛立たしいバグとは、標準的なモード情報を照会する ioctl はあまり正確な動作をしないということです。少なくとも、テレビ解像度の場合にはこれが当てはまります。前にも言ったように、NTSC と PAL の解像度ではいずれも仮想/物理サイズが 576x384 ピクセルとレポートされます。これはどう甘く見ても正確とは言いかねます。NTSC 画面の実際の幅は 720 ピクセルで、(徐々に大きくした RAM のスライスをマッピングして探し出すことによって判断される) 高さは実際には約 480 ラインといったところです。ですが少なくともデフォルトのビデオ構成では、フレームバッファー・コンソールはだいたい 400 ラインあたりで止まり、480 ライン目はオーバースキャン領域内の画面の下にはみ出てしまいます。

そのため、PS3 を明確に理解しない一般的なフレームバッファー・コードは、単純にコンパイルして実行しただけでは見事に止まってしまいます。これに対する私の回避方法としては、720x400 ピクセルの画面で実行しているかのように強制的にコードを作成することで、有効に機能するようです。NTSC TV 以外のものを出力装置として使用している場合には、この数値を変える必要があるかもしれません。コードはそれでも動作しますが、判読不可能な表示を生成するおそれがあります。

もう一点、PS3 の出力で明らかにおかしいところは、オーバースキャン領域の色が前のスキャンラインの最終ピクセルでの出力になってしまうことです。この点についての私の持論は、RAMDAC のピクセルがそれぞれの DMA サイクルでスキャンラインにラッチされ、ラスターがフレームバッファー領域外の垂直ブランク間隔まで移動すると、このラッチがフリーズし、黒のピクセル値で再ロードされてしまうということです。他の可能性としては、ハイパーバイザー・ソフトウェアとのある種の微妙な競合条件がこのような現象を引き起こしているとも考えられます。

上記の点について触れた唯一の理由は、画面左端に接する矩形を描画すると、矩形の左上端を除き、その矩形の色がオーバースキャン領域まで拡大されてしまうからです (左上端は、前のスキャンラインの終端の色を引き継ぐため)。この現象は、低解像度のテレビでも明らかに目につくものなので、私のコードのバグとしてはレポートしないでください。これはバグではありません。

判読可能にする

装置に必要なもう 1 つの機能は、テキスト描画コードです。私は文字生成機構の構造を手作りする代わりに、Linux カーネルの font_acorn_8x8.c (フレームバッファー・ドライブ・ツリーの一部) を流用しました。注: これが合法なのは単に、この連載で記載するサンプル・コードは GPL ライセンス交付を受けているからです。クローズ・ソースのディストリビューションを使用できるようにする文字セットが必要な場合は、多少の調査が必要になります。一例としては、Red Hat の eCos オペレーティング・システムに含まれている文字セットを使用できます。Linux フォントのメリットは、必要になる可能性のある hi-ASCII 文字がすべて事前に含まれているという点です。

ここで、サンプル・コードを見てください。このコードには、前述した初期化とともに、単一ピクセルのプロット、塗りつぶした矩形の描画、そしてテキストのレンダリングを行うための関数が含まれています。main.c のデモ・コードは画面に数本のカラーバー、数行のマルチカラー・テキストを描画し、コンソールに関心を引きそうなデバッグ情報を出力します。上記で説明したすべてのグラフィック・プリミティブは graphics.c および graphics.h にありますが、これらのプリミティブ自体を見れば大体の意味がわかるはずです。

キーボードについての注意

サンプル・コードを実行してみると明らかになりますが、最後の注意事項として、PS3 に接続したキーボードは編集に使用しないことをお勧めします。開発は ssh で行ってください (YDL インストールには、何も構成を行わなくても完全に機能する ssh デーモンがデフォルトで組み込まれています)。ssh で開発すれば、PS3 のフレームバッファーに表示されるグラフィックに煩わされることなく、アプリケーションを ssh コンソールで実行し、標準出力で有益なデバッグ情報を見ることができます。

上に戻る

機能的なグラフィック・インターフェースの出来上がりです!

ここまでの説明に従えば、より高度なプロジェクトで使用できる便利な基礎プリミティブを備えた機能的なグラフィック・インターフェースが PPE で実行中になっているはずです。

次回の記事では、iMic を使ってアナログ・データ・ストリームを収集する方法、そして SPE のうちの 1 つを使ってシステムを便利なスペクトラム・アナライザーに変身させる方法を説明します。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

学ぶために

• 準備段階には欠かせない記事として、Linux のインストール方法について説明している Jonathan Bartlett の記事「Cell BE プロセッサーでのハイパフォーマンス・アプリケーションのプログラミング、第 1 回」(developerWorks、2007年1月) を読んでください。
  
  
• Sony では、特に ps3fb 装置が GPU と Linux プログラムと相互作用する仕組みに焦点を絞った非常に優れた文書を公開しています。これはミラーなので、Sony のサイトではこの文書は正式版として扱われていません。
  
  
• 多少 (かなり) 古い情報ですが、Linux Documentation Project に Linux フレームバッファー装置の使用方法が記載されています。率直に言って、各種のデータ構造に関する情報については、サンプル・コード linux/fb.h のスニペットや ps3fb.c ドライバー (Terra Soft Solutions 提供の linux-2.6.16-20061110 ツリーにある drivers/video/ps3fb.c) のコードとコメントを調べるほうが分かりやすいと思います。
  
  
• developerWorks Cell Broadband Engine Resource Center では、Cell/B.E. 関連の新しい資料、ダウンロード、コミュニティーのニュースを紹介しています。
  
  
• Power Architecture ブログでは毎週木曜日にさまざまなニュースをまとめて紹介しています。
  
  

製品や技術を入手するために

• Griffin iMic は選り抜きのオーディオ入力装置です。Web サイトで紹介しているのは、この製品の新しいモデルだということに注意してください。この記事の PPC Linux でテストしたモデルはそれよりも古い、透き通ったシルバーのバージョンで、入力ジャックと出力ジャックの間にスイッチがあります。
  
  
• Yellow Dog Linux は Terra Soft Solutions から無料でダウンロードできます。私の経験から言うと、どのミラーもかなり時間がかかります。そこで、私は P2P ネットワークで yellowdog-5.0-phoenix-20061208-PS3.iso というファイル名を検索して、遥かに高速なインストール ISO を取得しました。
  
  
• Cell/B.E. SDK (最新バージョン 2.1) は、alphaWorks からダウンロードできます。
  
  

議論するために

• ディスカッション・フォーラムに参加してください。
  
  
• Cell/B.E. プロセッサーの利用方法やプログラム方法に関する質問は、Cell Broadband Engine Architecture forum に投稿してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 準備
• 論理的根拠
• 例
• 機能的なグラフィック・インターフェースの出来上がりです!
• ダウンロード
• 参考文献
• 著者について
• コメント