[翻訳] WorldExclusive: Durango’s Move Engines


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

翻訳元

World Exclusive: Durango’s Move Engines


Moore’s Law imposes a design challenge: How to make effective use of ever-increasing numbers of transistors without breaking the bank on power consumption? Simply packing in more instances of the same components is not always the answer. Often, a more productive approach is to move easily encapsulated, math-intensive operations into hardware.

ムーアの法則はチャレンジングな設計を強いる。つまりなおも増え続けるトランジスタをどうすれば電力消費を抑えつつ、効率的に使えるか?単純に同じインスタンスを増やすやり方は必ずしも答えにならない。生産的なアプローチは簡単にカプセル化可能で算術演算を多様する機能をハードウェア化することだ。

The Durango GPU includes a number of fixed-function accelerators. Move engines are one of them.

Durango GPUはたくさんの固定機能を持ったアクセラレータを含んでいる。Move Engineはそのうちのひとつだ。

Durango hardware has four move engines for fast direct memory access (DMA)

Durangoハードウェアは高速なメモリアクセス(DMA)のための4つのMove Engineを持っている。

This accelerators are truly fixed-function, in the sense that their algorithms are embedded in hardware. They can usually be considered black boxes with no intermediate results that are visible to software. When used for their designed purpose, however, they can offload work from the rest of the system and obtain useful results at minimal cost.

このアクセラレータは、それらのアルゴリズムはハードウェアに埋め込まれているという意味で真に固定機能だ。それらは通常ソフトウェアから見える中間結果のないブラックボックスとして考えられる。とは言っても設計通りに使われる場合、他のシステムの仕事をオフロードでき、最小限のコストで有益な結果を得ることができる。

The following figure shows the Durango move engines and their sub-components.

次の図はDurango move engine とそのサブコンポーネントを示している。


The four move engines all have a common baseline ability to move memory in any combination of the following ways:
  • From main RAM or from ESRAM
  • To main RAM or to ESRAM
  • From linear or tiled memory format
  • To linear or tiled memory format
  • From a sub-rectangle of a texture
  • To a sub-rectangle of a texture
  • From a sub-box of a 3D texture
  • To a sub-box of a 3D texture

The move engines can also be used to set an area of memory to a constant value.

4つのmove engineは共通のベースラインの機能を持ち、次のようないかなる組み合わせのメモリ転送も行える。

  • 送り側のメモリー: main RAM, ESRAM
  • 受け側のメモリー: main RAM, ESRAM
  • 送り側のメモリー上のデータの並び: Linear, Tile
  • 受け側のメモリー上のデータの並び: Linear, Tile
  • 送り側のテクスチャの一部をread
  • 受け側のテクスチャの一部にwrite
  • 送り側の3Dテクスチャの一部をread
  • 受け側の3Dテクスチャの一部にwrite

Move Engineは、また特定の値でメモリーを埋める機能も持っている。

DMA Performance


Each move engine can read and write 256 bits of data per GPU clock cycle, which equates to a peak throughput of 25.6 GB/s both ways. Raw copy operations, as well as most forms of tiling and untiling, can occur at the peak rate. The four move engines share a single memory path, yielding a total maximum throughput for all the move engines that is the same as for a single move engine. The move engines share their bandwidth with other components of the GPU, for instance, video encode and decode, the command processor, and the display output. These other clients are generally only capable of consuming a small fraction of the shared bandwidth.

各move engineはGPUクロックあたり256bitのreadとwriteを行え、ピークスループットはそれぞれの方向で25.6GB/sだ。tilingかuntilingの形態だけでなくrawコピーでもピークレートで行える。4つのmove engineは単一のメモリーパスを共用しているため、すべてのmove engineのトータルの最大スループットはひとつのmove engineの場合と同じだ。move engineビデオエンコーダ、ビデオデコーダ、コマンドプロセッサー、ディスプレイ出力などの他のGPU内のコンポーネントと帯域を共有している。これらの他のクライアントは通常、共有された帯域のうちわずかな量しか消費しない。

