PCTuning fórum

mega52 píše:Preto nemozeme u Tahiti znizit bandwidth o 30% z 288GB na 221GB, lebo to ovplyvni vysledok. Toto nie je porovnanie efektivity CU.
Rovnako R9 290 ma 320GB/s a Raja Koduri tiez urcite nepodtaktoval pamate u R9 290 ked uvadzal +15%.
A dalsia chyba merania je i to ze RX470 mohol pomoct i discard accelerator.

a proč myslíš že delta color compression či discard accelerator by se neměl započítávat do vylepšení a výsledný efektivity? Ale budiž, Tahiti ti vadí tak se podívej sem http://www.hardware.fr/articles/949-30/ ... laris.html tady máš Tongu nijak nepodtaktovanou a delta color compression má taky

na slajdu k Polaris je "up to 15%", proč myslíš že když tohle podle cb.de i podle hw.fr splňuje Polaris GCN4 už proti GCN3 to nesplňuje proti GCN2?

Docent: Je to obdobný případ jako byl refresh Fermi GF104, tam v SM bylo celkem 48 CC, ale schopnost počítat FP64 mělo jen 16 z nich.

Možná se s Vegou pleteme a Vega 10 není vůbec o výpočtech, ale jen tak vypadá. Také ECC pokud vím chybí.

ArgCZ píše:a proč myslíš že delta color compression či discard accelerator by se neměl započítávat do vylepšení a výsledný efektivity? Ale budiž, Tahiti ti vadí tak se podívej sem http://www.hardware.fr/articles/949-30/ ... laris.html tady máš Tongu nijak nepodtaktovanou a delta color compression má taky

na slajdu k Polaris je "up to 15%", proč myslíš že když tohle podle cb.de i podle hw.fr splňuje Polaris GCN4 už proti GCN3 to nesplňuje proti GCN2?

zase těch 15% to má jen v jedné jediné hře , průměr je 8,2% oproti GCN3, ale v porovnání proti GCN2 (Hawaii) to těch 15% určitě je a AMD to přímo v tom slajdu uvádí ( nárust oproti R9 290 )

@webwalker: je docela možné, že je to tak jak říkáš a je to z důvodů úspory energie. Těch plně konfigurivatelných CU u Fiji/Tonga/Polaris je jen určitá část, zbytek je prostě natvrdo "zadrátovaný" a proto ty čipy uvádějí jen 1/64FP. Pravděpodobně se tím ušetří i nějaké trazistory a tím pádem i místo na die. Zrovna Fiji je obrovský čip na 28nm proces.

U Vega 20 ale zřejmě všechny CU zůstanou s volitelným FP64, takže ten čip pak zvládne počítat s 1/2 DP rate.

@Docent: je pravda že GP102 podporuje 4x INT8, což by teoreticky mohlo znamenat že umí i 2x16FP, ale také to může být tak (vzhledem k tomu že je to zcela jiný a nově navržený čip oproti GP100 nikoliv jeho menší klon) že prostě ta podpora FP16 je tam stejná jako u GP104, tedy 1/64 a že čip žádné jiné FP16 jednotky neobsahuje a Nvidia má prostě tímto rozsegmentované portfolio produktů podle požadavků trhu....

Když už se zde řeší fyzická velikost čipu Vegy, tak mě napadla ještě jedna teorie. Předpokládejme, že se čipy budou vyrábět u GF na jejich 14 um procesu. Na příkladu jader Polaris víme, že se zrovna nejedná o proces, u kterého se snadno dosahují vyšší frekvence. Co když v návrhu Vegy byly vlastnosti výrobního procesu lépe zohledněny a některé rozhodující části čipu využívají nově menší hustotu trazistorů. Tím by se daly omezit proudové úniky a ve výsledku by to mohlo znamenat zvýšení efektivity a frekvence čipu na úkor jeho plochy.

Dost tranzistorů taky sežere Infinity Fabric, který propojuje IP bloky.

navic je tam nejaka logika predvidajici dalsi instrukce coz urcite taky nebude mala zalezitost

všechny nové feature v tom čipu žerou nějaké tranzistory (některé víc, některé míň) Třeba NV-Link u GP100 stojí také poměrně hodně tranzistorů...

slajdy k Infiniti fabric: (zdá se že Hypertransport ještě neřekl poslední slovo)

https://www.forum-3dcenter.org/vbulleti ... st11260758

Zabudas na to, ze ma prijst 485 seria polaris na vyssich taktoch. Vobec to nemusi byt iba skladbou a rozlozenim jadra ale daleko lepsie vyladenym procesom vyroby. Uz dnes vidis ako sa kusy polaris lisia na rovnakych taktoch brutalne spotrebou aj oc.

Mr_Trollfan píše:Zabudas na to, ze ma prijst 485 seria polaris na vyssich taktoch. Vobec to nemusi byt iba skladbou a rozlozenim jadra ale daleko lepsie vyladenym procesom vyroby. Uz dnes vidis ako sa kusy polaris lisia na rovnakych taktoch brutalne spotrebou aj oc.

O RX485 teda fakt nic nevím ani o velkých rozdílech OC a spotřebě u aktuální sérii, to sis zase něco vycucal z prstu?

No, v MAC driverech se objevily Polaris 12 a Polaris 10 XT2. Právě Polaris 10 XT2 by měla být nová revize čipu. AMD si připravilo značení právě i pro refresh - aka Revision.

No my Macuseri se uz celkem tesime pac R9 395M ma vytop jak Temelin, v klidu ma 65-70st v Imacu 5k.
To zase Apple u AMD ziskal nejaky brutal slevy, jinak to neni mozny. Predchozi Kepler (780M) mel polovicni vytop. End OT...

