POPPUR爱换

标题: 醒悟了, C1定了几年的flops其实是错的。 [打印本页]

作者: RacingPHT 时间: 2007-4-30 13:05
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-4-30 13:09
哦？你实际测试出来的？

作者: RacingPHT 时间: 2007-4-30 13:12
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-4-30 13:14
这个只是ISA层面的，硬件上的做法未必一样。

作者: Edison 时间: 2007-4-30 13:18
我查阅了Microsoft的paper，的确是：

48 ALUs
simultaneous vector, scalar ops
16 vertex & 16 texture fetch
96 shader instr/cycle ( 48 Ginstr/s) - 12 instr/pix fill rate
32-bit IEEE FP (VS & PS)
216 GFLOPS (theory)
168 GFLOPS (Vtransform)
they are arranged in 3 banks of 16 ALUs in SIMD
64 threads (HW), 16x64 Vertex vectors, 48x64 Pixel Vectors
Balancing vertex vs pixel shader perf

作者: eye2eye 时间: 2007-4-30 21:15
:funk: 虚假宣传

作者: PS5 时间: 2007-4-30 22:25

原帖由 Edison 于 2007-4-30 13:18 发表
我查阅了Microsoft的paper，的确是：

48 ALUs
simultaneous vector, scalar ops
16 vertex & 16 texture fetch
96 shader instr/cycle ( 48 Ginstr/s) - 12 instr/pix fill rate
32-bit IEEE FP (VS & P ...

这个比RSX强吗？:o

作者: RacingPHT 时间: 2007-5-1 09:30
提示: 作者被禁止或删除内容自动屏蔽

作者: Edison 时间: 2007-5-1 09:38
怎么对这个感兴趣呢:)

作者: RacingPHT 时间: 2007-5-1 09:47
提示: 作者被禁止或删除内容自动屏蔽

作者: Eji 时间: 2007-5-2 03:45
話說有趣的部分：
http://pc.watch.impress.co.jp/docs/2005/0526/kaigai183.htm
這裡面的資訊反而是說，"216GFLOPS 更正到 240GFLOPS"。

　ちなみに、前のレポートでは、Microsoftからの情報をもとに、ベクタFPUが1サイクルで積和算の2オペレーション、スカラFPUが1サイクルで加算の1オペレーションで、1 Shaderで1サイクル当たり最大9の浮動小数点演算オペレーションで、Shader演算性能は最大216GFLOPSと性能について書いた。しかし、 Microsoftが後に出した資料では、最大で5wayベクタで1サイクル2オペレーション、Shader演算性能は最大240GFLOPSと修正されている。

到底哪個是新版的呢....XD

作者: Edison 时间: 2007-5-2 09:23

原帖由 Eji 于 2007-5-2 03:45 发表
話說有趣的部分：
http://pc.watch.impress.co.jp/docs/2005/0526/kaigai183.htm
這裡面的資訊反而是說，"216GFLOPS 更正到 240GFLOPS"。

　ちなみに、前のレポートでは、Microsoftからの情報をもとに、ベ ...

应该是是microsoft为准了。

作者: hourousha 时间: 2007-5-2 09:53
其实很早的时候b3d的jawed就说了这个问题了:)
jawed大概是最早把SDK内容外泄的人了，比如什么shader exp用法，scalar无mad，C1无FP16 blending，FP16 filter用的是INT16+INT16等等……:wacko:

[ 本帖最后由 hourousha 于 2007-5-2 10:58 编辑 ]

作者: hourousha 时间: 2007-5-2 10:01
但显然多数人不认为这是很大不了的事情，本来scalar的主要任务就是rsq，exp那些工作。而这些指令的flops同样无人关心。:lol:

作者: 来不及思考 时间: 2007-5-2 10:21
提示: 作者被禁止或删除内容自动屏蔽

作者: hourousha 时间: 2007-5-2 10:33

原帖由 来不及思考 于 2007-5-2 10:21 发表

开平方这些比较复杂的数学运算在现在的shader里还是用得很少吧

应用很普遍啊，从SM_2时代开始
所以，R3xx-R5xx的那些可以co-issue的scalar unit的存在，其根本任务不是为了通过co-issue提高什么指令并行，而在于补全指令。

其实较真的话，sin可以算6-7个flops了（当初R3xx就是7个周期sincos，应该用的是收敛级数法）但显然不是所有人都和西川大叔或者后藤大爷一样恨不得把nrm_pp都拉出来算flops w00t)

作者: 来不及思考 时间: 2007-5-2 10:46
提示: 作者被禁止或删除内容自动屏蔽

作者: hourousha 时间: 2007-5-2 10:53
不是有GPUBench么？看指令发射率就成了呗。G80是每个SP中都带个SFU么？好像也不是。

作者: RacingPHT 时间: 2007-5-2 10:58
提示: 作者被禁止或删除内容自动屏蔽

作者: hourousha 时间: 2007-5-2 11:06

原帖由 RacingPHT 于 2007-5-2 10:58 发表
是啊, OP/s比较重要. 对于SF, 现在的产品都是采用80/20法则.
另外, 对于LS的那个问题, R6xx的所有SF应该都是单周期pipeline化才行？

我想R600中代替原先的结构scalar unit的那个东西（粗的那个），大概应该不会和原来相比有什么大变化。所以应该是 1 cycle throughput的。
所以R600的复杂指令发射率基本就应该是把原先结构的发射率按照64组和更高频率来放大。

作者: Edison 时间: 2007-5-2 11:08
RSQ在G8X的吞吐大约是4个周期左右，在R5XX上是1个周期。

作者: hourousha 时间: 2007-5-2 11:11

原帖由 Edison 于 2007-5-2 11:08 发表
RSQ在G8X的吞吐大约是4个周期左右，在R5XX上是1个周期。

也就是半个sp cluster（8 SPs）中有2个SFU了？那和R600半斤八两了。

作者: 来不及思考 时间: 2007-5-2 11:28
提示: 作者被禁止或删除内容自动屏蔽

作者: rongronglulu 时间: 2007-5-2 20:49
R600的是不是和这个玩艺儿一样w00t) w00t) w00t) 有看头了

欢迎光临 POPPUR爱换 (https://we.poppur.com/)