The careful reader may deduce that raw performance of the move engines is less than could be achieved by a shader reading and writing the same data. Theoretical peak rates are displayed in the following table.

ここで注意深い読者はmove engineのrawパフォーマンスはshaderが同じデータをreadとwriteする際に達成できるものよりも劣ることに気づいたかもしれない。理論的なピークレートを次の表に示す。

Copy Operation Peak throughput using move engine(s) Peak throughput using shader
RAM ->RAM 25.6 GB/s 34 GB/s
RAM ->ESRAM 25.6 GB/s 68 GB/s
ESRAM -> RAM 25.6 GB/s 68 GB/s
ESRAM -> ESRAM 25.6 GB/s 51.2 GB/s

The advantage of the move engines lies in the fact that they can operate in parallel with computation. During times when the GPU is compute bound, move engine operations are effectively free. Even while the GPU is bandwidth bound, move engine operations may still be free if they use different pathways. For example, a move engine copy from RAM to RAM would not be impacted by a shader that only accesses ESRAM.

move engineの有利な点は、演算とは並列に動作させられる点にある。GPUが演算にかかりっきりになっている間なら、move engineは事実上ノーコストで動かせる。GPUが帯域を消費している間でも異なるメモリーコピーパスであればmove engineはなおもノーコストで動かせる。ひとつのmove engineによるmain RAMからmain RAMへのコピーは、shaderがESRAMのアクセスしているなら影響を受けない

Generic lossless compression and decompression


One move engine out of the four supports generic lossless encoding and one move engine supports generic lossless decoding. These operations act as extensions on top of the standard DMA modes. For instance, a title may decode from main RAM directly into a sub-rectangle of a tiled texture in ESRAM.

4つのmove engineのうち1つは一般的なロスレス圧縮をもち、別の1つは一般的なロスレス伸長機能を持つ。こられの演算はスタンダードなDMAモードの拡張機能として働く。つまり、main RAM上のデータを伸長し、直接ESRAMのタイルテクスチャの一部に書き込んだりできる。

The canonical use for the LZ decoder is decompression (or transcoding) of data loaded from off-chip from, for instance, the hard drive or the network. The canonical use for the LZ encoder is compression of data destined for off-chip. Conceivably, LZ compression might also be appropriate for data that will remain in RAM but may not be used again for many frames—for instance, low latency audio clips.

このLZデコーダーの標準的な使い方はチップ外から、つまりHDDやネットワークから読み込んだデータを解凍(あるいはトランスコード)することだ。このLZエンコーダの標準的な使い方はチップ外にデータを送る場合にデータを圧縮することだ。LZ圧縮はRAM上のデータに対しても行えるだろうと想像されるが、低遅延なオーディオのようなたくさんのフレームデータに対して使われることはないだろう。

The codec employed by the move engines is LZ77, the 1977 version of the Lempel-Ziv (LZ) algorithm for lossless compression. This codec is the same one used in zlib, glib and other standard libraries. The specific standard that the encoder and decoder adhere to is known as RFC1951. In other words, the encoder generates a compliant bit stream according to this standard, and the decoder can decompress certain compliant bit streams, and in particular, any bit stream generated by the encoder.

このコーデックにはLZ77(ロスレス圧縮であるLempel-Ziv(LZ)アルゴリズムの1977年バージョン)が採用されている。このコーデックはzlib, glibや他の標準的なライブラリで使われているものと同じだ。エンコーダとデコーダが準拠する詳細な規格はRFC1951として知られている。言い換えるとエンコーダは規格に準拠したビットストリームを生成し、デコーダも規格に準拠したものを伸長することができる。つまり、他のエンコーダで生成されたビットストリームも扱えるということだ。

LZ compression involves a sliding window and operates in blocks. The window represents the history available to pattern-match against. A block denotes a self-contained unit, which can be decoded independently of the rest of the stream. The window size and block size are parameters of the encoder. Larger window and block sizes imply better compression ratios, while smaller sizes require less calculation and working memory. The Durango hardware encoder and decoder can support block sizes up to 4 MB. The encoder uses a window size of 1 KB, and the decoder uses a window size of 4 KB. These facts impose a constraint on offline compressors. In order for the hardware decoder to interpret a compressed bit stream, that bit stream must have been created with a window size no larger than 4 KB and a block size no larger than 4 MB. When compression ratio is more important than performance, developers may instead choose to use a larger window size and decode in software.

