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

[mouldy]

Vykonove je na tom FPU K10,5 jak? V porovnani se Sandy... ?

delka pipeline je stejna jako u K8

a to je kolik?:D...cim kratsi, tim lepsi?
U IPC je to cim vic, tim lip? K cemu je vubec IPC?

[yuri.cs]

heh
wikipedia.org

[mouldy]

Vykonove je na tom FPU K10,5 jak? V porovnani se Sandy... ?
Citace:
delka pipeline je stejna jako u K8
a to je kolik?
IPC uz vim...

[DOC_ZENITH]

Vykonove je na tom FPU K10,5 jak? V porovnani se Sandy... ?
Citace:
delka pipeline je stejna jako u K8
a to je kolik?
IPC uz vim...

Se sandy citelně hůře, ale je o něco jelpší jak ta co má Core2. Ne o hodně, ale je.

[yuri.cs]

delka pipeline je stejna jako u K8

Hammer/Opteron/K8 - 12; K7/Athlon - 10

[mouldy]

Takze ma lepsi pipeline nez Nehalem?

[webwalker]

DOC_ZENITH: U délky pipeline neplatí, že je horší nebo lepší

[del42sa]

efektivita procesoru se nedá posuzovat jen podle jeho jedné části...

[yuri.cs]

Presne tak, nejde na to koukat bez nadhledu. To pak muzeme rict, ze zasobnikove CPU, ktere maji myslim jenom Fetch a Exec (2 stages), jsou preci nejlepsi...

Jenom pro zajimavost graf od Intelu se vztahem IPC vs delka pipeline vs 'vykon' u NetBurstu. http://www.behardware.com/medias/photos ... 017464.gif

[DOC_ZENITH]

Ale to jsem přeci nikdy neřekl, nesmíte brát vše doslovně. Řekl jsem že hry preferují kratší pipeline a o pár stránek dopředu jsem ale řekl, že prodloužení pipeline je akceptovatelné jen pokud přinese zlepšení jinde, více IPC, atd. A pak jsem se tu dlozho bavili o netburstecha rozdílech mezi nimi a jakej negativní vliv tam dlouhá pipeline měla.

Já netvrdim že čím kratší pipeline tím lépe, to bych tvrdil že 486>all, ale tvrdim že moc dlouhá je hodně na škodu. A BD má podle spekulací mít nad 20. To je prostě hodně. Podle mě je to hodně.

[del42sa]

http://en.wikipedia.org/wiki/Instruction_pipeline

Kód: Vybrat vše

With branch predictor the cycle time of the processor is reduced, thus increasing instruction issue-rate in most cases.

http://en.wikipedia.org/wiki/Branch_prediction

\\webwalker: ještě ne, možná totiž po vydání BD trochu zlevní

[webwalker]

del42sa: OT - už jsis pořídil SB?

[nou]

k tomu vykreslovaniu cez DirectX odporucam precitat tento odstavec http://en.wikipedia.org/wiki/Comparison ... Windows.29

proste pri DX sa musi prakticky kazdom volani DX funkcie prepinat CPU do kernel modu. a to trva neskutocne dlho. (az zopar miktosekund) toto moze mat Intel efektivnejsie ako AMD a teda nestraca tak na vykone.

a su dva dovody preco sa zaviedla tesselacia.
1. setrenie prenosu dat z pamete karty do GPU.
2. moznost urobit jemnejsie prechody medzy jednotlivymy urovnamy detailnosti modelu.

[DOC_ZENITH]

No pokud to mělo cokoliv urychlit dost se nepovedlo, protože co jsem kde viděl teselaci tak to vžd byl solidní performance hit. Dle mého názoru je to nejdůležitější proto, že to přináší více polygonů na modely, a polygony tvořené čistěv GPU, tudiž se tím nemusí zatěžovat CPU. Tak i byla prezentována a marketingově tlačena, že prostě zvedne počet polygonů.

[nou]

tak este raz CPU nepocita geometriu uz od dob DirectX7 kedy prislo TnL. jedine co rata su pozicie objektov co su len x,y,z suradnice.

a je jasen ze tesselacia ma dopad na vykon kedze kazda apliakcia co som videl PRIDAVALA polygony. keby si renderoval s 10 milionov klasickych trojuholnikov a potom s 1 milionov klasickych pricom by sa teselovaly na 10 milionov tak by si vydel vykonovy narast. teda s tesselaciou dosiahnes urcitu kvalitu s vecsim vykonom.

[DOC_ZENITH]

A na to jsi přišel jak? Z propagandy nvidie z dob GF256 a GF2? Testy ve své době ukázaly že tyhle karty začali mýt přínost pro systém až když byl CPU slabší jak zhruba K7 1Ghz. A umožňuou v GPU sázet nasvětlení, ne tvořit samotnou geometrii. Já si to ani nedovedu představit jak by taková věc mohla bejt jen v GPU když na ní stejně musíš počítat kolizní model, animce, atd. Ano animace a pohyby tam teoreticky můžeš přikázat přes vertex shader, ale kolizní model, fyzikální výpočty, a další věci kterejch je v těch hrách plno prostě ne.... A další věci které se na ní vážou. Co jde do GPU už nikdy nejde zpátky, tam data tečou vesměs jdnim směrem. Do GPU pošleš už hotovou kostru toho oběktu a textury/shadery co se na něj mal aplikovat a GPU to provede, společně s dalšíma věcma jako texture filtering, a různé formy post processingu protože je v tomhle 100x rychlejší jak CPU. Ale GPU samo nedovede geometrickej model postavit, ten dovede měnit až příchodem teselace. Alespoň tak mi teda připadá že to je, a tak ňák se to projevuje na výkonu pokud jde o CPU limitaci.

[Trovaricon]

