PCWatch--AMD與ATI的CPU+GPU姿態

Eji

http://pc.watch.impress.co.jp/docs/2006/0810/kaigai294.htm

AMD與ATI正在朝向CPU+GPU的方向前進，透過GPGPU的方式來強化未來CPU的咚隳芰俊?r
後藤推測，AMD與ATI的努力方向有兩種：

1. GPU直接透過bus接上CPU，一開始甚至可能是同package的不同dle；
未來則可能透過類似HT的方式接起來，這個狀況下programming技術與過去沒什麼不同，
優點也自然是相容性。

缺點則很明顯：以GPGPU而言，透過graphic API來進行非graphic工作本身就不是很有效率，
上述的方式並沒有辦法全面地發揮出GPU的咚隳芰俊?r

2. 所謂的"Cell Like"方式，將GPU的pipeline完全打散，融合進CPU的結構裡面，
一個一個shader就像是co-processor一般，優點是對所謂的"GPGPU"類的工作特別有效率。
GPGPU的特性當然就是可以大量平行化、方便利用GPU咚懔康墓ぷ鳎??荊PU對這些工作而言，
有著不少"贅肉"....重新組成像Cell這樣很適合走平行咚愕慕Y構，就會把這些工作跑得更好。

但是GPU本來針對繪圖用的結構被如此打散的話，
還要同時保有過去"GPU的特性"就會變得開始困難，那麼"本業"方面可能就會變得比較難兼顧。
其實說起來，上面提到"Cell-Like"這點，就會有種把Cell當成某種GPU的亞種般的錯覺；
其實Cell目前仍普遍被視為一個multi-core CPU，甚至是PowerPC+DSP的一種特殊結構而已，
後藤上述的說法還是有點怪怪的；而且在PS3的結構裡面，還是有一個標準的GPU--RSX。

只是如果我們把整個結構重新攤開來的話，後藤指的可能就是一個"很大的Cell+簡易Rasterizer"般的新結構，
這個結構就有很大的可能維持住接近shader的平行咚懔浚?约搬槍?L圖工作的適用性，
而上述的所謂"保有GPU的特性"的困難度鎖在，就相當於如何在SPE與EIB環狀bus上把傳統的shader有效率地執行這點。

從這點來看，其實NVIDIA和IBM已經算是比AMD和ATI更早接觸到這個部份，
並且在目前的製程條件下，拿出了屬於自己的解答了也說不定。

此外，後藤認為NV30當時NVIDIA已經遭遇過在管線內加入大量的通用咚阗Y源，
但是因此重新重組了管線的平衡度，而在結構上遇到了設計時沒有設想到的效率問題，
進而造成了對US結構採用與否的態度轉為慎重....

回到本文：
以AMD和ATI整合資源後的當面課題來說，應該會以減少額外內耗、儘早推出有效率的產品為重心，
所以一開始應該是將GPU直接on-die結合進CPU，然後未來才慢慢地重新整合GPU的各種設計重心，
設計出全新的CPU結構。

這邊有個有趣的地方：過去幾年內，GPU的功能翻新了許多次，每次都在相當短的週期內推出了大量的衍生產品；
相對起來CPU的結構變化與產品更新週期都較長，但是CPU的功能翻新的部份相對於GPU來說壓倒性地少，
所以比較起來有很長的時間在底層結構的最佳化上，而使得咦鲿r脈、耗電量等等的表現都比GPU來得好。
如果programmable shader持續進展的話，應該會在一段時間後達到某個功能上的平衡點，
之後就可能轉為對底層結構的最佳化，因此有可能造成GPU會在未來達到與CPU相去無幾的時脈。
上述ATI與AMD初期將GPU on-die結合進CPU這點，就可能變成某個2~3GHz的CPU core，
以及一個以數分之一時脈，如1/4的600~700MHz咦鞯腉PU core的不同狀況。

而後藤提到，GPU業界人士指出：
如果將Shader進一步最佳化、與某些傳統ASIC：如rasterizer等作咦鲿r脈上的切割的話，
則可能達成Shader的部分與CPU等速、而以ASIC數倍的時脈咦鞯臓顩r。
這也合於NVIDIA先前對G80的某些描述。