LZ圧縮はwindowのスライドとブロック符号を持っている。windowはパターンマッチングに使う履歴をあらわしている。ブロックは自己完結のためのユニットで残りのデータに影響されずにデコードすることができる。windowサイズとブロックサイズはエンコードのパラメータだ。winodwサイズとブロックサイズがより大きければ大きいほど圧縮比率は上がる。逆に小さければ少ない演算とメモリーで圧縮できる。Durangoハードウェアエンコーダ・デコーダは4MBまでのブロックをサポートしている。エンコーダは1KBのwindowサイズを使用し、デコーダは4KBのwindowサイズをしようする。この事実はオフライン圧縮を行う場合の制限となる。ハードウェアデコーダが圧縮ストリームを扱えるために、そのビットストリームは4KBのWindowサイズと4MBのブロックサイズを超えないように生成されていなければならない。圧縮比率が性能よりも重要な場合は開発者は大きなWindowサイズにして代わりにソフトウェアでデコードするかもしれない。

The LZ decoder supports a raw throughput of 200 MB/s compressed data. The LZ encoder is designed to support a throughput of 150-200 MB/s for typical texture content. The actual throughput will vary depending on the nature of the data.

LZデコーダはrawスループットとして200MB/sの圧縮データをサポートする。LZエンコーダは典型的なテクスチャの場合で150-200MB/sのスループットをサポートするように設計されている。実際のスループットは圧縮前のデータによって代わる。

JPEG decoding


The same move engine that supports LZ decoding also supports JPEG decoding. Just as with LZ, JPEG decoding operates as an extension on top of the standard DMA modes. For instance, a title may decode from main RAM directly into a sub-rectangle of a tiled texture in ESRAM. The move engines contain no hardware JPEG encoder, only a decoder.

LZデコードをサポートしているmove engineは同じくJPEGデコードもサポートしている。LZと同じようにJPEGデコードも通常のDMAモードの拡張として動く。つまりmain RAMにあるJPEGをデコードして、直接ESRAMのタイルテクスチャの一部に書き込むことができる。move engineにはハードウェアJPEGエンコーダはなくデコーダだけだ。

The JPEG codec used by the move engine is known as ISO/IEC 10918-1, which was the 1994 JPEG committee standard. The hardware decoder does not support later standards, such as JPEG 2000 (wavelet encoding) or the format known variously as JPEG XR, HD Photo, or Windows Media Photo, which added a number of extensions to the base algorithm. There is no native support for grayscale-only textures or for textures with alpha.

move engineに使われているJPEGコーデックは ISO/IEC 10918-1として知られているもので1994 JPEGコミッティー標準規格だ。このハードウェアデコーダはさまざまな機能拡張が行われた JPEG2000(ウェーブレット圧縮)や、JPEG XR, HD PhotoあるいはWindow Media Photoとして知られるフォーマットのような、より新しい規格はサポートしていない。グレースケールテクスチャやアルファ付きテクスチャのサポートはない。

The move engine takes as input an entire JPEG stream, including the JFIF file header. It returns as output an 8-bit luma (Y or brightness) channel and two 8-bit subsampled chroma (CbCr or color) channels. The title must convert (if desired) from YCbCr to RGB using shader instructions.

move engineは入力としてJFIFヘッダーを含むJPEGストリーム全体を受け取り、8bit Luma (Y または輝度)チャネルと2つのサブサンプルされたchroma(Cb Cr あるいは色相)チャネルを出力として返す。タイトルはそれを(必要であれば)shaderを使ってYCbCrからRGBに変換しなければならない。

