引用:

原帖由 卖哥 于 2010-8-20 01:05 发表
222006
222007
222008

说到N64
这货很超前呀……

简单说下就是，N64的图形单元RCP，分为两个部分，
RDP是一个很规范的图形处理器
RSP是一个64位的处理器，功能是T&L和把粒子、多边形一类图元的内存地址递 ...

PS也有GTE做T&L的工作。那不是更超前了。
RSP是8way-fixed_point的格式，而T&L是需要浮点运算的，只能用定点数模拟，因此才有‘一开始SGI提供的数学库由于追求准确而速度过慢’的现象发生。GTE好歹还是原生浮点运算支持的。
要说N64比PS先进的，还真就是RDP，毕竟PS连Z缓存都没有，所有的三角形在‘显卡处理’的阶段都只是一个平面的三角形而已。遮挡关系全由绘制顺序而定（没Z-Buffer自然深度检测无法实现），至于像素属性的透视矫正则更加没有希望了。

引用:

原帖由 lemonninja 于 2014-6-27 22:12 发表
GTEはCPUのコプロセッサとして、座標変換や光源計算、例えば固定小数点形式の行列やベクトル演算を並列処理機構により高速に演算します。
GTE哪里来的原生浮点运算啊，连PS的开发文档上都说不支持浮点格式。

4年前的老坟您也挖……
不过这点确实是我搞错，GTE有若干种定点格式，比如1.27.16或1.31.12等。不过基本不影响我说的结论，准确说T&L需要的是相当的动态范围，浮点数的动态范围自然是非常理想，不过GTE的定点格式动态范围也算尚可，最关键是不用开发者去太操心这个，尤其是中间运算的容错和精度等等（其实是想去操心也没得操心），而RSP的8way_FX16就不是这么回事了。
也就是说RSP直接把uCode的Ref扔给开发商，则对大部分厂商来说虽然是可编程了但基本没法用，于是乎只好去用现成的SGI库，然后结果就是N64很快被HLE……而且就如图所示，fast3D这个库，过于注重运算的精度和健壮性，速度其实是相当慢的，明显低于PS的GTE提供的性能。

[ 本帖最后由 hourousha 于 2014-6-27 22:51 编辑 ]

引用:

原帖由 conda 于 2014-7-1 15:55 发表
PS1 的 GTE 哪有这些格式，只有 16位整数机能。

16位定点处理器不代表运算变量是16位定点好不？否则还能用吗你想想？
当初没有x87协处理器的电脑，编程就只能用整数了是么？
以下是RTPS的演算流程，第一列代表精度，为符号位，定点整数位数，定点小数位数

复制内容到剪贴板

代码:

(1.31.12)  SSX = TRX + R11*VX0 + R12*VY0 + R13*VZ0; <1>
(1.31.12)  SSY = TRY + R21*VX0 + R22*VY0 + R23*VZ0; <2>
(1.31.12)  SSZ = TRZ + R31*VX0 + R32*VY0 + R33*VZ0; <3>
(1.15. 0)  IR1 = limA1S(SSX);
(1.15. 0)  IR2 = limA2S(SSY);
(1.15. 0)  IR3 = limA3S(SSZ);
(0.16. 0)  SZx(0) <- SZ0(1) <- SZ1(2) <- SZ2(3) <- limC(SSZ);
(1.27.16)  SX = OFX + IR1*(H/SZ); <4>
(1.27.16)  SY = OFY + IR2*(H/SZ); <4>
(1.19.24)  P = DQB + DQA*(H/SZ); <4>
(1. 3.12)  IR0 = limE(P)
(1.15. 0)  SX0 <- SX1 <- SX2 <- limD1(SX);
(1.15. 0)  SY0 <- SY1 <- SY2 <- limD2(SY);
(1. 7.24)  MAC0 = P;
(1.31. 0)  MAC1 = SSX;
(1.31. 0)  MAC2 = SSY;
(1.31. 0)  MAC3 = SSZ;

[ 本帖最后由 hourousha 于 2014-7-1 19:19 编辑 ]