拉娜芘的行为艺术larrabee

Prescott

原帖由 Edison 于 2008-9-2 17:12 发表
这个 06 年的 paper 已经说得很清楚了：cache line 是 512bit aka. 64B。

vector register也是512bit，那存在从同一个cache line G/S的可能性吗？

Edison

那我准确一点说好了，从同一个 cache-line 里 G/S 。

Prescott

原帖由 Edison 于 2008-9-2 17:17 发表
那我准确一点说好了，从同一个 cache-line 里 G/S 。

那还叫G/S啊，就是一普通load嘛

Edison

难道同一条 cache-line 里 load 就一定是等于连续地址的 load ？

Prescott

寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？

zhangyi1984911

游戏性能难说，用这东西跑3Dmark06 CPU分数肯定超过3万{lol:]

Edison

原帖由 Prescott 于 2008-9-2 17:28 发表
寄存器大小=cache line大小，都是64Byte，你怎么从同一条cache line中load出不连续地址的64B数据来？

Siggraph 的 paper 的确是这样说的。 我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。

G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。

你来说说 register size = cache line size 和 从同一条 cache line 里能不能 G/S 不连续地址数据是有啥关系吧？

Prescott

原帖由 Edison 于 2008-9-2 17:43 发表


Siggraph 的 paper 的确是这样说的。 我上面说的是指不同 cache-line 需要多次 access，需要的时间就是 n 倍。

G/S 可以从不同的 cache-line 抓，也可以从同一条 cache 里抓。

你来说说 register size =  ...

很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题

gaiban

原帖由 Edison 于 2008-9-2 17:03 发表
Larrabee 在 G/S 的时候，只能做到单周期完成同一个 cache line 的 G/S，如果从不同的 cache-line  G/S，就可能需要更多的时间，例如两条不同的 cache-line，可能就是两倍的时间，最糟糕的情况应该是16倍，这样的设计 ...

话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？

为何说cuda呢？  通用性能，larrabee天下无敌。

Edison

原帖由 Prescott 于 2008-9-2 18:06 发表
很简单，如果G/S必然是从不同的cache line中取数据，那你就不要认为Intel工程师会笨到不会处理这种明显的性能问题

The speed of gather/scatter is limited by the cache, which typically only accesses one cache line per cycle.

现在的问题是程序不会完全是由 Intel 的工程师来编写的吧，而且如果软件、编译器能解决这个问题，还需要 G/S 吗？

Edison

原帖由 gaiban 于 2008-9-2 18:13 发表
话说游戏的时候，GPU主要应该是到显存去G/S吧？
由于tile/bin，而larrabee主要是到cache里面G/S吧？
为何说cuda呢？  通用性能，larrabee天下无敌。

谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采用 compute shader 实现一些需要 data re-use 的状况，compute shader 支持 shared register。

Tile/binning 做图形运算的时候需要多少机会用到 G/S ？

gaiban

原帖由 Edison 于 2008-9-2 18:18 发表


谁说游戏的时候是不会动那个 "scratchpad" 的，只是图形运算的时候可能不触及，用 GPU 跑物理、AI 加速的时候不就是游戏运用上 scratchpad 的情况了吗？如果说是 deferred rendering，到了 DX11 世代我想大都会采 ...

你要是说，当前游戏里，驱动会自动使用scratchpad来参与渲染，还有点说服力。   

要是你说的那些，那等到GPU 跑物理、AI、或compute shader的时候， 那就基本就无关了。 larrabee跑那些会很强大，另外那些还用得到G/S？

Edison

目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。

如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 data-reuse 的 filter，scratchpad + G/S 的设计就会非常有意义。

insect2006

好东西，慢慢研究一下

gaiban

原帖由 Edison 于 2008-9-2 18:39 发表
目前跑 D3D/OGL 的时候，g8x/g9x/gt200 的 shared memory 应该根本就没启用，除非配合 CUDA ，但是这必须游戏开发人员来采用而不是驱动来做。

如果你用 compute shader 计算一些范围是 100x100 或者更大并且涉及到 ...

若游戏没有用到的话，那GPU就是要去显存G/S了，需要好多好多个cycles了。

偶主要说物理、AI这些哪用得到G/S。   compute shader还比较远的事情。

Edison

对于图形渲染来说，数据的读取大都是非常非常规则的，使用到 G/S 的机会并不大，如果需要使用的话，NVIDIA 这里有 CUDA，AMD 过两个星期也都有支持 RV770 scratchpad 的 SDK 推出，开发人员可以根据其游戏的渲染特别决定是否使用。

我的确不知道 Compute Shader 或者说 DX11 什么时候会正式出来，但是以目前资料的发布详细度看，明年应该就能出来了吧，谁能告诉我 Larrabee 什么时候出来呢？

如果是进行特征识别的话，我想 G/S 还是可以使用上的，特征识别在 AI 上是时常使用到的。