Dozviem sa uz konecne co si predstavujes pod pojmom "pocitanie geometrie" ? Kazdy model je definovany v lokalnom suradnicovom systeme, ktory je pomocou transformacii (pocitania geometrie) umiestneny do suradnicoveho systemu sceny. Transfomacie su 3: world (lokal system > global), view (pohlad kamery), projection (vlastnosti kamery - sosovka).

Aplikaciu tychto matic na model ma na starosti T&L alebo Vertex shader.

Kolizny model a fyzikalny model nema s tym geometrickym vacsinou nic spolocne (haha, to by som chcel vidiet tu architekturu, kde by toto bolo mozne). Ako kolizny model sa pouziva najma kvader, orientovany kvader, gula, konvexna obalka - najma ich kombinacie (napr. na vybratie "koliznych kandidatov" sa pouzije najjednoduchsi model - gula, nasledne sa vysetruje na detailnejsom modeli kolizia tych, ktore su v prvom kroku vyhodnotene na koliziu).
Zaroven, co to je za napad ratat kolizie (prip fyziku) vo vlakne s renderingom ? Ved to je totalne chory napad... To akoze ak mi pojde hra 2 fps, tak sa rychle nelinearne pohybujuce objekty nezrazia ?

Geometricky model je zoznam vrcholov primitiv, ktore tvoria objekt - co tam chces na CPU pozitat okrem transformacnych matic ? Nazorna ukazka:



prislusna transformacia (pozrite si tie 3 obrazky):


Ja sa v ziadnom pripade nechcem hadat o tom, ktora architektura CPU je vykonnejsia / "lepsia". Snazil som sa len vyjadrit nazor, ze dovod, preco system A je rychlejsi ako system B nie je vacsinou trivialna vec - vsade sa to extremne generalizuje (za pojmy ako "CPU nestiha krmit grafiku" by som na odbornych weboch stinal hlavy) a co viac, casto sa striela zlym smerom.

Ked som bol maly chlapec, tak som chodil po parkoviskach a pozeral cez sklo na ta rychlomery aut, ktore vyzerali byt drahe. Asi viete na zaklade coho som auto vyhodnotil ako "faro"

EDIT:
Bolo by asi vhodne ak by sa ostalo len pri system A je v hre X rychlejsi ako system B - to je fakt zisteny meranim. Dovod, preco je rychlejsi si vyzaduje uplne iny set vedomosti. Teda strelit od brucha ze je to koli FPU (maly detail: SSE alebo x87 ? Zrejme nebudem inicializovat SSE ak nemam batch na pocitanie) alebo uchylny conditional jump spam (MMO server) ? V jednej diskusii som narazil na nazor: vykon CPU pre L2j (java emulator na Lineage 2) sa pocita na pocet jadier (threadov) - smiesne ? Myslim, ze bol pravde podstatne blizsie ako ludia, ktori na utvrdenie svojho odporucania na vyber CPU (pre l2j server) zacnu vkladat linky na SPEC, ine syntetiky alebo rendering testy.

[yuri.cs]

S kolizema a potazmo fyzikou mas samozrejme 100% pravdu. Je to vzdy samostatny thread. A co se collision shape tyce, tak se skutecne postupuje pyramidove k vrcholu - relativne nejpresnejsimu shape.

FPU se ve hrach samozrejme pouziva. V libovolnem profileru bude videt, jaky mix instrukci tam skutecne je. Kdo se vyznate v Intelskem nebo AMD profileru, tak to mate za minutu.

Nahodou je na B3D je chlapik, ktery vytvari tuhle hru: Trials HD. Pridam jeho vyrok:

According to some of our profiler captures, the thread that executes most FPU/SIMD in our game is the visibility culler thread. It has around 15% FPU instructions and around 20% SIMD instructions. So 35% of the instructions go to the FPU/SIMD pipeline.

SIMD vs x87 je zajimava vec. Notoricky znamy bude treba vypocet Eukl. normy (delky) vektoru v klasikem pouzivanem prostoru - sqrt( x*x + y*y + z*z ). Tady je srovnani skalarni SSE vs x87: http://assemblyrequired.crashworks.org/ ... uare-root/

[Trovaricon]

Moment, ja netvrdim, ze sa FPU nepouziva v hrach. Ja som pisal, ze konkretne vlakno, ktore obsahuje volania OGL/D3D (renderovacie vlakno) tych vypoctov vela nenarobi ak sa tam niekto nesnazi umyselne natlacit nieco, co tam byt nemusi (napr. vypocet hodnot transformacnych matic tam samozrejme je).

Kolko vypoctov s realnymi cislami sa da v hre mat mi je znama vec - implementovat server-side koliziu projektilov (sipy, kuzla) s hracmi v open space MMO vytvori isty nadhlad.

[Hladis]

Tak ted se mi rozpadla babovicka. Muzemi tedy nekdo vysvetlit kde je to uzke hrdlo u CPU ? Ja mel uz leta letouci stejny pohled jako DOC ,ze predevsim (ne pouze) zalezi na FPU a s jeji silou rostl i herni vykon coz je otestovane. Prinos T/L sice nejaky byl ,ale ty grafarny i s nim potrebovali silny CPU jinak podavali mizerny vykony. GF2/3/4 potrebovali silna CPU coz bylo vseobecne znamo (z te doby je i L2). Pokud je CPU slaby tak GK proste idluje a nepracuje na 100% a fps jdou dolu. Pokud to teda neni tim ,ze nestaci dodavat GK data ,tak proc tedy GK jede na pul plynu ? Pokud tedy CPU nepocita polygony atd.. proc s rostoucim poctem je vetsi narok na CPU ? Zkuste to laicky vysvetlit bez nejakych slovnich spojenich jen pro zasvecene.