全球第一个第三方D3D10 shader级别性能测试

Edison

Rightmark 3D 2.0，源代码公开，公开、公平的测试软件。

驱动程序：CATALYST 8.3891 / ForceWare 158.45

原文：http://www.ixbt.com/video3/rightmark2.shtml

93324003

FX好强大~~

Eji

原帖由 RacingPHT 于 2007-7-23 14:55 发表
这个地方确实不严谨, 如果只是cache line miss才fetch, 就算多一些也应该不能算是prefetch. prefetch我的理解是, 如果load超出一个cache line大小, 尚未开始使用的数据, 就可以算是prefetch.

但是我也不能确定GPU没有这个东西...不过其实有threading机制之后太过聪明的prefetch变得没有必要了。

過去用quote長度來吸收texture fetch時的latency，現在則是因為延遲的種類增加、複雜化，所以改成threading來吸收。
不過狀況大多是"因為存取記憶體會有很大的延遲、而且記憶體系統的進展又沒有縮短延遲的跡象"，所以提供機制來吸收這部份的負擔....
其實本質沒什麼變化。

[ 本帖最后由 Eji 于 2007-7-23 15:08 编辑 ]

Eji

原帖由 RacingPHT 于 2007-7-23 14:02 发表
关于prefetch优化, 有一些暗示
http://www.math.sintef.no/gpu/pdf/Dokken_SCCG_2005.pdf

The GPU prefetches texture data close to the current
fragment to speedup fragment execution. However, this ...

關於這部份.... 我覺得這只能算是每次tex fetch的時候，替後面的處理"多讀的"....
說成prefetch有點太聰明了些。

ayanamei

原帖由 Eji 于 2007-7-23 14:08 发表


前面RPH兄提到，G8x每個Multi-processor（8SPs set）有8192個 float4 (128bit) register。
8192個Register可以是16個float4下128個thread、或者是4個float下512個thread(max)，甚至是128個register下16個t ...

大致明白一些了
就是说thread manage也不可能创建大于rigister file所能承受的thread
当threads 所需要的register file 饱和后 也不会派发新的thread给下面的资源了

如果是每个MP 8192个float4... regfile总量2MB了阿。。。
:funk:

[ 本帖最后由 ayanamei 于 2007-7-23 14:29 编辑 ]

ayanamei

原帖由 RacingPHT 于 2007-7-23 14:13 发表
ayanamei:

你的理解对于fine grained threading是不对的。对于这种需要单周期切换线程的系统, 必须提供与thread数量倍数大小的register file.
而对于GPU来说, 每个shader所需要的register是不同的, 并且也没 ...

谢谢

也可以理解为constant register中主要是一些公有数据

而temp register中是不同thread 处理过程中所抓取的数据，以及一些计算结果之类的
能这样理解吗？

Eji

原帖由 ayanamei 于 2007-7-23 13:18 发表
恩 确实 因为对GPU内部具体是如何做这个切换 只是猜测
主要的来源是G80声称每个block 512thread
如果实际真的并发这么多thread
事实上我也认为不可能在G80塞下那么多的 rigsiter
所以这些thread中应该有部分 ...

前面RPH兄提到，G8x每個Multi-processor（8SPs set）有8192個 float4 (128bit) register。
8192個Register可以是16個float4下128個thread、或者是4個float下512個thread(max)，甚至是128個register下16個thread應該都可以....(當然效率可能會有問題，這與Register File的讀寫port設計有關)
如果從這點來看，每個MP會需要128KB的Register File。

Constant Register是記載常數用的，咚氵^程中不會被更改，而且是共用的，所以與thread無關
由於咚阒袛嗯c繼續的需求，thread得記載咚氵^程中的暫存結果。


Temp Register: The Temporary Registers are 4-component floating-pointvector registers used to hold temporary results during vertex program execution.

Float Constant Register: They are also program parameter registerswhich are a set of 4-component floating-point vector registers containing thevertex program parameters.

Integer Constant and Loop Counter Register: Integer Constant Registerscorrespond to flow control registers which are currently used only in the LOOPand REP instructions. When used as an argument to theLOOP instruction:

