Je dobry psat k takovym vecem "myslim si", "podle me", "slysel jsem", "mozna", atd... Nejde něco psat jako fakt, když to nejde ověřit, nebo dokázat. To ze HBM2 budou pravdepodobne drahy a vůbec vyrobne cela ta VEGA karta a ze AMD proste nema ekonomicky na to udelat separatne vypocetni a herni cip, tak to napere vse do jednoho, to si myslim taky, ale nemuzu to vydat za fakt, ze třeba bude AMD 8GB kartu dotovat, coz moc nedava ekonomicky smysl.
Dal u prvnich HBM byl problem s latencema, který to u Fiji zabili a cela ta propustnost sla do kelu. U HBM2 by to melo byt uz ok, ale při tahani z RAM je stejne bottleneck rychlost PCI-e sbernice, takze jakmile GPU sahne primo do RAM, fps jdou dolu. Pokud chce AMD používat pamet jen jako buffer, musí to umet aplikace, nebo nejak donutit aplikaci, aby do VRAM nervala kvanta zbytečných dat, kdy by GPU musela sahnout pro aktualni data do RAM primo.
CageJ píše:
To ano ale tu sa bavime o 4Mbit sirokej zbernici.. cip dokaze velmi rychlo tahat z pamati..
Ani by som sa necudoval, ak bude NVMe odporucane SSD....
Dokonca tipujem, ze karta bude mat nejaky 1GB buffer, nieco pod.
4Mbit?? Spis se mluvi o 2048bit, to je trosku rozdil. Ve finale to nebude nijak zvlast rychlejsi nez >256bit GDDR5X. Ostatne rychlost pameti primo u GPU je jaksi vedlejsi, kdyz tam pozadovana data nejsou a leze se pro ne pres PCI-E do systemove RAM. Typ SSD nema s timhle zadnou souvislost, nebo bys snad chtel, aby GPU dotahovalo textury rovnou z SSD?
Hladis píše:Dal u prvnich HBM byl problem s latencema, který to u Fiji zabili a cela ta propustnost sla do kelu.
Ehm, what? Byl by link?
Mimochodem, HBM jsou na tom ohledně latencí právě líp jak GDDR5 hlavně díky vysoké šířce pásma, to potvrdil i Joe Macri, autor GDDR3, GDDR4, GDDR5 i HBM standardu
The PHY’s are laid out on the edges of the chips to keep the latency to a minimum. HBM does decrease the latency as data is for the most part no longer being moved horizontally to a central part of the die like it was with GDDR5. With HBM it is pushed down vertically and that really helps reduce the latency. HBM has more channels and banks and that helps improve pseudo random access, which is critical to reducing latency for the HPC market.
Uz se to resilo davno a bylo i psany s ohledem na Vegu, ze HBM2 vyresi problem latenci u HBM. Znova to hledat nebudu. Ostatne potvrdil mi to i zdejsi vyvojar a kdysi sem to jeho zjisteni sem psal, ze to dela u nekterych aplikaci problem a shazuje to vykon.
CageJ píše:
To ano ale tu sa bavime o 4Mbit sirokej zbernici.. cip dokaze velmi rychlo tahat z pamati..
Ani by som sa necudoval, ak bude NVMe odporucane SSD....
Dokonca tipujem, ze karta bude mat nejaky 1GB buffer, nieco pod.
4Mbit?? Spis se mluvi o 2048bit, to je trosku rozdil. Ve finale to nebude nijak zvlast rychlejsi nez >256bit GDDR5X. Ostatne rychlost pameti primo u GPU je jaksi vedlejsi, kdyz tam pozadovana data nejsou a leze se pro ne pres PCI-E do systemove RAM. Typ SSD nema s timhle zadnou souvislost, nebo bys snad chtel, aby GPU dotahovalo textury rovnou z SSD?
Jojo preklep kBit
AMD RYZEN 2700X 4.2GHz@watercooled, 32GB DDR4 2,8GHz, AsRock B450 GAMING K4, RIOTORO GOLD 650W; ASUS DUAL RTX 2060; CoolerMaster ML500; AMD RYZEN 3600X, NOCTUA NH-D15, ASUS STRIX B450-F GAMING, SuperFlower GK550, 32GB CL14 G.SKILL 3200, FRACTAL DESIGN XL R4, ASUS STRIX RTX 3080 OC; APPLE MacBook AIR M1 iPhone 12 Pro 128GB
Jinak co se tyce HBM na Fury, testy celkem jasne prokazaly, ze s OC pameti vykon stoupe... Cili jsou dve moznosti:
1. realna propustnost HBM silne zaostava za teoretickou, pro GPU to nestaci, proto po OC stoupnou fps
2. latence jsou vetsi nez by bylo zdravo a s OC se snizuji, coz ma pozitivni vliv na vykon
Nebo samozrejme kombinace obojiho, kazdopadne tam neco bylo (resp stale je) spatne.
havli:
Nevim zda si to dobře pamatuju, ale mel tam problem prave s pomalym pristupem a docházelo k propadu vykonu, pokud na to aplikace nebyla uzpusobena. Ale ten propad v globale nebyl enormni. Nekde na foru jsem to sem kdysi daval, když jsem to info dostal, ale hledat to je na dlouhy lokte.
"HBM is showing initial latency is a touch slower than GDDR5, but once the return data comes, it is absolutely faster...so slightly delayed initial response."
V tom hraje roli i horsi cache system a další bottlenecky jako fillrate a triangle rasterization ..... vcelku je to velkej cip s papirove velkou silou, ale shazuje ho hromada bottlenecku, kdy pak dnes ma problem nekde i s RX 480. Vega by mela prinyst dost zmen architektury a oprav, aby se tohle neopakovalo.
"HBM is showing initial latency is a touch slower than GDDR5, but once the return data comes, it is absolutely faster...so slightly delayed initial response."
Odkud to je? Žádal jsem link, ne o citaci z neznámého zdroje.
//BTW, AMD v prezentaci "Advanced Shader Programing on GCN" z GDC 2017 mluví o Vega uarch jako o GCN5, tzn. GCN ISA a kompatibilita zůstává zachována
Tak tohle mě rozsekalo. Co myslíte, je to apríl? Je to na apríl dost slušně udělaný.
Akorát ten render karty vypadá nekvalitně a pak ještě IMHO haprujou ty jména, Radeon RX Vega Rage X Fury, to je prostě moc dlouhý. No a ty endnotes + vypnutý komentáře. Jinak teda bych řekl že prvnotřídní job. Jestli ti zmetci z AMD udělali apríla jako virál a ty informace jsou reálný, tak mě asi odnesou
Ja by som nebol prekvapený, keby tam bolo aj nejaké pravdivé info. Tie parametre Vegy by mohli byť aj reálne. Na fake je 4096SP a 1600+mhz podľa mňa celkom blízko realite, skôr by som čakal, že do podvrhu dajú prehnané parametre ako napríklad 8192SP a 2500+mhz, keď na iných slajdoch máš veci ako 2x výkonnejší ako konkurencia, 4x lepší výkon/w, 2x lepšie IPC.
Naposledy upravil(a) THANATOS dne sob 1. dub 2017, 17:45, celkem upraveno 1 x.
THANATOS píše:Ja by som nebol prekvapený, keby tam bolo aj nejaké pravdivé info.
hehehe pobavilo
aby to nebolo nakoniec tak, ze tubuľkovy vykon na urovni GTX 1080/1080 Ti
bude mat akurat nejaka 2 jadrova zlatanina Vegy
s v reale bude asi tak pouzitelna, ako predchadzajuce modely ala Pro Duo a pod.
THANATOS píše:Ja by som nebol prekvapený, keby tam bolo aj nejaké pravdivé info.
hehehe pobavilo
aby to nebolo nakoniec tak, ze tubuľkovy vykon na urovni GTX 1080/1080 Ti
bude mat akurat nejaka 2 jadrova zlatanina Vegy
s v reale bude asi tak pouzitelna, ako predchadzajuce modely ala Pro Duo a pod.
dufajme , ze nie
hehehehe aj ty si ma týmto príspevkom pobavil.
12.5 TFlops Vega je realita a nikde som nevidel správu, že to je dual gpu.
Improvements for general performance:
- GCN3 introduced delta color compression. Including ability to sample/load compressed textures without decompress step.
- GCN3 improved geometry tessellation performance
- GCN4 improved geometry performance in general (including fast strips, primitive discard, etc).
- GCN4 improved delta color compression.
- GCN4 added instruction prefetch (reduces pipeline latency, again helps with geom bottleneck).
- GCN4 improved async compute scheduling (GPU side)
GCN5 (Vega) adds these general performance improvements:
- L2 cache includes L2 ROP cache (L1 ROP caches under L2). Don't need to flush caches between pixel shader passes.
- Tiled rasterizer. Reduces overdraw, bandwidth and makes ROPs more efficient in general.
- Improved geometry pipeline (including proper load balancing, up to 2x higher peak throughput)
- General purpose memory paging system
(I didn't list features that don't bring performance improvements without programmer intervention)
All of these improvements mean that GCN5 should run general purpose pixel/vertex shader code much better than GCN2. GCN5 has most of the same tricks that are seen in modern Nvidia GPUs.
There are nice compute improvements as well, but they need special programmer support (DPP, SDWA, FP16). We will see the real impact of these improvements when DX12 SM 6.0 becomes available. Doom is already using these features with Vulkan, resulting in nice gains.