为ATI正名

NightBeckon

ati的thread能力比并不是很弱

根据R600公开ISA以后 对r600 以及其衍生的rv770的thread能力 以及GPU threadmanage的动作有了比较正确的认识
if,else之类的动作 在threada manage 的dips-pacth processor被解开 有选择性的把来自各个Vertex/Fragment 的thread 根据一致性打包成64thread为粒度的wavefront 交付给每个SIMD ARRY（16 * 4D+1D规模） 由arbiter 以及sequencer来分配 调度给每个4D+1D 执行单元 。这些完全一致的thread就如指令流一样经过执行单元，而arbiter 以及sequencer用来错开指令冲突或寄存器冲突
而dips-pacth processor会把由branch造成的不一致的thread挂起 压后至少64个周期 和其他与其符合并发条件的thread 打包成另外一个64thread 并列的指令串 交给空闲出来的另一个SIMD ARRY执行。这个过程中branch造成的延迟 还是被以切换wavefront 的方式尽可能的遮掩了。R600的结构最大能够操作96个这样的wavefront
R600要说最大thread 并发能力是 6144thread 而rv670/rv770 则可以并发192 wavefront 12288threads 和G80 /g92持平 (32thread x24warps x2SM X8TPC=12288threads)
但是 真正有实际价值的是实际并列thread R600拥有4个SIMD ARRY 所以它的实际平行度是64thread x4 =256thread
而g92 拥有8个TPC 每个TPC 2SM ,每个SM 1 WARP warpsize=32thread =32x2 x8 =512thread

简单的归纳thead namage的动作 就是把具有一致性的thread 大包成一个一个wavefront,让它在各个SIMD ARRY中中执行，当某个wavefront遭遇tex 延迟 或者其他阻塞的时候挂起它 然后切换到另外的wavefront，通过切换wavefront来规避管线阻塞 带来的性能下降,对于branch造成的不一致性 将会被抽离原有的wavefront 在合适的条件包装进另外一个wavefront,由于wavefront粒度比较大
R600体系结构理论能够容忍最小的branch size也就是64 pixel

关于thead manage的动作 其实g8x 和r6xx是一样的 但是不同的地方在于g8x 的wavefront size 也就NV自己称作warps 比较小 只有32thread，而且还存在size=16thread的half warp
拿g92来做对比的话 几乎与对手2倍的Shader core频率 造成了实际解branch能力是 r6xx的体系的4-8倍 这点比较恐怖。不过这个优势还是要在GPGPU方面才能看到
branch size=8x8 pixel 来说 满足图形应用应该说是够用的。。。
作soft shadow R6XX-RV6XX 都逊色一些 还是因为做这些操作TMU不够劲吧

R600\RV670和RV770都是一个wavefront含64个thread，RV770的理论并行度可以达到512个wavefront，但是由于SIMD的问题，实际上LDS在掩盖thread延迟的能力上基本等于无用，RV770勉强可以做到RV670的理论性能，即每个SIMD core每周期最多2个wavefront，如果此时其中一个wavefront里面含有1个2重分支，这在softshadow中很常见，那么这个wavefront就要进出两次，中间整个SIMD core被挂起的周期干脆不知道会有多少，一旦该wavefront开始这么9进9出，整个SIMD core就实在是爽了……
NV一样会有分支方面的问题，但是16个thread的half-warp保证了相当细化的粒度，再加上shared memory的高度共享可以有比LDS好得多的性能和共享度用于掩盖延迟，所以G80才会有这么好的分支性能
wavefront里面64个粒度的设置过大才是关键，一旦这些像素中出现分支则此时压力不应该来自纹理而是Shader，从RV670到RV770暴利放大的纹理单元能够带来相应的纹理性能提升，而softshadow性能的对应提升却没有G80到GT200来的大