The JPEG decoder supports both 4:2:2 and 4:2:0 subsampling of chroma. For illustration, see Figures 2 and 3. 4:2:2 subsampling means that each chroma channel is ½ the resolution of luma in the x direction, which implies a footprint of 2 bytes per texel. 4:2:0 subsampling means that each chroma channel is ½ the resolution of luma in both the x and y directions, which implies a footprint of 1.5 bytes per texel. The subsampling mode is a property of the compressed image, specified at encoding time.

JPEGデコーダは4:2:2と4:2:0のchromaサブサンプリングのフォーマットをサポートしている。図2、3に示されたように、4:2:2サブサンプリングとはそれぞれのchromaチャンネルがlumaチャンネルのx方向に1/2の解像度になっているものだ。結果メモリーフットプリントは1ピクセルにつき2バイトだ。4:2:0サブサンプリングとはそれぞれのchromaチャンネルがx,y方向の双方でlumaチャンネルの1/2の解像度になっているものだ。メモリーフットプリントは1テクセルにつき1.5バイトだ。サブサンプリングモードはエンコード時に指定されるパラメータだ。

In the case of 4:2:2 subsampling, the luma and chroma channels are interleaved. The GPU supports special texture formats (DXGI_FORMAT_G8R8_G8B8_UNORM) and tiling modes to allow all three channels to be fetched using a single instruction, even though they are of different resolutions.

4:2:2サブサンプリングの場合において、lumaとchromaチャネルはインターリーブされる。GPUはスペシャルテクスチャフォーマット(DXGI_FORMAT_G8R8_G8B8_UNORM)とタイリングモードをサポートしておりこれらの3つのチャネルは、たとえそれらが異なる解像度であっても、1つの命令でフェッチすることができる。

注)インターリーブとはYとCbCrが交互に並んでいるという意味
注)"異なる解像度であっても"というのは意味がわからなかった

JPEG decoder output, 4:2:2 subsampled, with chroma interleaved.

In the case of 4:2:0 subsampling, the luma and chroma channels are stored separately. Two fetches are required to read a decoded pixel—one for the luma channel and another (with different texture coordinates) for the chroma channels.

4:2:0サブサンプリングの場合において、lumaチャネルと2つのchromaチャネルは別々にメモリに格納される。デコードされたピクセルを読むには2回のフェッチが必要となる。一つはlumaチャネルで、もうひとつが(異なるテクスチャの)2つのchromaチャネルのためだ。

JPEG decoder output, 4:2:0 subsampled, with chroma stored separately.


Throughput of JPEG decoding is naturally much less than throughput of raw data. The following table shows examples of processing loads that approach peak theoretical throughput for each subsampling mode.

自然な結果としてJPEGデコーダのスループットはrawデータのスループットよりはるかに少ない。次のテーブルはそれぞれのサブサンプリングモードごとに理論的なピークスループットに近づく場合の処理負荷の例を示している。

Peak theoretical rates for JPEG decoding.

Subsampling mode Peak performance Raw data rate
4:2:2 two 720p images/frame at 60 Hz 2 × 1280 × 720 × 2 bytes × 60 Hz = 221 MB/s
4:2:0 two 1080p images/frame at 60 Hz 2 × 1920 × 1080 × 1.5 bytes × 60 Hz = 373 MB/s

System and title usage

Move engines 1, 2 and 3 are for the exclusive use of the running title.

move engine 1,2,3は動作中のタイトルが独占して使用できる。

Move engine 0 is shared between the title and the system. During the system’s GPU time slice, the system uses move engine 0. During the title’s GPU time slice, move engine 0 can be used by title code. It may also be used by Direct3D to assist in carrying out title commands. For instance, to complete a Map operation on a surface in ESRAM, Direct3D will use move engine 0 to move that surface to main memory.

move engine 0はタイトルとシステムで共有される。システムがGPUを使うタイムスライスの間はシステムはmove engine0を使用する。タイトルがGPUを使うタイムスライスの間はmove engine0はタイトルのコードが使うことができる。タイトルのコマンドを補助するためにDirect3Dによって使われるかもしれない。例えば、ESRAMにあるサーフェス上のマップオペレーションを完了するためにDirect3Dはmove engine0を使ってそのサーフェスをメインメモリーに移動させるだろう。
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。