PCTuning fórum

DOC_ZENITH píše: 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).

J to je diskutabilne.

DOC_ZENITH píše: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.

S tím FP16 máš recht, čistě úmělé omezení.

DOC_ZENITH píše: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.

tohle jsme tu ale už jednou probírali, a takhle jak to píšeš to prostě nefunguje. Všechna GPU až do Tonga FP16 vůbec nepodporovala. Až Tonga přinesla nativní FP16 support, ale při stejném výkonu jako FP32. Pascal GP104 od Nvidie je stejný případ. Její FP32 jednotky neumí to stejné co umí FP32 jednotky velkého Pascala GP100. Nakonec o dvě stránky zpět jsem ti to linkoval, kde to máš přímo od Ananda pěkně rozebráno....

As it turns out, when it comes to FP16 NVIDIA has made another significant divergence between the HPC-focused GP100, and the consumer-focused GP104. On GP100, these FP16x2 cores are used throughout the GPU as both the GPU’s primarily FP32 core and primary FP16 core. However on GP104, NVIDIA has retained the old FP32 cores. The FP32 core count as we know it is for these pure FP32 cores. What isn’t seen in NVIDIA’s published core counts is that the company has built in the FP16x2 cores separately.

To get right to the point then, each SM on GP104 only contains a single FP16x2 core. This core is in turn only used for executing native FP16 code (i.e. CUDA code). It’s not used for FP32, and it’s not used for FP16 on APIs that can’t access the FP16x2 cores (and as such promote FP16 ops to FP32). The lack of a significant number of FP16x2 cores is why GP104’s FP16 CUDA performance is so low as listed above. There is only 1 FP16x2 core for every 128 FP32 cores.

Samozřejmě máš pravdu v tom, že u poslední generace Pascal by teoreticky GP104 mohla FP16 instrukce provádět na FP32 jednotkách, ale při stejné rychlosti jako je FP32, tedy jde o stejné řešení jaké přineslo GPU Tonga.


U GP104 je skutečně omezení i softwarového rázu nicméně o to nejde. Tohle nás dovádí k původní debatě, že lze automaticky na FP32 jednotkách provádět FP16 instrukce což minimálně pro všechny pre Tonga čipy a Pascal čipy není pravda.

Starting with the Tegra X1 – and then carried forward for Pascal – NVIDIA added native FP16 compute support to their architectures.

http://www.anandtech.com/show/10325/the ... n-review/5

Proto nelze automaticky předpokládat, že každý SP nebo Cuda jednotka v nových GPU může provádět instrukce jako GP100/Vega, tj. FP32 = 2xFP16 = 4xINT8 jenom proto, že 32:2 je 16...

Chceš mi říci, že GP102 může prováděl 4x speed int8 ale FP16 dovede jen 1/64 a nedovede jej ani prohnat jako 1/1 přes FP32? Ihmo troufám si tvrdit že ne, tohle smrdí SW omezenim, jinak by to bylo FP32 only jak GP104/106 a pod.

ne chci tím říct jen to, že FP32 nautomaticky neznamená zároveň 2x FP16 nebo 4x INT8 a také, že to u všech čipů automaticky nemusí znamenat FP32 = stejná rychlost FP16.... Některé čipy FP16 nepodporují vůbec.

GP104 to tak rozhodně nemá, u GP102 to může být jinak, ale to budeme vedět jistě až se k tomu vyjádří někdo z Nvidie. Ani jeden z nás není inženýr a popravdě nevíme, jak to tam mají vevnitř zadrátováno. Navíc nejde jen o ty jednotky samotné, jde i o příslušné registry, atd.

podle me i fury x umi 1/2 DP ale je SW omezena a to z duvodu ze nebylo mozny na HBM1 nacpat vic jak 4GB pameti takze to AMD nikdy do profi sfery nevydalo

Tak v OpenCL sa s FP16 sa daju len ulozit do pamete. Musite pouzit specialnu funkciu vload_half() ktora nacita FP16 hodnotu z pamete a konvertuje ju do FP32. Tym mozete ziskat vykon naviac ak ste limitovany memory bandwith alebo sa neviete zmestit data do VRAM pricom staci aj FP16 presnost.

OpenGL ma podporu uz od roku 2002 vid GL_NV_half_float GL_ARG_half_float GL_ARB_half_float_vertex

Vo vsetkych pripadoch je to ale len moznost ulozit data v FP16. Vypocty aj GPU potom rata vo FP32 presnosti.

Já pořád nechápu jak můžete považovat podporu jiných instrukcí, DP s poloviční propustností v 32bit registrech a podobně považovat za jednoduché změny.
Hlavně pokud si uvědomíte, že řešení, které dneska AMD i NVIDIA používá, tedy místo změny ALU prostě do CU přihodí několik samostatných jednotek pro DP výpočty. Proč by neudělali to samé pro HP (FP16)?