wavefront Size=64的考虑是错开并遮掩thread 指令流间的指令延迟 和部分寄存器读写冲突 造成的still，64thread 正好让每个SIMD ARRY中16 个4D+1D UNIT 保持 1执行3列队的状态 ，与wavefront的不同的是每个thread都有实际使用到rigsiter资源。所以考虑平行度的时候 把这64thread作为运行状态
这个和g8x Warp size=32 的情况一样 满足SM内 8SP 同样是1执行3列队的状态。
=.= 从cho给的资料看RV670/RV770 每个SIMD ARRY最大同时并发48 wavefront 然后按照4 X SIMD ARRY 最大并列数192 wavefront,而rv770 现在貌似还没有明确的数字 不过个人觉得48x 10 480wavefront 或者没有进一步强化并列度 而是降低了每个SIMD ARRY的并列度 维持原有192 wavefront的可能性都很大 512wavefront的说法好像也看到过 不过这个出处没什么印象

在branch的情况下 造成了wavefront中的不一致性的话 thread根据branch的结果 自然的停顿下来 等待wavefront退出后 再重新根据一致性再次打包 ，如此反复直到整个过程结束。最坏的情况下是64条thread全都满足branch条件， 然后整个wavefront still,干等至少64cyc 给他们找到跳转目标
但是实际情况应该还有未满足branch条件继续执行仍保持一致的thread存在 所以实际并不会完全浪费掉16个SIMD 64个周期,但是这样的情况 必须等待那些依然维持一致性的thread被执行完成，或者遭遇tex latency之类的才会被退出wavefront。这样2个结果分别是 branch本身需要干等若干倒数百个周期 ，如果是因为阻塞退出执行的wavefront ,不满足已执行的thread就会被抽离 那么剩下下次被激活处于中间状态的wavefront thread就不满64 如果实际size小于16的话 那么空闲的UNIT又要空载若干到数百个周期。。。
这里比较怕的一个情况就是branch size小于64 r600 可能需要反复很多次才能抓到跳转目标 这样branch延迟可能就会多数倍
这就是branch比较多 同时branch size如果小于GPU允许 性能就会几何状下降
但是即便如此让整个SIMD ARRY都停下来的情况概率还是太少了 但是R600解branch付出的代价比g8x高很多这点是肯定的 一旦branch比较多的shader 性能差距就会拉大。g8x独特的share memory,parallel memory 这些似乎只有在CUDA管理下才能用到，图形应用是不会操作这些东西的
总的来说决定GPU 面对各种延迟 和branch数量能力的主要还是 GPU thread最大平行度 和wavefront 的粒度 这2点上

fur和steep parallax Mapping中双方的差距其实基本上已经接近分析所体现出的理论值了~我不知道其中究竟试用了几重分支，但大体上看来2重分支应该占主流，进出2次才能完成完全的解包以及条件分支之后的结果就是从rv670到g92那平均300%到400%的差距，其实应该已经算是相当致命了。而且我相信如果此时提高分支的步伐，恐怕几何暴降应该会轻松出线甚至成为整个US单元最致命的拖累……不过目前还没有什么人用这么多的分支来写游戏指令就是了

这是我和一个朋友讨论的原话

原帖由 NightBeckon 于 2008-10-9 15:47 发表
这是我和一个朋友讨论的原话

稍微排下版吧~~~个别字句加个颜色什么的~:a28:

原帖在这里, 这是我在NGA的测试帖, 后两页是他们两位高人的讨论贴,....
http://bbs.ngacn.cc/read.php?tid=1897433&fpage=3

在A菲米斯眼棱召唤出来的骷髅的时候以及打双子暗女的2个场景

咱的280只有20-30帧左右

那到底应该说是我的U不行呢还是说在画面很混乱的时候再高端的显卡也会被WOW一砖撂倒呢

280在WLK即使是野外,表现也不怎么样.有时候也跑不上60.WLK的真实阴影吃硬件和弹头有一拼.

引用某人原话:
我alpha到beta玩了4个多月

不知道report了多少各类bug

灰熊 HJ那边做任务的卡的和狗一样的人 不是只有我一个 然后还费神费力和GM聊天 现在总算好了

至于用ATI卡 跑灰熊和HJ完全没有这个问题 这个是我到现在那么久测试过程中碰到最大的一个硬件相关问题

只谈玩Wotlk ATI要比NV好

其他的不谈