Procesory AMD 15h "Bulldozer&Bobcat"- info, testy, spekulace

[flanker]

ten test BF3 je skutečně zajímavý! Hra je graficky středně náročná, což je plus a CPU...hodně závislá na L3, protože ten propad z x4 940, kdy je hra ještě dobře hratelná, na x4 620 je brutální....

[uber]

myslis, ze je to opravdu tou L3? je tam opravdu velky rozdil, mozna bych rekl, ze nejaka chyba mereni - koneckoncu neni to regulerni benchmark, jen takove zbastlene mereni.

Az vyjde plna verze, tak mam nachystanou metodiku jak zmerit vykon procesoru i gpu, nicmene jsme omezeni tim, co tech par lidi co je v repre ma za HW. Porovnat hlavne chci amd X4 a X6, i5 750, 2500k, i7 930, i7 970 a pokud se dostane nekdo z nas k bd

jinak jeste ten test BF3 byl proveden na mestske mape operation metro 16v16 a byla vypla destrukce, coz v bc2 se pocita na cpu ... lze ocekavat slusny propad fps na velkych mapach s letadly, tanky, vrtulniky a hlavne 64 lidmi na serveru. takze lidi co maji quady nebo x4 budou mit nejspis problem - tady je dulezite podotknout, ze BF serie je pohodlne hratelna na 80fps, kdyz je fps min, nebo jsou propady tak je to ve spojeni s akceleraci na mysi docela neprijemne ... narozdil od cod a spol

[HEAD]

Ten naskok i5 2500k v bbc2 je celkem brutalni a to tam mel jeste nejhorsi grafiku.
Jinak v bf3 predpokladam, ze 4jadrovej i5 2500k prekona 6jader(phenom2) od amd jako nic i kdyz hra bude vyuzivat 6 jader.
Taky sem zvedavej na bulldozer.
Uz se nemuzu dockat na launch a hlavne doufam, ze ty cpu ve hrach zas nebudou testovat s 5770 .
To chce gtx580 a jeste nakou oc edici...
Taky by to chtelo aby na extrahw uz konecne vymenili dneska tezce lowendou gtx280 za gtx580 a pretestovali vykon cpu s ni.S tou gtx280 je to taky onicem.
V Cr ty testy cpu nestojej za nic(co se tyce vykonu ve hrach).

[DOC_ZENITH]

Ono by to o něčem bylo, stačilo by hodně snížit rozlišení, aby se zbavili GPU limitu. Ale to by zas pod článkewm byla tuna komentářů že to nemá reálnou vypovídající hodnotu. Má, ten CPU totiž ve finále ovlivní hlavně propady a min. fps, takže pokus se ten stav dá nasimulovat / zvýraznit / obenchamrkovat takto, tak proč ne.

