Urbi et Orbi: Radeon HD 2000 serija

destroyer2k od kar postaš tukaj se tako selfpwnaš, da je joj. GDDR4 naj bi imela le XTX ker je ta pomnilnik VELIKO bolj drag zaradi nerazširjenosti. Memory controller v R600 podpira tako GDDR3 kot GDDR4 in valda bodo na XT zaradi cene dali GDDR3. Na koncu jih je GDDR4 še fino zj**al tako da XTXa še nekaj časa ne bo. So pa že nardil eno GDDR4 grafično - X1950XTX. Limit pri navijanju RAMa je IIRC 1142 MHz in niti sam hipro5, največji navijalec ATI grafičnih tega ne more preseči. Čudne stvari pač.

Ali je kdo prebral oceno kartice v Jokerju ? Dobil sem obcutek kot da berem od druge kartice kot v vseh spletnih reviewih... predvsem drugace so jo ocenili, drugacni so bli grafi fpsjev in tudi drugacne potrebe po moci so ji dodelili kot pa na internetu...

Tudi sam sem opazil zelo različne rezultate in zaključke pri branju na TweakTown, AnandTech ter Beyond3D.

Da ne bom iz spomina vlekel in se tudi zmotil, ter tudi ne bom prevajal word-to-word, bom copy/paste iz AnandTech-a en odstavek:

Comparing Shader Architectures: R600 vs. G80

The key to the architecture comparison is to realize that nothing is straight up apples to apples here. We need to look at how much work can be done per clock, how much work is likely to be done per clock, and how much work we can get done per unit time.

First, G80 can process more threads in parallel: 128 as opposed to R600's 64. Performing work on more threads at a time is one very good way of extracting overall parallelism from the problem of graphics. There are millions of pixels in every frame that need to be processed, and if we had hardware large enough we could process them all at once.

However, more work (up to 5x) is potentially getting done on each of those 64 threads than on NVIDIA's 128 threads. This is because R600 can execute up to five parallel operations per thread while NVIDIA hardware is only able to handle one operation at a time per SP (in most cases). But maximizing throughput on the AMD hardware will be much more difficult, and we won't always see peak performance from real code. On the best case level, R600 is able to do 2.5x the work of G80 per clock (320 operations on R600 and 128 on G80). Worst case for code dependency on both architectures gives the G80 a 2x advantage over R600 per clock (64 operations on R600 with 128 on G80).

The real difference is in where parallelism is extracted. Both architectures make use of the fact that threads are independent of each other by using multiple SIMD units. While NVIDIA focused on maximizing parallelism in this area of graphics, AMD decided to try to extract parallelism inside the instruction stream by using a VLIW approach. AMD's average case will be different depending on the code running, though so many operations are vector based, high utilization can generally be expected.

However, even if we expect high utilization on AMD hardware, the fact remains that G80 has a large clock speed advantage. With the shader core on G80 pushed up to 1.5 GHz, we could still see some cases where R600 is faster, but the majority of the time G80 should be able to best R600 on a pure compute basis.

This overview still isn't the bottom line in performance. Efficient latency hiding, good scheduling, high cache utilization, high availability of texture data, good branching, and fast and efficient Z/stencil and color processing all contribute as well. Where possible, let's explore those areas a bit more.

vir: anandtech.com.


--

Vprašanje je, koliko SPjev bo lahko v prihodnosti compiler optimalno zaposlil pri prihajajočih igrah. Tudi driverji so še zelo bogi. Čeprav nisem nek strokovnjak, se mi zdi arhitektura kar v redu; sploh kot podlaga za naslednjo generacijo, kjer bodo najbrž upoštevali, kar so tu falili. Prehod na 65nm, optimizacija arhitekture in pa obvezno boljši izkoristek na Watt. Če bodo res dobro poskrbeli za te stvari (no, še kakšen AA specific hardware bi prav prišel - ker pri R600 za AA skrbijo kar SPji), potem se nam obetajo zelo dobre kartice. Kajti moramo upoštevati, da sta tako G80 kot R600 prva serija dx10 kartic. Kaj se je pa v preteklosti pokazalo za vsako prvo serijo, pa tudi vemo: takratne igre so nove kartice dobro prebavljale, a prihajajoče so bile pa čisto druga pesem.