DOC_ZENITH: Ilustrace toho jak počítat FP16 v FP32 jednotkách: (1:1 je utopie, 1:64 je určeno pro nápis na krabici)

Konverze menšího FP typu na vetší není zadarmo. A obráceně je to horší.
FP je v paměti vždycky uloženy jako 0.xxx * (2 ^ (e - Z))

U FP32 to bude v paměti: [znamenko(1bit),e(exponent 8bit),xxxx(mantisa 23bit)]
U FP16 to je [znaménko(1bit),e(exponent 5bit),xxxx(mantisa 10bit)]
Kde Z je polovina rozsahu. (první doplněk se tomu tuším říká). Z pro FP32 je 127, pro FP16 je 15.

Takže konverze z FP16 na FP32 bude vyžadovat, přeházení bitů na jiné pozice pro znaménko a mantisu. A pro exponent půjde o přičtení konstanty.
Obráceně je to podobný, jenom se řeší zaokrouhlování mantisy, přetečení exponentu, výsledkem čeho může bát nekonečno, což je specifická hodnota v celém registru.

Máme GPU, které FP32 operace dělá v jednom taktu. Chceme počítat FP16 pomocí FP32:
Pro FP16 podpora může být:
1) V mikrokódu, každá konverze může zabrat klidně desítky taktů navíc
2) HW konverzní instrukce za 1(+) takt navíc proti FP32
3) Nebo přímé načtení FP16 do FP32bit.