Apple dlouhodobě spolupracuje s AMD R9 395m v macu asi na hry až tak člověk nevyužije, spíše výpočty? No, pokud se do fullu udrží okolo 90st, tak je to cajk.

godlike píše:No my Macuseri se uz celkem tesime pac R9 395M ma vytop jak Temelin, v klidu ma 65-70st v Imacu 5k.
To zase Apple u AMD ziskal nejaky brutal slevy, jinak to neni mozny. Predchozi Kepler (780M) mel polovicni vytop. End OT...

Taky bych asi raděj viděl v Applím HW nVidii ale třeba to Vega změní .

Možná až nV přestane "sabotovat" OpenCL na kterém Apple staví.

Ale zpět k tématu. Řešili se tu nárůsty efektivity Tonga vs. Polaris, tady je jeden z testů clock to clock od Damiena (Hardware.fr)



Těch 15% co AMD uvádělo není nereálný údaj.

Podle mě je největší úspěchem Vega architektury to, že AMD bude schopno poměrně velké die provozovat na docela vysokých taktech (cca 500mm2 na 1,5GHz) To by mimo jiné znamenalo, že další a o dost menší čipy této arch. by teoreticky mohly běžet na vyšší frekvenci (?) a AMD by v tomto ohledu konečně frekvenčně dohnala Pascala... Časem by se mohla totiž objevit třeba Vega 12 ( stejně jako se nečekaně objevil Polaris 12 ) a zcela nahradit původní Polaris 10...

Krteq: Nj, v jednej hre zo 17...potom je tam ale napr. aj Hitman, čo je naviac hra ktorá má AMD rada a tam je to + 0%. Vo väčšine prípadov je to pod 10% a keď pozriem na ten rozptyl, tak my to neprijde moc ako HW vylepšenie, ale skôr že novšia generácia dostáva viac starostlivosti pri optimalizácií...

Krteq píše:To vyjádření Dana Bakera bylo dřív než se přišlo na ty machinace se zdrojákem.
A mimochodem, driver 368.25 to nefixnul, proto se to pitvalo dál a přišlo se na to
Ale to ve vlákně o Vega uarch nemá co dělat, dost OT.

Zadny machinace se zdrojakem v tomhle pripade nebyly, protože se zadny ani nepotvrdily.
Chybu mel jen jeden ze tri preview driveru, kde doslo k chybe obrazu, na coz AMD upozornilo, Oxide se k tomu pak vyjádřilo, vcetne následného vysledku ze za to mohl jeden preview driver. Vadny byl pouze a jen 368.19, testovalo se v magazínech na 368.13 a ještě existoval 368.16. Oficialni driver 368.25 tuto chybu taktéž nemel a obraz hry je identicky bez chyb. Jednalo se pouze a jen o chybu v jednom z preview driveru a potvrdili to i samotni Oxide.
Ano, nemá to tu moc co delat, takze priste si odpust tyhle poznamky a nevydavej svoje domenky za fakta a pak se nediv, ze ti je někdo narovna. Mas smulu ze si to pamatuju a bylo to tu na foru reseny.

michal3d píše:Vo väčšine prípadov je to pod 10% a keď pozriem na ten rozptyl, tak my to neprijde moc ako HW vylepšenie, ale skôr že novšia generácia dostáva viac starostlivosti pri optimalizácií...

Může být, možná má konečně AMD opravdu výbornej driver team...

michal3d píše:Krteq: novšia generácia dostáva viac starostlivosti pri optimalizácií...

Z casti suhlasim, nieje to potrebne prehanat ale hw/zdroje na Async compute do GPU pretlacit len do miery v akej su aktualne hry a hry v priebehu cca 3 rokov dopredu schopne dany prislusny HW/QUE vyuzit, nie to zbytocne tlacit nasilu do vypoctoveho vykonu, ktory 95% trhu nevyuzije. Ovsem co bude v buducnosti, do akej miery sa to bude vyuzivat povedat nevieme... To je ale dlha doba. Tam karty nebudu stacit vykonovo, takze zatial je to iba pritaz(v dx11) tak isto to bolo pre herny trh na pritaz pre Tahiti. Zbytocnost tolko DP vykonu na ukor spotreby. Kazdopadne Async compute je potrebny, nie fast/context switch.

Neni potřebný ani jedno. Fast context switching je reakce na async a jak async provést na GPU co jej neumí s menší ztrátou výkonu. Samotnej async je pak o tom jak využít GPU pipeline aby nebyla částečně idle a je to důsledkem toho že ona pipeline nedovede běžet na plno se stávajícim kódem. Mnohokrát se tu debatovalo o tom jestli by nebylo lepší mít jedonušší a efektivnější pipeline a investovat tranzistory do jejího hrubého výkonu než mít složitou pipeline co běžné hry nedovedou zasaturovat a vymejšlet pak vehementy jak jí pomoci (ala AS). AMD o tomto problému vědělo co dokončili GCN (Q4 2011) a až o monoho let později v době nástupu DX12 se najednou vynořlo AS co těmto GPU zázračně zvedá výkon... resp jej dostává tam kde dle specs a velikosti měl bejt už od začátku. Pokud by AMD bylo schopné ze svejch GPU dostat výkon co měly mít nikdy by se nestalo aby NV prodávala mainstream jako high-end, od Kepleru dále.

Del - FP16 nikdy nemůže bejt slower jak FP32 už z principu. Některá nová GPU dovedou dát dvě FP16 instukce místo jedné FP32 ala až 2x takovej výkon v FP16 (a stejnym principem pak až 4x v INT8). Pokud dojde k situaci že FP32 běží 1/1 a FP16 jako 1/64 tak je to jasné SW omezení, protože i kdyby GPU FP16 vůbec nativně neumělo, tak by se provedla přes FP32 tzn speed 1/1.