翻訳/ビデオカードの仕組み(HowVideoCardsWork)


Top / 翻訳 / ビデオカードの仕組み(HowVideoCardsWork)

ビデオカードの仕組み(HowVideoCardsWork) (by ひげぽん)

X.Org Wiki - Development/Documentation/HowVideoCardsWork の翻訳です。まだ途中です。
翻訳が終わり、推敲したら日記で公開する予定です。

ビデオカードの仕組み

最近のビデオカードの仕組みを知りたいだろうからここに説明する。

最近のビデオカードは共通していくつかの機能を備えていることが多い。

である。

Video Ram

Video Ram は大きなサイズの高速なメモリである。
このメモリは下に挙げる用途で使われる。

Video Ram 中のバッファには stride (もしくは pitch )と呼ばれる値が関連づけられる。
stride はバッファ中のバイト列の width である。
16 bits/pixel (2 bytes/pixel) の 1024x768 ピクセルのバッファであれば stride は

1024 pixels * 2 bytes/pixel = 2048 bytes	

となる。
32 bits/pixel (4 bytes/pixel) であれば

1024 pixels * 4 bytes/pixel = 4096 bytes

となる。
stride はバッファの全ての行の開始/終了位置を示す重要な値である。
リニアバッファフォーマットの場合、バッファの各行は Video Ram 上でリニアに並ぶ。

framebuffer address
0              2048            4096
|---------------|---------------|---------------| ... |---------------|

Tiled framebuffers

上のレイアウトは、メモリ上のピクセルのレイアウトがスクリーン上のレイアウトと同じなので、「リニアである」と呼ばれる。
スクリーン上の現在のピクセルの右のピクセルは、メモリ上で次に高位なアドレスに一致するということになる。
Tiling はリニアでない一般的なピクセルレイアウトのひとつである。
Tiling では、小さな四角形上にならんだピクセルがメモリ上で次のアドレスにある。
4x4 の Tiling の場合は

 0  1  2  3
 4  5  6  7
 8  9 10 11
12 13 14 15

言いかえると、メモリ上で 0から数えて4つめのピクセルは、スクリーン上の座標 (0, 1) になるし、一方でリニアレイアウトの場合は、(4, 0)になる。
同様に、16個目のピクセルは前者では (4, 0) 、後者では (16, 0) になる。
このレイアウトが使われるのは、スクリーン上で近接しているピクセルはメモリ上でも近接し、キャッシュの局所性を向上させられるからである。

一部のハードウェアは多段の Tiling を持っている。
例えば Radeon のカードは複数のピクセルから成る、複数の microtile と microtile から成る microtile を持つことが可能である。
GPU は tiling を CPU には見えなくする場合もある。(例えばタイルの領域へのアクセスが PCI のバスアクセス上はリニアに見えるようにするなど)

Display control

概要

ビデオカードに搭載されているディスプレイセルは、モニターに送信される信号のサイズ、タイミング、タイプを制御する。
ディスプレイセルは以下の3つの要素からなる。
1. CRTC もしくはディスプレイコントローラ
2. PLL (pixel clock)
3. Outputs

CRTC

CRTC(訳注 CRT コントローラ) は信号のサイズとタイミングを制御する。
この制御には、垂直/水平のサイズや、帰線区間(信号を含まない期間)の制御も含まれる。
多くのビデオカードは2つ以上の CRTC を搭載し、それぞれの CRTC は1つ以上の出力の制御が可能である。
一般的には、それぞれの CRTC が個々にタイミングの値を保持することはない、CRTC が1つ以上の出力を制御しているならば、どちらの出力の制御タイミングは同じである。
CRTC はフレームバッファ上の異なる領域を走査し出力することが可能である。
同じフレームバッファアドレスを指す、2つ以上の CRTC があれば、「クローン」モードである。
クローンモードは、1つの CRTC で2つ以上の出力を制御することでも実現可能である。
複数の CRTC をフレームバッファの異なるポイントを指すようにしている場合はデュアルヘッドであると言える。

ToDo: タイミングのパラメータ、ポーチ(porches)、帰線(blanking)などの説明を加える。

CRTC の stride は走査出力の対象となるバッファの stride である。
バッファの stride は必ずしも CRTC モードのサイズと一致させる必要ない。
そうすることで、バーチャルデスクトップ(2048x2048のバーチャルデスクトップのバッファを 1024x768 のモードに出力する)のようなものや、同じバッファ内の異なる領域を複数の CRTC で出力する(2つの 1024x768 の CRTC が 2048x768 のバッファを出力する)ようなものを実装することができる。

PLL

PLL は pixel/video のクロックを制御する。
pixel クロックは pixel が送信されるレートが PLL である。
垂直リフレッシュレートや、画面解像度が高ければ高いほど、pixel クロックも高くなる。
pixel クロックは通常以下の公式で計算する。