[ 本帖最后由 Eji 于 2007-7-23 14:14 编辑 ]

ayanamei

恩 确实 因为对GPU内部具体是如何做这个切换 只是猜测
主要的来源是G80声称每个block 512thread
如果实际真的并发这么多thread
事实上我也认为不可能在G80塞下那么多的 rigsiter
所以这些thread中应该有部分是在真正执行的，而部分是挂起的
是否这些挂起的thread 相关的rigister数据能够被保存到GPU内部某个储存器上，比如一些sram,毕竟写回local memory太慢,GPU也不会涉及这种动作
至于shared memory,constant memory貌似是G80 thread manage体系里面的东西
确实和register拉不上太关系 只是GPU内部是否还有类似的东西来保存这些挂起的threads
还说它们一直霸占着register资源？
对于GPU物理上是如何运作 我也只能大概去想象一下 以上都是猜测
另外constant rigsiter/temp register 之类是使用上去区别的概念吧吗？
我能理解什么是rigsiter 但是 这种区别是始终不明白
还请简单的解释一下

[ 本帖最后由 ayanamei 于 2007-7-23 13:28 编辑 ]

ayanamei

原帖由 RacingPHT 于 2007-7-23 00:09 发表


1: GPU调度的单位名义是thread，但实质上则是一组thread。
2: 某个硬件的thread数量不是固定的, 而大体上与程序的寄存器需求呈倒数关系。shader越复杂则thread数量越少，实际获得的IPC就越低。
3: 对于G8 ...

G80 每个MP 拥有独立的constant memory 和shared memory
应该有register file的替换机制才对 将stall theading所需的资源替换出来 让其他theading使用
这样TPC最终最大能管理的threading数量和实际
constant register决定的parallel-threading的总量了就不存在什么冲突了

[ 本帖最后由 ayanamei 于 2007-7-23 03:10 编辑 ]

ayanamei

其实我觉得思考说"GPU没有CPU那样的Cache"
简单的理解就是说从GPU cache机制更多的是为了texture fetch服务的
CPU可以从cache中抓到想要的所有数据 只要必要
但是GPU 的渲染流程来看 Cache是保证平行度 减少stall的东西
毕竟GPU不是从内存抓数据开始整个管线

而单纯看待cache而言 cache的特性和应用是不会有什么本质不同
但是从CPU和GPU的整体特性上 他们的地位 和解决的问题取向有少许差异

[ 本帖最后由 ayanamei 于 2007-7-23 02:49 编辑 ]

Edison

iXBT的老大刚刚和我说，他们将会在明天正式发表这篇测试文章，大家拭目以待。

vrml

有几个问题想请教RacingPHT 和 思考:

至于thread数量，G80一共有8个TPC，每个TPC拥有两个multiprocessor，每个multiprocessor具备24个warp，每个warp拥有32个独立的thread....你可以自己算一下一共有多少个thread

可以算一下，一共有8 * 2 * 24 * 32个thread,但同时有128 个scalar process, 平均每个96个thread, 而

现代内存系统在1.35Ghz的处理器上的延迟大概是200-300个cycle

实做中shader的temp寄存器直接影响到thread的数目, 所以实际的thread数量远远达不到理论的水平。20个thread是一个实际我见到的数目。

可以解释一下为什么吗？

另 for 思考： 你引用David B.Kirk的这段话，难道你忘了这位老兄曾经给我们开的大玩笑吗？ "G80 是non-unify-shader"

"但是我后来的观点“GPU不具备类似CPU那种类型的perfetch体系”，我认为依然是正确的"

我不知道什么是“CPU那种类型的perfetch体系“,能否给解释一下。但任何一种cache,遇到miss后都不会只fetch当前所需的数据，而是一整条cache-line,从而保证以后的若干request是hit.即如RacingPHT如说的texture fetch的例子。

So, 我认为无所谓"build for hit" or "build for miss", 在实作中既有尽量保证数据相关性以提高hit rate,又要有诸如multi-thread的方法来cover latency.

kunnsr

原帖由 flymop 于 2007-7-20 21:19 发表
FT啊
这哪是FX附体
这明明不是当年的S3么

那个野人2000哈w00t) w00t) w00t)