|
| 第14页：GeForce 8的标量化渲染单元（2） |
对于一个4D vector ALU来说，指令的执行只有有限的几种方式。一般来说最常见的是3D+1D的指令，如
CODE:
add r0.xyz,r0,r1
rsq r2.w,r3.w
或者是一条4D算术指令绑定执行比如
CODE:
add r0,r0,r1
上面举例的这些指令，3D+1D的ALU能单周期完成；但这样的机会不是时刻都能保证的。我们首先要明白co-issue的含义。所谓co-issue，既指令并行,一个4D ALU能并行的同时执行一条3D vector指令和一条1D scalar指令(比如常见的RGB+A色彩渲染)就属于co-issue。对于一个支持co-issue的4D vector ALU，跑
CODE:
add r0,r0,r1
实际上实际相当于3D+1D co-issue的特殊情况：
CODE:
add r0.xyz,r0,r1
add r0.w,r0,r1
对于普通3D+1D ALU的GPU来说，必须将纹理和算术指令配对，否则因为指令限制将出现严重的ALU空闲
co-issue至少要是前后各一个指令，所以shader compiler通常会做特定sorting，这也是实用性比较低的一个原因 因为绘图很难实际做到OOO(Out of order，乱序执行)。如果连续两组1D指令，普通的co-issue 3D+1D ALU应该就会遇上3D闲置的状况，因为arbiter没有连续OOO能力。小熊在线www.beareyes.com.cn
co-issue对指令进行并行处理
所以co-issue并不是每时每刻都有效的，传统流水线的GPU，在内部指令执行方面都有一定限制。比如，NV4X、G7X、R4XX、R5XX都要求程序对RGB+Alpha的co-issue进行配对优化；R580这种非对称架构需要着色器指令的顺序针对不同的过滤方式、不同的纹理格式使用不同的TMU、ALU指令配对比例；G7X要求nrm_pp指令紧挨着TMU指令执行....等等等等。一旦出现不符合它们“胃口”的Shader顺序或者指令搭配方式，那么它们的理论指标就会大打折扣。也就是说，支持co-issue的4D ALU存在指令限制。小熊在线www.beareyes.com.cn
要使co-issue发生，指令有严格的要求
而GPU的编译器即使经过大量优化，编译出来的Shader也指令也会长短不一，五花八门，操作数既有4D，也有1D、2D、3D(例如rsq这样复杂的branch指令需要多个周期才能完成。而且流水线中本身也存在很多诸如blending、2D贴图坐标运算等非4D/3D指令)。对于通常执行能力为4D的ALU来说，让它跑1D或者2D指令，而由于SIMD天生的单发射端口限制，不可能同时跑两个或多个，而跑一个单周期内它的运算能力就填不饱。这样就很“划不来”了。这就是SIMD的指令并行性问题。面对复杂的Shader环境，co-issue不可能是每时每刻都有效的，因此通常的4D ALU在这里就存在一个浪费问题。而对于1D ALU，就不存在上述问题了。
比如一段4D vector算术指令
CODE:
add r1,r2,r3
到了G8X的线程管理调度器里，就被编译变成
CODE:
add r1.x,r2.x,r3.x
add r1.y,r2.y,r3.y
add r1.z,r2.z,r3.z
add r1.w,r2.w,r3.w
虽然1条指令变成了4条，但正好由1个4D ALU切割成的4个1D ALU分别执行，依然是一个周期(期间多出的一条控制指令的周期会被线程管理调度器掩盖掉)。因为各个ALU都有自己的指令发射端口和控制资源，只要线程控制器设计得当，理论上能保证非常高的执行效率。而普通的3D+1D vector只有在co-issue成功的情况下才能保证最高执行效率。在G80上，NV率先引入了这种高效的1D纯标量渲染单元，所以G8X家族的底层执行单元被称做MIMD(多指令多数据流)架构。说得通俗一点，传统4D vector ALU管线的GPU，通过编译器和程序本身去寻找Shader中的并行性，而G8X则通过硬件本身来寻找Shader中的并行性。传统管线的GPU强调ALU的理论浮点运算能力(Flops)，而G8X体系则强调ALU的运算效率。
2007年04月18日 于上海
版权作品 未经许可 请勿转载
| 