pixel clock = (ref freq) * (m/n) * (1/(1 + r))
ref freq = ハードウェアの影響するベースクロック周波数
m = クロック乗算器
n = クロック割算器
r = 後クロック割算器?

出力(器?)

出力器は、CRTCから送られるデータストリームをモニタが解釈できる何かに変換を行う。
例えば DAC (デジタルアナログコンバータ)は、デジタルデータストリームをモニタ用のアナログ信号に変化する。

他に例を挙げれば、TMDS(Transition Minimized Differential Signaling)トランスミッタ(DVIやいくつかのコネクタで使われるデジタルフォーマットを変換する)、
LVDS (Low Voltage Differential Signaling) トランスミッタ (ノートPCの LCD のようなフラットパネルへの接続に使われる事が多い)、
テレビエンコーダ (しばしば拡大縮小を伴う、アナログテレビ信号への変換)などがある。
出力器はグラフィックチップに統合されたり、外付けのコンポーネントとして(たいていは DVO(Digital Video Outや SDVO (Serial Digital Video Out)のような標準的なインターフェースに接続される形で)提供される。

ドライバの例

多くの Xorg ドライバには、ディスプレイコントローラの設定用に、3種類の関数(普通はチップの名前_driver.c で見つけられるだろう)がある。

Radeon の場合

Save

Init

Restore/Write

2Dエンジン

概要

基本的に2Dエンジン(blitter と呼ばれることが多い)は video ram 中のデータを移動するものである。
2Dエンジンは一般的に4つの操作を持つ: blits(データを一方から他方へコピーする)、fills(一色に塗る)、lines(線を描く)、color expansion(モノクロデータをカラーデータに変換する; 例 モノクロのフォントグリフを画面にあわせた色深度に変換する: 普通は 16か24ビットカラー)の4つである。
論理演算(rops -- ラスタ演算)もまたデータに適用される可能性がある。
ソースとディストネーションバッファがあり(これらはサーフィスと呼ばれることが多い)、これらの演算は1つ以上のサーフィスを利用する。
solid fill のようにディストネーションバッファ(矩形を赤く塗る場所)しか使わないものもある。
blits のような演算はソースとディストネーションバッファの両方を要求する。(この矩形をアドレスAからBにコピーしろ)。
サーフィス同士は重なっていても良い。(実際にそうなることが多い)
このような事情により blit する際は、direction(方向)の概念が必要である。
もし、ソースとディストネーションバッファが重なっている部分があるのであれば、正しい意図するデータをコピーする必要があるだろう。(上から下、右から左など)
システムのメモリに配置されているデータもこれらの操作のソースバッファになりうる。
これはホストデータ blit と呼ばれる。
ホストデータ blit では、ホスト上のデータは video ram の特別な領域にコピーされるか、チップに依存したコマンドキューにコピーされる。
その後、blitter によって、フレームバッファにあるディストネーションにコピーされる。

2Dエンジンは通常、適切なレジスタにアクセスするダイレクト MMIO や、コマンドキューを経由してコントロールされる場合が多い。
ダイレクト MMIO では適切なレジスタに適切な値が書かる。
一連のレジスタの最後に値が書かれたタイミングや、コマンドレジスタに書かれたタイミングでコマンドが実行されるのが普通である。(タイミングはハードウェアに依存)
コマンドキュー方式では、フレームバッファの一部が、コマンドキュー(FIFO)として使われる。
コマンドとひもづくデータは、キューに順に書かれ、描画エンジンによって処理される。

Solid の例

screen (x, y) の (25, 75) の場所に、赤い 200x400 ピクセルの矩形を描く場合。

  1. ディストネーションサーフィスの pitch を、表示するスクリーンの pitch の値にし、スクリーンのバッファが置かれているvideo ram 上のオフセットをオフセット値にセットする。
  2. 使用する rop (ラスタオペレーション)をセットする
  3. 使いたい色をセットする
  4. 目的の矩形の width、height, サーフィスからの相対座標で位置 (x, y) をセットする。

(翻訳途中)

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • タイミングパラメタに関しては、http://direct.xilinx.com/bvdocs/userguides/j_ug230.pdf  のVGAディスプレイの信号タイミングを参照。もっといい日本語解説があると良いんだけど。 -- .mjt 2007-10-18 (木) 06:39:31
    • よく見るとxorg.confのModelineの項目と対応してるのが解ると思います。 -- .mjt 2007-10-18 (木) 06:45:24
    • ありがとうございます。推敲のときに見直します。 -- ひげぽん 2007-10-19 (金) 01:22:30

MENU

now: 2

リンク


最新の20件
2017-09-29 2017-04-25 2017-01-10 2016-12-11 2016-12-09 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 5870, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:03 (3681d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.070 sec.