Ono by to taky chtělo testovat ty hodně CPU závislé hry, či to prostě nasimulovat. Ala upravit ini a spawnout 128 botů v UT, pak to otestovat ve world of conflict, Shogun 2, Starcraft 2, pár mmo hrách (kde se to opravdu těžko testuje protože nemívaj benchmark a situace ve hře je vždy jiná a když tam bude 60 m ísto 100 postav budou ýsledky naprosto mimo..... je to hold těžký no.

[uber]

v bc2 se hraje s tim configem co je na tom screenu, tzn vsechno na low, pak i na 1080p neprekroci zatizeni grafiky 40% ... hra je brzdena jen cpu, a to konkretne jednim jeho jadrem, kde 2500k exceluje, default ma asi 50% navic na pretaktovany thuban. V alfa BF3 se grafika nedala nastavit, jen rozliseni, bylo to vicemene nastavene na high, takze vetsinu lidi brzdilo gpu s gtx285 a thubanem jsem mel 100 % gpu, a 40 % cpu, spoluhrac s 930 a 580 mel oboji na 100%

[DOC_ZENITH]

U CPU se nedá měřit vytížení procenty. V rendering procesu jde CPU vždy napřed, grafika může částečně idlovat jen když jí CPU nestíhá živit. CPU nemůlže idlovat nikdy, vždy musí bejt na 100% protože to prostě počítá, a když je výkon nazbyt tak prostě udělá více fps, ne že by si začal idlovat. Když někdy je CPU load pod 100%, tak to znamená že hra nedovede využít plnej potenciál toho cpu, prostě neni dostatečně dobře optimalizovanej multithread. U singlecore cpu a starších her máš cpu load vždy 100%, bez ohledu na framerate či cokolic jiného. Tak to má bejt, a to že to tak někde není značí ten problém s optimalizací.

Nejedná se ale jen o hry, třeba komprese či některé programy na enkóding nevyloadujou jádra na to co v nich je. Maj třeba funkční multithread, ale pořád špatnej, ala dovedou si práci rozdělit na mnoho threadů ale ty samotné thready vůbec nejsou optimalizované, čekaj na sebe či prostě nedovedou využít potenciál či instrukce CPU. A právě v takovýchto případech může vynikat HT, které při super dobře napsané aplikaci je k ničemu a naopak škodí.

+ Jak bylo zmíněno předtím, v hrách je dost často mutithread udělán tak, že je thread pro AI, thread pro fyziku, thread pro zvuk, bal bla. Ale je jen jeden thread pro render, pro tvorbu 3D objektů a posílání jich do grafiky, a tohle je hlavně o FPU a pak to leží na tomhle jednom threadu kterej se stává bottleneckem, a CPU defakto musí co nejvíc zabrat na tomhle jednom threadu, protože ostatní to poměrově vytěžujou tak málo, že je klidně můžeš vtěsnat na druhé jádro u dvoujádra. (viz super herní výkon sandybridgové I3 ,které je lepší herní CPU než Thuban). Některé strategie jako je world in conflict co škálujou ideálně jsou super náročné ne na počet polygonů a rendering, ale na AI, protože se tam pohybujou stovky jednotek, a vzhledem k tomu že jedna jednotka = jedno AI, tak to se dá paraelizovat briliatně. Průser jsou hry kde nejde o AI, nejde o fyziku ,a ten thread pro rendering se stane jediny a kritickym bottleneckem. Typicky tohle jsou onlinovky, ale dá se to na některejcdh místech pozorovat i v Crysis, ačkoliv je to hra o které se dá říci že je multithread a dá se rozject plynule na Pentiu 4.

Dokud se nevymislí herní engine, kde samotnej render thread bude multithreadovej (jo to jsem napsal píčovinu, ale tohle přesně musej vyřešit). Z multithreadovat ten thread co vede od enginu přes API do GPU, ten co tam posílá geometrii. Co si dobře pamatuju tak DX11 toto už umožňuje, ale vzhledem k tomu že vše jsou konzolové porty, tak se toho asi jen tak nedočkáme. To se spíš dříve dočkáme full SW renderingu jak to předpovídá Epic.

Geometrie je prostě průser. Dam příkald. 3Dfx voodoo1, má 1 milion trianglů za sekundu. To uživá tak Pentium MMX, či ranné Pentia 2 zajistěj že karta neni nikdy CPU bottlenecked. 3Dfx Voodoo3 má 10 milionů polygonů za sekundu. To dokázal uživit aby nikdy nebyl CPU limit až tak K7 na 2Ghz ( tim myslim 2Ghz čisté, ne XP2000+). Geforce 2 ultra má 25 milionů za sekundu. (a teď už to budu střílet ne přesně ale zhruba jak si to pamatuju). Geforce 4TI (první dvojitej vertex shader) má 60. Geforce 6800 ultra má 400. Radeon X1800XT má tušm kolem 650. X1950XT kolem 800. R600 bylo první GPU co trhlo miliardu. O G80 se traduje že byla v tomhle slabší protože měla bug, ale vzheldem k tomu že se k tomu v praxi nikdy ani nepřiblíží, tak se ten bug neprojevil. Koukněte se jak to jde nahoru. K 10 mil jsme potřebovali 2Ghz K7. CVo potřebujeme k 1 miliardě co nám nabídle R600? I7 tak na 40Ghz? Tady je ten kámen úrazu. Ta sběrnice, PEG16x, doslova idluje, po ní maj téct tyhle data, proto rozdíl mezi PCI-E 16x, 8x, někdy i 4x je u grafik mizivej, proto přechod z AGP na PCI-E ve své době nepřinesl žádnej boost výkonu. Protože ta geometrie neni, CPU jí nestíáhaj podávat. Teselace je jeden z pokusů jak to zachránit, ala že si tu geometrii bude GPU dodělávat samo aby se CPU ulevilo a to mohlo počítat jen základní skeleton model. Ale jak je vidět i samotné GPU se tim docela dusí, jejich teselační jednotka neni o tolik rychlejší jak CPU samotné ( v případě ATI ), u NV je silná celkem dost ale kolik jich tam je a kolik na to padlo tranzistorů. A pozor, teselační jednotka a její výkon se nerovná geometrická prostupnost. to že Cypress je slabej v Teselaci neznamená že by měl málo FPS kdyby do tý karty ty data dorazily v dostatečné rychlosti z CPU.

Prostě se musí změnit engine a kompelt celá API aby se s timhle geometrickym bottleneckem něco pohnulo. Vše co se od roku 2000 vejš v GPU děje je jen snaha tenhle bottleneck ňák zamaskovat. Příchod TnL jednotky se více či měně úspěšně pokusil převést nasvětlení scény na GPU, pak shadery... se nám sanžej vytvořit dojem vodní hladiny protože nemáme CPU sílu na to jí vymodelovat a animovat geometrickou cestou, bumpmapy... se nám snažej vytovřit dojem nerovného povrchu na rovném protože naše CPU nebyly schopný tolik geometeie protlačit, normálový mapy, to samé... atd, atd.... teselace.... o tom už jsem mluvil... atd, atd. Prostě CPU jsou bottleneck grafického pokroku a furt je tu tenhle jeden render thread, dřepící na síle single thread FPU výkonu a ten tu je od dob počátku akcelerovaného 3D rederingu a nedovedou s nim pohnout.

Ideální herní CPU by vypadal asi tak, že by měl mnoho menších klidně slabších ALU jednotek, řekněme 8. Poměrně malá L1, poměrně malá L2, L3 by ani nebylo nutná, ale v budoucnu jí tam dát můžeme. Nebyly by moc super rychlé na takt ani vyspělé, 3IPC by stačily, jen ať moc nezabíraj prostoru a netopěj, a tak 50% čipu by byla jedna obrovská super silná FPU jednotka, která by měla vše co je jen možné aby se jí zvedl výkon + by obsahovala něco jako interní sheduler či HT, a každá z těch malejch ALU jednotek by mohla využívat její služby, kdyby thread požadoval instrukce využívající FPU. A díky tmu že by byla jedna a super silná by se ten jeden thread co potřebuje to obrovskou FPU sílu, do toho mohl pořádně opřít. Takovejhle CPU, vymyšlenej timhel způsobem, by byl nejrychlejší herní CPU v těch současnejch geometricky zastaralekch enginech.

Ale jde o to hlavně změnit SW. Ne dělat HW tak aby na něm běhal dobře totálně neoptimalizovanej SW. Jako příklad mohu uvést Uncharted sérii her z playstation 3. Tam GPU, protože je hodně slabé, toho moc nedělá, naopak Sony to zaposnzorovalo tak aby ten engine co může dělal přes to silné CPU, a tak se tam dočkáš na postavách takového polygon countu a tak solidně vypadajících scenériích, jaké nejsou v nej. PC titulech a to to má 256MB ram a GF 7600GT. Dávám to jen jako příklad že když se chcce, někdo to zaplatí a zašťítí, tak to jde. Ale.... SW inženýrům se moc nechce, oni se vůbec neradi učí, jsou zaboxovaní a zabednění ve svém světě, a doslova maj panickou hrůzu že by mohl vyrůst svět jinej a lepší, protože oni se naučili věci programovat takhle... a odmítaj a dupou do země každého kdo by se snažil přijít s něčim průlomovym co by totálně změnilo situaci a posunulo výkon jinam, protože pak by se oni, kdo neovládají tyhle nové způsoby, stali nadbytečnýni a nepotřebnými.

[Hladis]

Snad jen jedina MMO mela kdysi Bench. Byla to nejaka Final Fantasy. Tam se to myslim snazilo nasimulovat hromady avataru a bylo to ve sve dobe sakra narocny. Bohuzel ostatni MMO zadny benche nedelaji, nijak se netestuji a nejak relevantne je otestovat ,aby se zachovaly podminky pro kazdy test stejne ,je skoro nemozne. Takova TERA kdyby mela Bench.....

Nejsem pritelem testovani her v nizkych rozlisenich. Sice to dobre skaluje ,ale vypovidajici hodnota neni uplne nejlepsi nebot takhle nikdo nehraje. On se stejne ten rozdil u minimalnich FPS v CPU narocnych hrach projevi i ve vysokych detailech a rozlisenich.

[uber]

wall_of_text

predpokladam, ze narazis na me neomalene tvrzeni o tom, ze me brzdi grafika "s gtx285 a thubanem jsem mel 100 % gpu, a 40 % cpu" ... nicmene ja verim tomu, ze kdyz bych tam dal 580 misto 285, tak stoupnou fps z puvodnich cca 50 na 70-110 co mel kolega na kombinaci i7 + 580 (vychazim z vysledku toho ruskeho testu, kdy thuban dosahoval stejnych fps +- jako ta 930)

co se tyka tohoto tvrzeni: "CPU nemůlže idlovat nikdy, vždy musí bejt na 100% protože to prostě počítá, a když je výkon nazbyt tak prostě udělá více fps, ne že by si začal idlovat", tak se me to nezda, delal jsem pred mesicem statnice z cisc a risc, ale stejne spoliham na selskej rozum a empiricke poznani, kdy do kompu strcim 8800gts + thuban a v bc2 mam 50 fps a cpu load okolo 30 %, pak tam dam 285, fps stoupnou na cca 100, zatizeni cpu kolisa okolo 85 %... mozna ze jsem te jen nepochopil, to pak sry


ad testy bc2/bf3 ...myslim, ze se muze klidne testovat v hd, ale snizit detaily na min, resp pouzit esport config

[uber]

abych svoji myslenku podporil, tak tady jsou vysledky dvou lidi z tymu, jeden ma i7 950 + 560ti, druhy i7 960 + 580
http://postimage.org/image/2lcof1gzo/
http://img687.imageshack.us/img687/1273/highbf3.png

[Trovaricon]

nedalo mi nezareagovat dlhym prispevkom.
DOC_ZENITH vazim si ta aj na inych portaloch koli odbornosti v HW oblasti, ale predtym ako sa zacnes rozpisovat o SW stranke, tak sa aspon opytaj nejakeho znameho, ci to ma aspon hlavu a patu.

1. Geometriu NERATA CPU ani ju na kazdy frame neposiela do GPU !!! Uz som to v tejto diskusii raz pisal (Zaroven s otazkou: co si predstavuju diskutujuci pod pojmom "geometria" ?). Skinning(animacia postav - kostriciek) je rieseny bud cez CPU alebo GPU (zalezi na platforme a planovanom vytazeni GPU/CPU inymi castami programu - napr. niektori na XBox360 preferuju CPU ini GPU skinning) - aj preklinany Lineage 2 to pri zasktrnutom GPU animation rata cez VS 2.

Staticka geometria sa natlaci do vertex buffrov a kresli sa scena bez nasledneho prenasania co len jedinej suradnice nejakeho objektu (dynamicke objekty sa daju riesit roznymi sposobmi napr. priamym updatovanim dynamickych VBuffrov - pripad Lineage 2 ak je GPU animation nezaskrtnuty).

2. Renderovat z viacerych vlaken ? To je imo synchronizacna kravina.
Renderovat v D3D =
Nastav texturu(abc)
Nastav render state(alfablend, off)
Draw primitive (vertex buffer pozicia, dlzka)

Ze niekto chce, aby vas zaroven funkcia v danom vlanke aj skrabala za uchom je vec ina...

kolko je tam FPU vypoctov ? Na aku rit je dobre toto delit na viac vlaken ? Co je realny problem takeho "renderovania" ? (vid. obrazky) Kazde volanie na vykreslenie (+nastavenia stavov) stvorca s vyslednymi stranami na rendertargete 2 pixely je na pomyselnej prehistorickej D3D kompatibilnej grafike otazka rychlosti samotnej grafiky (vymyslena 50 rokov stara DX grafika). Aka je skutocnost ? Keby som mal sceny vykreslovat tymto sposobom, tak to volim spravit cele na CPU a poslat do framebuffera hotovu bitmapu.

Kazde volanie ma relativne velku latenciu. Program>DX API>System>CPU>"lagfest" PCI-e>Grafika
Takze moju 100TFlop grafiku a 1TB/s PCI-E si mozem niekam strcit. Pre laikov: je to ako keby ste chceli zistit, kolko je 1+2: mam spoluziaka, ktory ma znameho v druhej triede, ktory je s osobou, od ktorej chcem vysledok, kamarat. Vysledok dostanete za aky cas ? 2 minuty ? (Aj to len v pripade, ze vas jedna z tych osob s takou poziadavkou niekam neposle )

L2 vykonava prd FPU vypoctov - preco su take rozdiely medzi CPU ? Co tak zacat trochu odbornejsie ? Moja teoria: rozne platformy (nie len CPU ale komplet) maju vyrazne odlisne krivky dopadu na vykon ak pridavame "dummy" D3D volania resp. su nachylne na "call spam".

MMO hry padaju na pouzivani 3rd party enginov... A totalne to zabijaju svojim "tunenim enginu". V tutoriali na Direct3D je renderstate manager (aby ste neposielali volanie na nastavenie rovnakeho stavu ak uz je nastaveny), t.j. amater do svojho lolenginu ho dost casto implementuje - skuste si prepnut D3D9 do debug modu a zistite, ze "profici" si s takymi malickostami nerobia starosti (debugview sa utopi vo warningoch)

toto je dnesny vysledok enginu, s ktorym sa s*ru pred ocami ludi uz, neprehanam, 10 rokov (cas, ktory je VYPUSTENY na trhu). L2 "CPU limited" aj na 10GHz CPU ? samozrejme... Chcete navod ako na to ? (warning: rovno pochopia len ludia, ktori aj tak vedia, o com je rec).

EDIT: MMO test (Lineage 2 IL) server-side aj client-side je "in development"
EDIT 2: Vravi sa, ze kazda minca ma dve strany. Bavime sa o grafike, tak len dodam, ze kazda kocka ma stran 6...

[Hladis]

Tak L2 to je hodne prasacky naprogramovana hra a iluze si o sikmookych po programove strance nedelam. Tak nestabilni ,swapujici a pomalou hru aby clovek pohledal ,ale bohuzel s tim se hold musime poprat u vetsiny her ,ze programatori se zrovna nepretrhnou. U L2 dost platilo ,ze zalezi i na rychlosti celeho systemu vcetne disku. Kazdopadne to byla asi nejnarocnejsi hra te doby Ono ale ikdyz se podivame na ostatni MMO ,ktere maji engine vlastni a ne prejaty ,tak ono to zadne terno tez neni. Priklad WoW nebo Rift. Tyto hry maji vlastni engine a i tak to poterebuje hodne silna CPU. U MMO na licencovanem engine je to asi jeste horsi ,ale tam uz vetsinou uraduji asiati a ty povazuju po programove strance za prasata. Ve vysledku da se rici neznam jedinou MMORPG ,ktera by nebyla CPU limited.

[DOC_ZENITH]

Trovaricon - Ano já nejsem programátor. Ale v naprosto všech CPU limitovanejch hrách ( s vyjímkou těch kde je limitem AI jak jsem již psal v tom megapostu) je to o počtu polygonů na scéně. Čím více trjúhelníků na scéně, tím méně FPS. A čím má ten CPU silnější FPU, tím lépe se mu tam daří. A to napříč celým CPU spektrem. Jo ehm, a ještě krátkou pipeline. Může za tím bejt strašná věda v pozadí, ale platí tenhle fakt. Pokud jsem na CPU limitu s počtem polygonů na scéně, tak mi neřikej "geometrie se nedělá na straně CPU" protože evidentně CPU je to co mi to geometricky limituje.
Edit: Ano můžeme se jim vysmát jak prasácky je ta či ta hra dělaná, ale to nezmění fakt, že lidi si jí doma neopravěj. A budou brát produkt kterej jim v tomhle prasácky SW napídne lepší výkon. Ala jak jsem již napsal v tom megapostu.

[webwalker]

DOC_ZENITH: Myslím, že nevýhoda dlouhé pipeline ve hrách nebyla prokázána. Jinak souhlas.
Nejsem sice odborník na hry a grafiku, ale co takhle DX11, je tam toho více co ulevuje CPU.
Teselace, DC, ale také multithreaded rendering!
Pokud vím, tak nVidia ovladače již multithreaded rendering podporují, nebo se pletu (Civ V)?

[DOC_ZENITH]

Ano, ale DX11 se nepoužívá.

[yuri.cs]

Delka pipeline: Nehalem - 16, Core 2 - 14. Takze je C2 lepsi?

[Hladis]

Edit: Ano můžeme se jim vysmát jak prasácky je ta či ta hra dělaná, ale to nezmění fakt, že lidi si jí doma neopravěj. A budou brát produkt kterej jim v tomhle prasácky SW napídne lepší výkon. Ala jak jsem již napsal v tom megapostu.

No tak to kazdopadne. Muzeme si poplakat vsichni spolecne nad neoptimalizaci softu a posilat programatory do pekel ,ale pak si pujdem koupit to kde ten soft pojede nejrychleji

[DOC_ZENITH]

Delka pipeline: Nehalem - 16, Core 2 - 14. Takze je C2 lepsi?

To by platilo pokud by Nehalem neměp 5 IPC oproti 4 (Core2) + 2x tak rychlou FPU + mnohem lepším přístupem do paměti + L3 je pro všechny jádra, ne 2x2L2 jako u slepence C2Q, atd. V ALU operacích a dobovym softu pro Core2 je C2Q většinou srovnatelné s Nehalemem, někdy i vyhrálo, koukni na dobové recenze. Postupem času se ale to co Nehalem umí začalo více používat, tak Core2 propadla.

[yuri.cs]

Jak muze mit Nehalem IPC rovno 5, kdyz je 4-issue?

[mouldy]

Jak je na tom FPU, IPC, pipeline v Thubanu?

[yuri.cs]

delka pipeline je stejna jako u K8; FPU je stejna jako u 'K10'; IPC jsou 3;