[新闻] vgleaks最新消息！720杀招？盛传已久的secret sauce：data 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 hardware has four move engines for fast direct memory access (DMA)

　　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.

　　

　　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 ESRAMTo main RAM or to ESRAMFrom linear or tiled memory formatTo linear or tiled memory formatFrom a sub-rectangle of a textureTo a sub-rectangle of a textureFrom a sub-box of a 3D textureTo a sub-box of a 3D texture

　　The move engines can also be used to set an area of memory to a constant value.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.

　　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.Copy OperationPeak throughput using move engine(s)Peak throughput using shaderRAM ->RAM25.6 GB/s34 GB/sRAM ->ESRAM25.6 GB/s68 GB/sESRAM -> RAM25.6 GB/s68 GB/sESRAM -> ESRAM25.6 GB/s51.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.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.

　　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.

　　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.

　　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.

　　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.

　　

　　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.

　　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.

　　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.

　　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.

　　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.

　　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.

　　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.

　　Peak theoretical rates for JPEG decoding.

　　Subsampling mode

　　Peak performance

　　Raw data rate

　　4:2:2two 720p images/frame at 60 Hz2 × 1280 × 720 × 2 bytes × 60 Hz = 221 MB/s

　　4:2:0two 1080p images/frame at 60 Hz2 × 1920 × 1080 × 1.5 bytes × 60 Hz = 373 MB/sSystem and title usage

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

　　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.

这恐怕就是现在传闻720没那么好开发的原因吧~

偶有很多看不懂的地方，简单讲大概就是尽可能优化cpu/gpu调度，优化频宽。。

有位仁兄简单有效地描述了一下，蛮有意思的。。

Originally Posted by Drek:

You're moving to a new house, packing up everything you own and making a few trips to the new place to get it all moved.

With the PS4's solution, DDR5, you basically have a box truck that drives 70 mph everywhere all the time and can hold 4,000 pounds of your shit in a trip. When you get to your destination you need to unpack all of this shit too, at 1.8 tons an hour.

With the Xbox 360 you have a big box truck that can carry 8,000 pounds of your shit but it only drives at 28 mph. You also have a car that can carry 320 pounds of your shit and can drive at 41 mph. Once you get to your destination you have to unpack all your shit at only 1.2 tons an hour, but thankfully when you go to unpack your shit is already being sorted for you by a friend outside, helping to organize how you're receiving the stuff you unpack inside.

The Move Engines are that friend. They aren't going to do any of the unpacking (read: processing). They aren't going to carry any of your shit to the new place (read: memory). They just make everything run more smoothly, helping to reduce snags and bottlenecks.

If you were very diligent in how you packed either box truck you reduce the need for such a friend, but it's sure nice to have them no matter what. Chances are the PS4 will have some level of this same concept as well, though likely not to the same extent that MS is incorporating, since MS needs some way to get over the DDR3 bottleneck.

I'd say it's a further complication resulting from MS wanting 8 GB of memory and therefore going with clearly too slow DDR3. Move Engines, ESRam, etc. are all attempts to patch over that deficiency. This is also likely why MS is running them pre-programmed, because making developers have to manage this to avoid a bottleneck the PS4 doesn't have would be a pain in the ass.

It's like being able to transfer data from your main memory on PC to your GPU memory without using up CPU or GPU time. And while transparently doing some compression/decompression.


联动起之前的新闻，或许真是不谋而合。。
several development sources have told us that Sony’s solution is preferable when it comes to leveraging power. Studios working with the next-gen Xbox are currently being forced to work with only approved development libraries

[ 本帖最后由 倍舒爽 于 2013-2-7 03:04 编辑 ]

这回是软饭玩潜力无穷了？

哟，要真的话那倒也8错啊，让软饭了解下当年索饭的那股憋屈和失望，索饭一直等到09年e3才开始真正有作品让人挺起胸膛。。。
让人站在对方立场置身处地，身历其境。。实属难得啊。。
以姐姐的说法是：简直有利于人类的灵性升华啊。。。
不过以微软的软件开发力，相信1年内就能优化得比较彻底了。。

不过这已经都不重要了。。
因为今次有个人机交互的大前提。。

sony今次能让你看4k钢铁侠，而ms今回直接让你当钢铁侠去了哦。。。:D

[ 本帖最后由 倍舒爽 于 2013-2-7 02:37 编辑 ]

為什麼要理vgleaks這文,又長又模糊

話說發言間隔變300秒了

[ 本帖最后由 你老闆 于 2013-2-7 03:00 编辑 ]

为了给发帖机器人增加点障碍
最近深夜都是这样

看看微软新主机那侏儒般的配置能怎样迸发出惊人的小宇宙

posted by wap, platform: iPhone

微软的乾坤大挪移。
要想当钢铁侠估计要等kinect360

开发起来还算好用不？

但愿过几天别yy脑后插管进矩阵,都是巨硬没良心害的。

ms第一方那实力，玩什么潜力啊，ps3上07年就做出突显实力的海域1了，秒战争机器一条街，哈哈哈

posted by wap, platform: Android

记得当年有个别软饭鼓吹360主板上有隐藏芯片能实现1080p输出   是微软有意搞的隐藏大杀器   

后来呢？

(时间久远 大概这么个说法)


后来呢？

360不能1080P输出？

这篇文章很奇怪。。data move engine.  不是主要的的作用在于 gpu 和cpu 如何共享数据么？（hsa 的设计目标是cpu 和gpu 能够统一寻址） 读取内存只是一部分的功能吧。 jpeg解码不是最普通的功能么？200块钱的 高清播放机都有。。为什么要啰里啰唆讲这一堆。

我还是喜欢机能简单粗暴的巨硬
而不是玩潜力无限的微软。。。

posted by wap, platform: iPhone

真跟不上现在技术了，这玩意跟以前专用的dsp不是一样么，负责zlib，jpeg，和数据传输，但又嵌在gpu里。