Pak následuje cena za IEEE754 a deterministické výsledky na různém HW.
Na CPU (x87) probíhaly FP výpočty v 80bit registru což po řadě výpočtů mohlo přinést různé výsledky oproti SSE. Sice přesnější, ale podle IEEE754 špatně. (třeba https://en.wikipedia.org/wiki/X87 třetí odstavec z description)
Pro dodržení standartu tedy po každé FP operaci musí následovat zaokrouhlení na FP16.

Takže když chcete: načíst -> operace -> uložit
budete pro FP16 muset: načíst -> konverze -> operace -> zaokrouhlit -> konverze -> uložit

Pokud to bude mikrokódem nebo jenom s minimální HW podporou, tak mi ani 32 taktů pro jednu FP16 instrukci nepřipadá moc.
Po nějakých změnách v HW ALU, přidání zaokrouhlovacích a konverzních instrukcích půjdou FP16 operace jenom 1/2 rychostí oproti FP32.
Pro výkon 1:1 budou nutné další změny.
A pro výkon 2:1 musíte celou ALU totálně překopat. (podobně jako rozdíl MMX vs SSE)

Konečné řešení: FPU se neupraví (moc práce, možná to bude v další generaci), ale přihodí se jednotka.. stejně jako u DP. Kvůli nápisu na krabici, papírový podpoře FP16,


Hladis//Promaz a chovejte se bez toho, ze to hrube uraží diskutery.

Celej ten arguemnt byl o tom, že Titan XP umí 4x speed INT8, a neni logické pokud umí INT8 4x rychleji jak FP32 tak aby FP16 počítal 64x pomaleji... smrdí to SW omezenim, nic víc.

a všimnul sis, že to jsou dvoje různé instrukce ? FP16 jsou floating point instrukce a INT8 jsou integer instrukce.

The Pascal GPU architecture implements general-purpose, IEEE 754 FP16 arithmetic. High performance FP16 is supported at full speed on Tesla P100 (GP100), and at lower throughput (similar to double precision) on other Pascal GPUs (GP102, GP104, and GP106), as the following table shows.

The 8-bit and 16-bit DP4A and DP2A dot product instructions are supported on GP102-GP106, but not on GP100. Table 1 shows the arithmetic throughput of the different numerical instructions on Pascal-based Tesla GPUs.

https://devblogs.nvidia.com/parallelfor ... ng-cuda-8/

Finally, AMD added 8-bit computing support but it is specific to deep learning, as does Nvidia on GP102 / 104/106/107. Unlike the FP16, it is therefore not a generalized support but one or a few specific instructions such as DP4A (scalar product with accumulation).

http://www.hardware.fr/news/14910/archi ... voile.html

DOC_ZENITH: ttxman Ti tu dost polopatě tvoje totálně zavádějící a nepravdivé domněnky (už po několikáté) vyvrátil. Bylo by dobré už konečně začít v tvých postech požívat slova jako "myslím si, odhaduji, atd." a ne vše vydávat za fakt a mást jiné uživatele fóra.

Co bylo na mém posledním postu divně? To že Titan XP má 4x speed int8 je ofiko. To že má rovněž slow 1/64 FP16 je také ofiko. Jde o to že mi to logicky nejde dohromady, proč by u čipu implementovalo 4x speed int8 ale neměl fast FP16. To jest vše co jsem tím chtěl říci.

Inu pokud je to jen pár instrukcí a ne full implementace jak postnul Del, tak to už dává smysl.

ttxman: konverzia z FP32 do FP16 a INT8 a opacne musi byt v GPU zadarmo. je to totiz jedna z najcastejsich operacii ktore sa vykonavaju pri pristupe z/do pamete. totiz v shadery sa pracuje s farbou pixela ako s FP32 hodnotou s rozsahom 0-1. Ale pri zapise do framebuffera sa konvertuje na INT8 s rozsahom 0-255. Textury su to iste nacitava sa INT8 a v GPU sa potom pocita s FP32. Pri HDR renderingu sa pouziva FP16 docasny framebuffer ktory je vstupom pre tonemapping aby sa z toho spravil 8bit pre monitor.

Co sa tyka podpory 4xINT8 treba sa pozriet na binarnu scitacku Binarma scitacka sa sklada z jednobitovych scitaciek. Ak potrebujete scitat 32 bitove cislo tak ich zoradite 32 vedla seba. Ako mozete vidiet tak kazda jednobitova scitacka ma carry-out ktorym sa prenasa pretecenie. Je to presne ten isty princip ako ked scitavate rucne dve velke cisla pod sebou. Scitate 6+7=13. Zapisete 3 a tu pretecenu jednotku pripocitate v dalsom kroku.

No a ked uz mate 32 bitovu scitacku tak je dost jednoduche z nej spravit aj 4x8 bit. Kedine co treba spravit je prerusit tento carry bit pri kazdej osmej scitacke. Viacmenej to stoji len 4 dalsie hradla. Podobny princip sa pouzije aj pri FP64. Mate potom vlastne ALU ktora vie ratat s FP64 ale vie sa rozdelit a ratat s dvoma FP32 naraz.

Konfigurovatelny DP rate je len potom o tom mat dve verzie ALU. Jedna kde su prepojene dve FP32 ALU a druhy variant kde nie su.

Pokud bude mit vega aspon +4% IPC proti polarisu, tak to vychazi na +12% IPC proti FURYX.
Frekvence by mela byt 1500-1550Mhz tzn + 42-47%.
Vega by teda mela byt 55-60% rychlejsi nez FURYX.

Momentalne je GTX1080 rychlejsi o 36%(nereference pak o 50%) ve 1440p.
https://www.techpowerup.com/reviews/Zot ... me/29.html

Samozrejme muze hrat roli propustnost, ktera je stejna u fury a vega.Jestli to bude jen na urovni GTX1080, tak to asi bude diky propustnosti(meli tam dat aspon 768GB/s coz je +50% proti furyx)

Ale na druhou stranu od polaris si vega prinesla novou delta color kompresi + nova rasterizace tohle prave taky resi.

Ja to beriem pesimisticky, ocakavam fail, IPC+0%, 2x vyssi tflops nez P10, 2x vyssi bandwidth, takze 2x vyssi vykon nez P10, tj. 15% nad ref. 1080. Aby som AMD mohol pochvalit za dobru robotu, tak to bude musiet byt cca 50% nad 1080.

Na titan to stacit asi nebude ten je 75% nad fury X.To by museli byt takty blizko 1700Mhz a IPC +15% aby to srovnali.

Hoši celá tahle Wega je fake. Je to jen refresh starého produktu a architektury. Teď jsem zjistil že Strejc už jí dávno má ve sklepě, a s klidem mi jí dal. Tak kdyby někdo chtěl testy oné Wegy tak řekněte.

Foto v case:

http://imgur.com/wUc7p0Z
http://imgur.com/nwFpouv

PCB:

http://imgur.com/Z76FhOy

VRM (pěkný kondíky)

http://imgur.com/NNWaggn

DOCu jsi asi nejak zmaten. Asi na tebe dolehla tize nemciny, kterou do tebe ve skole cpali. Tedy VEGA vyslovuješ jako "FEGA" a tim padem ti to nepasovalo na AMD VEGA a tu zamenil za radio WEGA. Myslim, ze ta WEGA nezobrazi ani prd, ale mozna by sla pouzit jako FM modul se zvukem do PC (TrueAudio ?).

mega52 píše:Ja to beriem pesimisticky, ocakavam fail, IPC+0%, 2x vyssi tflops nez P10, 2x vyssi bandwidth, takze 2x vyssi vykon nez P10, tj. 15% nad ref. 1080.

Prečo si myslíš, že IPC nenarastie? Tento slajd hovorí o niečom inom.
http://images.anandtech.com/doci/11002/ ... _575px.png