AMD mora s splavitvijo novih procosorjev nujno poskrbeti za dobre mid-range kartice in glede na stanje mid-range nvidinih kartic to ne bi smel biti problem. Če mu to uspe, bomo vsaj malo lažje pozabili na "črno luknjo", ki je trajala kar precej časa - leto dni?

Moram omeniti še mobilne verzije. To je precejšen trg, ki ga večinoma obvladuje intel in ne bi škodilo, če bi se mu odrezalo kakšen kos torte. A glede na porabo 2900XT, bodo morali ATIjevi inženjirji pošteno pljuniti v roke. Upam da čim prej in čim bolj (pljuniti v roke).

HD2600XT je 65nm in ima bojda nizko porabo - samo kaj to pomaga če ni dobavljiv.

p.p a ni gddr 4 cenejši

Osnoven problem arhitekture R600 je v tem, da se zanaša na to, da je znotraj enega shaderja koda zelo neodvisna med sabo (in lahko več inštrukcij spakiraš skup) ali pa že kar vektorska sama po sebi. Glede vektorskih inštrukcij drži (do DX8 oziroma raje DX9 je bila večina shaderjev takih), glede neodvisnosti pa...
Tipičen primer, ki ga driver gotovo vidi vsakič ko poženeš kateri koli špil:
dp3 r0.w, r1, r1
rsq r0.w, r0.w
mul r1, r0.w, r10
Normalizacija vektorja, trije ukazi, nagradno vprašanje: koliko ciklov rabi R600? Tri cikle (isto kot ostali Radeon-i):
1. dp3 (_RGB_)
2. rsq (S____)
3. mul (_RGB_)
Koliko ciklov rabi G80? Sedem:
1. 2. 3. dp3 (mul, mad, mad)
4. rsq
5. 6. 7. mul (mul, mul, mul)
Hitrost, če delaš samo takle segment? R600: 15.829G pixlov/s, G80 GTX 24.685G pixlov/s in G80 GTS 16.457G pixlov/s. Efektivnost R600: 46%, G80: 100%.
In ni šans, da bi tistole kodo stisnil v manj kot 3 cikle. Načeloma lahko zraven unega rsq še kaj prišvercaš, tudi pri dp3 in mul lahko še kakšen poseben ukaz prišvercaš, vendar jasno: samo če ne potrebuje rezultata tega delčka kode, oziroma je v bistvu podatek za to kodo.

Zdej daljši ko je shader več možnosti je, da se bo našlo nekaj neodvisnih ukazov, ki se jih bo dalo stisniti v prejšnje. Ampak je že HLSL compiler presneto premetena zadevica in bo te stvari že sam od sebe hudo pametno poštimal. Sem se zadnjič ubadal z enim vertex shaderjem (teksturiranje iz vertex shaderja), ki je na GF7 nekaj kar je za eksperimentirat, uporabno pa ni kaj zelo (na G80 in R600 bi bilo to hudo hitrejše ).
Ideja je podobna, pogeldat v teksturo, in se potem še čim dlje tistega ne dotikat (kakšne 20 inštrukcij), sicer bo vertex shader moral čakat da pride rezultat nazaj. Pogledam HLSL kodo: ah dost aritmetike, to ne bo problema skrit. Pogledam kodo, ki jo generira HLSL: tretji ukaz gre teksturirat, četrti že rabi rezultat, 35. ukaz teksturira 36. že rabi rezultat. WTF? In potem grem gledat ukaz za ukazom ene 3x čez in ugotovim, da enostavno ne morem ničesar prestavit in da je shader "as good as it gets," čeprav spi celih 100 ciklov in počne nekaj uporabnega 60 ciklov...

