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

[yuri.cs]

http://www.xbitlabs.com/images/video/ra ... heme-1.gif
http://common.ziffdavisinternet.com/enc ... AFPIPE.GIF

Z tehle hilevel gfavu vyplyva, ze uzkym hrdlem rasterizace (jen rastrizace!) v pripade narustani slozitosti sceny - polygonu - budou dve veci. Zaprve spojeni mezi CPU a GPU, pres ktere musi proudit informace o vertexech. Pak taky cely pametovy subsystem CPU, ktery musi tahat data z hlavni pameti.

Je to tak?

[dexterav]

lenže minimálne ak by to brzdila ram museli by sa niekde prejaviť rýchlejšie ramky a to sa nedeje, takisto prepojenie CPU GPU by sa muselo prejaviť pri prechode PCIe1.x na PCIE2.x ale nič také sa nedeje
nejaké nárasty 1% sú na smiech kedže sa bavýme pri spomenutých veciach často o 2x náraste rýchlostí

[nou]

DOC ma pravdu v tom ze drviva vecsina dat ide iba smerok do GPU. ale ona geometria/textury sa tam nahra iba raz a uz sa len posielaju potom pozicie kde sa ma dany model vykreslit.

ono napr taky Red Alert 3 tak logika hry bezi na 30FPS. tato logika zabezpecuje ze sa jednotky hybu rata poskodenie, cesty kade ma jednotka ist a podobne. no a potom je tu renderovacie vlakno ktore si zoberie posledne dva stavy hry a medzi nimi interpoluje. takze mozete mat aj 150FPS kedy uvidite ako sa panacik presuva z predposlednej do posledne vypocitanej polohy.

taktiez sa my uz v par hrach stalo ze sa proste spomalila. bola to strielacka kedy som sa mohol normalne obzerat aj vsetko sa pohybovalo plynulo. len pomaly. proste vlakono co ratalo logiku nestihalo aj ked sa renderovalo na 50 snimkov.

ono dost fyzikalnych enginov je navrhnutych na pouzitie s konstatnym casovym krokom. mozete si zvolit samozrejme prakticky lubovolny casovy krok ale ten by ste maly pouzivat stale, inak sa mozu objavovat nestabylity v simulacii.

[yuri.cs]

Interpolace mezi tikama/updatama/save je normalni a nutna, protoze digitalni technologie jaksi z podstaty vylucuje spojitost.

[DOC_ZENITH]

http://www.xbitlabs.com/images/video/ra ... heme-1.gif
http://common.ziffdavisinternet.com/enc ... AFPIPE.GIF

Z tehle hilevel gfavu vyplyva, ze uzkym hrdlem rasterizace (jen rastrizace!) v pripade narustani slozitosti sceny - polygonu - budou dve veci. Zaprve spojeni mezi CPU a GPU, pres ktere musi proudit informace o vertexech. Pak taky cely pametovy subsystem CPU, ktery musi tahat data z hlavni pameti.

Je to tak?

EE. To z toho může vyplývat, ale PCI-E pro grafiky vesměs téměř idluje (mizivé rozdíly mezi PEG 8x vs 16x, či 1.1 vs 2.0) a prostupnost pamětí ovlivňuje dnes herní výkon CPU jen mizivě (pár %) Tohle platilo v dobách Pentia MMX a PCI grafik, že přínos rychlejší sběrnice byl a rychlejší prostupnost pamětí znamenala citelné nárůsty, ale dnes se ten bottleneck přesunul někam jinam, a přes všechnu tu huge teorii prostě platí to že ten kdo má silnější FPU výkon na 1 vláknu vyhrává, takže dokud mi někdo neobjasní proč to tak je, tak si budu stát za svym. Já nejsem v tomhle expert ani vzdáleně ale mám to vše změřené a obenchmarkované. Tak to prostě ihmo je. V praxi to takhle je, jestli teorie říkaj to a to je krása, ale prostě čím více polygonů na scéně, tim více se CPU stává limitem (ne GPU či sběrnice, ty maj furt rezervu dost velkou), a u toho CPU se stává limitem jeho FPU výkon. Tak to je, to se v praxi děje. A správná bude ta teorie které dojde k tomuhle závěru (asi).

Je sice hezký že mi tu někdo rozebere něco jako ne "geometrie se nepočítá přes CPU to je vše v GPU" nuo ok tak mi vysvětelte proč s tou rostoucí geometrií rostou nároky primárně na CPU, gpu to sežere téměř bez jakéhokoliv performance hitu, tomu rostou nároky jen díky vzrůstajícím nárokům na fillrate s počtem objektů, atd, ale ty rostou mnohem pomaleji než ten CPU bottleneck, takže jsou nepodstatné.

[webwalker]

Sic nejsem grafik, ale já se v tomto přikláním k DOC_ZENITH. CPU přeci musí natáhnout a vytvořit nějaké objekty pro D3D pipeline, které jsou následovně přes driver zaslány na GPU pro jejich vykreslení. No a příliš velký počet těchto objektů by mohl "zakroutit krkem" cpu, zvláště pokud se renderingem zabývá pouze jeden thread. Jak jinak by to mohlo fungovat? A proč by MS v DX11 vytvářel multithreaded rendering?

[Hladis]