雖說GPU的發展還有很多可能性，但是終究是對咚愕牧硪环N手法；
因為同屬咚闫髦?剩?l展至此又將一些新想法注入CPU的發展上，
這其實也是相當有趣的事情。

vp

本人很喜欢Eji带来的各种资料，不过每次都在下面厚着脸皮写几句反调似乎有些冒犯楼主，不要见怪，呵呵，我又要罗嗦了：
上面讨论了一大堆，但是本质问题还是没有谈到:CPU和GPU存在的巨大的精度差别。GPU算出来的东西是让人眼睛去看的，因此一开始对精度要求不高，DX10之前能够完全遵守IEEE754单精度标准的似乎也没有谁可以算的上，不要说对于CPU所必须的双精度要求了。此外，GPU的分支预测能力和CPU也不在一个等级上。要是CPU和GPU做在一起，把GPU真正通用化，怎么解决这些问题？精度上去可以会大大增加Gate counts的，对于独立的GPU而言似乎没有必要。DX10之所以要统一精度，是因为之前存在的各种Z bias，Z fight等因为精度不统一所导致的问题，而不是真正认为GPU精度太低了，需要提高一下。因此就算提到了和CPU一样等级，那就必须放弃pipleline的数目，这个似乎是GPU不务正业的表现，呵呵。如果CPU和GPU精度不一样，那很多工作肯定就不能让GPU去做了。
真正有意义的是解决cpu对GPU的显存访问问题。如果有专门的总线连接CPU和显存就好了，就像CPU和内存那样。（访问显存再也不需要通过PCIE了，凡是总线就会有总线竞争，一个慢速的设备占着总线不放，你速度再快也得在后面等。）不过问题是CPU访问显存和GPU访问显存的竞争就出现了。怎么解决？FIFO或是双口RAM？总之都会大大提高成本。

vp

原帖由 RacingPHT 于 2006-8-12 20:22 发表


GPU的精度, MUL, ADD之类的, 都没有问题呀？而且作为Stream Processor, 浮点的NaN之类的Exceptions自然也没有什么意义的。唯一的区别是非线性函数, 精度比较低。但是这个似乎并不妨碍GPU核心作为协处理器的价 ...

GPU的精度当然有问题，很多贴图错误，闪烁其实都是精度引起的，需要在驱动里面专门对于这些场景打patch。这个时候用谁家的卡作为开发平台就很重要，因为开发者会以这家的卡为精度标准。

vp

原帖由 RacingPHT 于 2006-8-13 13:45 发表


错误和精确度不是一个概念. 很多硬件专用电路的东西结果确实不能控制的, 而可编程的Shader不可能有这样的问题. 我觉得对CPU整合比较有意义的, 也是Shader这样的可编程部件而已。

我说楼上的，在GPU中贴图错误很多就是因为各家显卡精度不同产生的。由于Z采用的是Z buffer而不是W buffer，在远景上精度会很低。如果各家的显卡精度不一样，那么在采用Z bias做精度补偿的时候会采用不同的补偿系数，可惜这个系数是应用程序给的，因此他用谁家的卡开发，就给出适合谁家的系数。其他几家必须在驱动里面对此做修正，这个就是最常见的Z精度导致的贴图错误。类似的还有Z fighter。为了解决这个问题，微软在DX10中就强制统一精度，不许太高，也不许太低，大家都一样，就没问题了。
如果你经常做一些底层的shader应用，很容易碰到这些问题的。

vp

一不小心发了两遍，呵呵，手动删掉一遍

vp

原帖由 RacingPHT 于 2006-8-13 14:22 发表


Z-bias和Shader一丁点关系都没有. 我说了, 硬件电路和可编程电路是不同的. 我不认为CPU应整合Z-buffer这样的部件。
Shader具体的精度, 直接看GPUBench就是。

汗，要是Transform的精度足够高了，还要Z bias干吗。