Eji：

引用:

我是覺得如果它真的是96Gop/sec的話，會有點合不上....
尤其是它應該是用那個硬體排程把ops幹掉了，
所以我相信XGPU360應該不會有硬體mini-ops，因為它不需要。

48shaders x 2units = 96op/cycle。
應該不能再分割了。

Feldstein 先生的本意應該是說，4D和1D是可以分開运作的，
因為同樣一段話，TechReport似乎沒有解釋成96G ops。

----
話說 全硬體排程 老實講應該才是精華所在....

首先，NVIDIA對co-issue的理解與ATI顯然有很大的不同，
ATI認為3+1的關係是要能顧及1D，NVIDIA就連2D都做進去，
變成有一個2+2D的shader unit ....
但是從C1做成4D/1D並且可以分離?#092;作來看，
ATI顯然不認為需要做2D的部份。

於是，透過4D 和 1D的獨立?#092;作，以及完整的硬體排程，
Shader Pool 就可以依照Vertex / Pixel的順序，
把 job queue裡面的東西處理完，
看來Program / Driver這邊完全不需要理會GPU有幾個VS，幾個PS....

snakejoe：

引用:

QUOTE(Eji @ 2005-05-20, 19:32)
話說 全硬體排程 老實講應該才是精華所在....

於是，透過4D 和 1D的獨立?#092;作，以及完整的硬體排程，
Shader Pool 就可以依照Vertex / Pixel的順序，
把 job queue裡面的東西處理完，
看來Program / Driver這邊完全不需要理會GPU有幾個VS，幾個PS....

硬體排程, 再加上 firingsquad 報導所說的.
那這個 shader pool 的實用率應該很高啊.

http://www.firingsquad.com/featu ... terview/default.asp

引用:

So you have 64 threads, and it’s all controlled by hardware so it’s not like the programmer knows one way or another about threading at all, and the threads here are things like vertex buffers or pixel programs and the hardware just keeps the same [inaudible] in a thread buffer and we can just switch back and forth between the different threads. That way if we’re waiting for data from a vertex program or vertex array we can go ahead and work on a pixel program or we can work on a second vertex or whatever, a different instruction.

Eji：

引用:

是啊，應該會很高啊。
反過來說，沒有\"有效的\"硬體排程的話，
就只好靠co-issue硬湊了。

所以即使看起來是136ops，但是不見得96ops這邊效率會輸；
反過來說，RSX的那個怪op數量，大概是目前RSX唯一可能可以用來與XGPU360抗衡的暗樁。

(如果那真的是 Pixel Shader run at high clock的話)

991060：

引用:

如果不考虑整数和index的话，2D应该比1D更有用一些，image space里面很多操作都只和2D相关，因为它本身就是一个平面，到现在我也想不到这个1D能拿来干什么。

cho：

引用:

如果撇除那个1D，shader ops就会掉一半到28G shader ops， 1/4 RSX声称值。

1D在这里可能是跑PS的时候做alpha blending的。

或者这样：

“In DirectX& 1D textures are emulated by 2Dtextures of Nx1 dimensions”

Eji：

引用:

話說效率的部份上面只討論到排程和單元利用率，
可是單元本身的运作效率似乎是另外一回事....

NVIDIA的態度是PS單元跑VS會慢，因為PS還和Texture Cache?#092;作有關；
這回C1的單元看起來像是R3x0的VS為基礎(4+1D)演進來的，
不知道和這部份有沒有關係。

話說如果排程能力進一步強化的話，不知道有沒有辦法可以利用具備co-issue的shader unit呢？

ibelieveicandie：

引用:

随便找了一段ps (HLSL result)
****************************************
Target: GeForceFX 5800 Ultra (NV30) :: Unified Compiler: v66.93
Cycles: 31 :: # R Registers: 2
Pixel throughput (assuming 1 cycle texture lookup) 64.52 MP/s
=========================================
Shader performance using all FP16
Cycles: 31 :: # R Registers: 2
Pixel throughput (assuming 1 cycle texture lookup) 64.52 MP/s
=========================================
Shader performance using all FP32
Cycles: 31 :: # R Registers: 2
Pixel throughput (assuming 1 cycle texture lookup) 64.52 MP/s
****************************************
PS Instructions: 26
ps_2_0
def c4, 0, 1, -2, 3
dcl_pp t0.xy
dcl_pp t1.xyz
dcl_pp t2.xyz
dcl_2d s0
texld r1, t0, s0
nrm_pp r0.xyz, t1
mov r2.z, c4.y
add r0.w, r2.z, c3.x
nrm_pp r2.xyz, t2
rcp r3.w, r0.w
dp3 r2.x, r0, r2
add r2.w, r2.x, c3.x
max r0.w, r2.x, c4.x
mul_sat r3.w, r3.w, r2.w
mad r2.w, r3.w, c4.z, c4.w
mul r3.w, r3.w, r3.w
mov_sat r5.w, r0.w
mad r4.w, r5.w, c4.z, c4.w
mul r5.w, r5.w, r5.w
mul r4.w, r4.w, r5.w
mad r3.w, r2.w, r3.w, -r4.w
max r2.w, r3.w, c4.x
mul r2, r2.w, c2
mul r0.xyz, r0.w, c1
mov r0.w, r2.w
add r0, r0, c0
mov r2.w, c4.y
add r0, r2, r0
mul r0, r1, r0
mov oC0, r0

似乎1D指令比2D多不少...

hdyfale：

引用:

watch.jp Xbox 360-GPU讲座

http://www.watch.impress.co.jp/game/docs/20050520/x360_g.htm

Xbox 360-GPUの組み込みメモリの秘密～3Dグラフィック処理機能が内蔵された特殊なメモリ、それが10MBのeDRAMだ!

「我々のXbox 360-GPUは家庭用ゲーム機向けのGPUとしてはどう考えても最強だ」(Feldstein氏)

PS3のSPEもかなりユニークなグラフィックス処理の未来像を示唆してくれたが、Xbox 360-GPUは、そのGPUの中にSPEがあるような印象を抱かせ、可能性という意味に置いてはPS3に優るとも劣らない。

浪漫跑车：

引用:

PS3真能带入次世代？除非性能比XB360强超过4倍，否则连1080P都无法胜任，自己算算1080P和720P下像素填充率一项的差距吧，每桢需要的像素都差2.25倍，就凭那可怜巴巴的22.4G的带宽？平面材质相差二次方倍，立方体贴图，体积材质差三次方倍，而且还是几何级数往上涨，除非是火星科技。而且CELL毕竟是CPU，浮点运算再强也无法取代着色器和像素引擎，对材质处理也毫无用处，充其量是个几何运算的线性加速器。

都摘自GZeasy