Kar hočem povedat je to: da ATI-jev compiler iz D3D9/10 shader kode v njihovo mikro kodo morda še ni optimalen... Ampak mu že Microsoftov HLSL compiler naredi tako optimalno kodo, da boljše ne bo dobil.
Vse "shader" grafične (razen GeForce 8x00) od GeForce 3 pa do Radeon HD2900XT so VLIW (very long instruction word), kar je bilo včasih hudo cool, ker si lahko z enim ukazom GPU-ju povedal cel efekt, ob katerem je potem folk sline cedil (recimo bumpmapping je tipičen primer). ATI se je ves ta čas držal zelo enostavnih cevovodov. ČISTO VSI (!!) njihovi čipi R200 (Radeon 8500), R300 (Radeon 9700), R420 (Radeon X800), R520 (Radeon X1800), R580 (Radeon X1900) so 3D+1D, kar pomeni dva ločena ukaza v enem VLIW ukazu. NVIDIA je imela tak design do GeForce FX (torej GeForce 3 in GeForce 4).
GeForce FX je bil sicer tako skropucalo, da sam VLIW ni nikoli povzročal problema. GeForce 6 in GeForce 7 pa nista bila več taki skropucali in ob novih igrah se ravno ta VLIW pokaže za HUD problem ("kolcanje" v Tomb Raider Legends, če je kdo igral pred patchom v driverjih ), ki nima sam po sebi nič s hitrostjo GPU-ja. Kako je s tem na GeForce 7: globalno znano, da ima vsak pixel shader dva ALU-ja (dva ločena VLIW ukaza)... Malo manj globalno znano pa je da je vsak ALU sestavljen iz dveh delov in že osnovna ALU-ja nimata oba enake funkcionalnosti (GF 6 in GF 7 prvi ALU prevzema vlogo TMU-ja, GF 6 prvi ALU zna množit, drugi seštevat - za tiste, ki hočejo detaje ). Compiler, ki sedi v driverju in prevaja kodo, ki jo dobi od D3D (ali OpenGL, da ne bomo rasisti), v tiste VLIW ukaze mora sedaj tisto precej optimalno kodo razpalcelirat na enih PET (!!) različnih enost, kjer vsaka zna nekaj, nobena pa ne zmore vsega.
Zdej kolk dobro razpalcelira je pa odvisno od tega koliko časa si vzame... Problem pa je ker to hitro postane milisekunda ali dve ZA VSAK SHADER. Pri 60 fps je en frame dolg 16 milisekund, sedaj si pa zamislite kaj se zgodi, če mora ta compiler sredi frame-a prevesti nekaj shaderjev (kar traja nekaj milisekund)...
In ravno to je ATI-ju uspelo... Njihov compiler v driverju mora shader kodo spravit na 5 enot (na srečo samo dveh različnih tipov).

Upam da je kolikor toliko razumljivo, zakaj se mi zdi, da v splošnem kakšnih čudežnih driverjev ni za pričakovat (bodo pa driverji, ki bodo sem in tja dvignili performance, tako kot še za vsak drug čip).

Edini optimalni primer, ki se ga spomnim iz glave: množenje N*M matrik (to so sami podivjani ukazi - MAD ). Oziroma ker veš nekaj o shaderjih (tko en random shader, ki ne počne nič pametnega):
mad r0.xyzw, r1, r2
rsq r3.w, r3.w
dp4 r4.xyzw, r5, r6
rsq r7.w, r7.w
mad r0.xyzw, r0, r4
mad r1.w, r0.w, r3.w, r7.w
Trije cikli na R600 torej: 15.829G pixlov/s, 15 ciklov na G80 GTX: 11.520G pixlov/s, G80 GTS: 7.680G pixlov/s.
Rabiš veliko medseboj neodvisnih ukazov (torej da naslednji ukaz ne potrebuje rezultata prejšnjega), vedno vsaj 5 (operacija na vseh komponentah registra so že štiri).

Mene zanima če ima že kdo slučajno to kartico in jo je stestiral ali vsi pač tako na pamet oz. iz spletnih testov govorite kako je ta kartica super/podn.

LP, Vasilij

Kul, komaj čakam da boš dal gor benche. Jaz tem spletnim testom bolj pogojno verjamem. Dobiš občutek da so eni na Atijevi strani drugi pa na Nvidijini (Pač moje mnenje).

Nekaj slikic za poskušino:

Kaj je tvoja?

JA!

Kaj je tvoja?

JA!

Res lepa grafa Komej čakam, da jo še sam kupim

>Zdaj samo še čakam nove gonilnike in ati tool pa bo!

To verjetno misliš , da čakaš na najnovejšo različico drv in atitool, ki bodo bolj optimizirani za HD2xxx kartice in računaš na dodaten pospešek