Kdyz vezmu L2 tak tam zalezelo i na rychlostech komunikace celeho systemu od HDD (ktery byl velky bottleneck) po FSB a CPU kde kazdy narust byl hned znat a to ze hodne. V dnesnich PC pokud tam nasadim SSD abych odboural vliv HDD ,tak v celem systemu neni nikde uzke hrdlo a vse konci u CPU. Pokud CPU posle jen za cas geometrii/textury (jine jadro fyziku atd...) a posilaji se jen pozice ,tak by musely byt pozice objektu hlavni problem kde se to zpomaluje ,ale to mi moc nesedi. To je nejak malo na to aby se to cely zaseklo ,ale treba to tak je. Kazdopadne to ma na starosti prave FPU pokud se nemylim. I tak proste musi platit ze GPU ceka na CPU jinak by musela jet nepretrzite na 100%. Osobne mam natestovano take dost a vysledky se shoduji s tim co rika DOC. V pripada C2 vs. Nehalem to bylo hodne markantni. Normalne Nehalem nijak nezaril a v benchmarcich to oproti C2 bylo nic moc. Hry to same dokud ale nedoslo na CPU limited hry. Tam byl vykon prekvapive az dvojnasobny. Prikladem je Aion kde to byl doslova brutalni rozdil.

[webwalker]

Jen tak pro zajímavost, jak obrovský vliv má multhreaded rendering v DX11. Nvidia v ovladačích podporu má ale AMD ne
http://www.anandtech.com/show/4135/nvid ... 0-market/9

[yuri.cs]

No, ono to neni jenom o ciste propustnosti RAM. Co takhle rychlejsi a vetsi cache, vsechny mozny prefetche, atd.

V dusledku i GFX driver musi tez mit svou nezanedbatelnou rezii, ktera taky musi lezet na CPU.

[nou]

lidicky stiahnite si tento program. tento prakticky dokaze vytazit kartu prakticky na maximum teoretickeho maxima. http://www.geeks3d.com/20100629/test-op ... hd-5870/2/

webwalker: ten test na anadatech poznam. ale to myslim malo vplyv nieco uplne ine kedze napr v LuxMarku tam nvidii zaznamenaly skok takmer na dvojnasobok.

[Hladis]

No a predstavme si to demo tak ze ty jednoduche asteroidy by byli slozitejsi panacci a ti by pohybovali udama a behali by nezavisle na sobe nedej boze by vykonavali nejakou cinnost jako vrazdeni mezi sebou. A mame CPU killera.

[flanker]

Recently a server maker accidentally disclosed specifications of next-generation Opteron models that AMD seems to plan to release initially which sported pretty low clock-speeds:

* Opteron 6220: 8-core, 3.0GHz, 3.5GHz Turbo, 8MB L2, 8MB L3 cache
* Opteron 6234: 12-core, 2.4GHz, 2.9GHz Turbo, 12MB L2, 12MB L3 cache
* Opteron 6272: 16-core, 2.1GHz, 2.6GHz Turbo, 16MB L2, 16MB L3 cache
* Opteron 6276: 16-core, 2.3GHz, 2.8GHz Turbo, 16MB L2, 16MB L3 cache

http://www.xbitlabs.com/news/cpu/displa ... eport.html

[yuri.cs]

Xbit newsky jsou cim dal tim horsi. Kde je zdroj zpravy? Turbo se nenaleza v originalu a je tudis vymyslene. 50% vs 35% atd.

Jiz probirana originalni zprava je tady: http://www.cpu-world.com/news_2011/2011 ... ghted.html

[webwalker]

webwalker: ten test na anadatech poznam. ale to myslim malo vplyv nieco uplne ine kedze napr v LuxMarku tam nvidii zaznamenaly skok takmer na dvojnasobok.

Kdepak, vysvětlení je zde:
http://forums.anandtech.com/showpost.ph ... stcount=28

[del42sa]

zajímavé

PS: nečteš si SZ.

[webwalker]

del42sa: Sorry, napraveno

[nou]

no tam to mate napisane. problemom nie je objem geometrie ale pocet objektov ktore sa musia vykreslit.

[ttxman]

Trovaricon: ad chory napad s fyzikou v renderingu: K tomu se da rict jenom Tony Hawk pro skater .. tusim 2. Kdyz si totalne zasekal pocitac tak ti to pocitalo dylku skoku (skore) na zaklade doby ve vzduchu takze cim vic to sekalo tim lepsi byly skore

Ad geometrie: Ted se ve hrach animuje snad i trava. Animace = prepocitavani modelu v case a to dela prevazne CPU a diky maticovejm vypoctum to zatezuje FPU. A to i relativne pomale vypocty goniometrickych funkci.

Ad rendering ve vice vlaknech: Viz animace ... kdyz muzu rozdelit generovani modelu do vice vlaken a pak to vsechno najednou poslat. (V openGL nebo DX11 to z tech vlaken muzu i zvlast posilat) Tak se da dost casu usetrit v pripade, ze to nestaci spocitat 1 vlakno, pokud by stacilo tak to vicevlaknovym renderingem muzu i castecne zpomalit.

[webwalker]

ttxman: Nejsou animace typu tráva apod. transformace řešeny Vertex shadery?

[maltra]

Správa z bulváru:

"Po pár dňoch na mori ... Bulldy výsledky budú pokračujú dnes ...
Ostante Naladení ... Bulldy sračkové výsledky sú na ceste. Začať plakať AMD imbecilní fanúšikovia Všetko bude známe za pár týždňov a uvidíte, kto má právo (já samozrejme) ... hehehehehe! (škodoradostný smiech mentálne zaostalého dospelého človeka)".