如果从光栅化处理器的角度来考虑‘3D硬件’的定义，那么最根本的定义就是，它接收的图元（primitive）坐标数据，是3D的还是2D的。
如果它接收的图元坐标信息，是3D的，无论z分量是以z值还是1/z存在都无所谓，那么它从设计上就是一个3D硬件，如果它接收的图元坐标，就是2D的，那么它只能称为一个2D硬件，因为图元的深度分量在进入光栅化时就给抹掉了。
只有当光栅化接收的坐标是3D的，才有Z/W缓冲用武之地、才有对纹理坐标、颜色等‘非透视归一化’信息进行透视矫正的可能。
因此如果从这个角度看，SS和PS在光栅化单元上讲都是2D硬件。两者在纹理采样的实现上不同，但这并不成为区分3D还是2D的关键。

至于几何变换部分，我觉得有SCU的土星，倒也不算没有为加速3D运算定制。
其实对于3D图形来说，几何运算部分，对灵活性的需求是很大的，所以第一代也就是DX7的T&L，其实基本就是过渡的半成品，到了DX8的可编程化的VertexShader，才算是真正堪用的东西。
而且直到DX9的VS 2.0，这个也没有和硬件硬性绑定。也就是微软做了个使用CPU的SSE指令的‘软处理器’，而且性能在当时还相当可用。我印象中当年Geforce4 MX就是没有硬件VS单元的。
对于Console而言，其实都比较接近于这个方式，包括后来的N64、DC和PS2，本质上都是拥有SIMD的协处理器。而比如N64那种，官方会提供软件封装好的3D运算lib，从形式上就更类似了。当然原因不太一样，微软它本来做的就是API；而N64是直接操作定点数SIMD的ucode太难以使用，所以官方不得不提供封装好的library，当然也就产生了广为人知的精度和速度矛盾的问题。

引用:

原帖由 SONIC3D 于 2020-9-24 20:20 发表
问题是土星的那个SCU本身其实更接近于一个可编程的DMA和总线控制器，对它的编程开发来作向量运算加速算是超规格使用，而且开发方面和给N64写ucode一样痛苦，这也是为什么Sega要封装SGL库的原因，和老任的封装是异曲同工。用来做向量加速运算本身更接近于给SH2作能力扩展，弥补超大量计算时弱鸡SH2的不足。只能说这机器设计时匀出了一个比较难用的偏方来半吊子解决实际应用问题，但不及PS1眼光放得更远，可能当时觉得家用机3D应用不会这么快，有这么点就足够撑到下一代。。。

另外GF MX440确实没有硬件VS/PS单元，VS/PS支持版本为0.0，但那时真正强制依赖可编程管线特性的PC游戏老实讲太少了，所以无所谓，卡便宜才是王道，但游戏机么没有什么向下兼容的累赘负担拖累的情况下其实还是超前点好，土星这方面是比较可惜的，如果能有哪怕2/3的Model-2能力，估计又是一个新世界。。。

所以我说SS属于'倒也不算没有为加速3D运算定制'，要说合理性前瞻性自然是不如PS的。
举GF4MX的例子，其实是想说明这么个情况：GF4MX毫无疑问是跑不了运用了PixelShader的程序的，但使用VertexShader的程序，却是可以跑的（VS并非必须和PS一同使用）。当然这时的VS不是由GF4MX跑的，而是MS的软件顶点流水线模块使用CPU里的SIMD单元（SSE或3dNoW）跑的。而众所周知，当初3dNoW也好，SSE也好，用途宣传都主打‘加速3D运算’，所以如果从道理上说，该模式也应该算‘使用硬件3D加速’的一种情况，只不过加速单元并非位于GPU内部，而是CPU里。我觉得这其实是有些类似于XBOX/GC之前的Console的。

[ 本帖最后由 hourousha 于 2020-9-25 00:43 编辑 ]

记得当初VF2 PC版一开始是没有3D加速的，不过开启阴影，Pentium2可以基本流畅运行，而PMMX 166就慢动作了。后来出了3D加速补丁，不过兼容性很成问题。
后来的东京番外地就完全没出过3D补丁。