AMD Vega GPU

Grey je 5. jul 2017 ob 08:39 izjavil:

Senitel je 5. jul 2017 ob 07:21 izjavil:

Ejga Grey, kaj pa vsaj referenca za 11G FP16 FLOPs-ov na Polarisu? Sem kupil enga 580, pa ne potegne tolk. A ga lahko pri tebi reklamiram?

1:1 ima

Če si imel karkoli od GeForce 10xx serije, si si naredil uslugo z nakupom. Na splošno in še vedno imaš 6 TFLOPS višjo FP16 zmogljivost od GTX10xx, če to rabiš. Ni ravno Tesla P100, ampak če primerjaš ceno in FP16 zmogljivost je kar dober deal. Drugače pa imaš Vego FE (ali pa počakaj na RX Vega) in še tisto dej not pa boš imel FP16 performansa kolikor ti srce poželi. Nekaj, česar ti Pascal ne more dat.

Kaj ima ali nima? Komu zdaj verjeti?

http://wccftech.com/amd-rx-vega-benchma...
Me zanima kakšna bo cena? Okoli 550€? Pod pogojojem da so benchmarki legit

Hydros je 5. jul 2017 ob 10:49 izjavil:

http://wccftech.com/amd-rx-vega-benchma...
Me zanima kakšna bo cena? Okoli 550€? Pod pogojojem da so benchmarki legit

kakšen BS. Kako je pa zdej lahko tolk hitrejša .. anymal?

Predator X je 5. jul 2017 ob 11:20 izjavil:

Hydros je 5. jul 2017 ob 10:49 izjavil:

http://wccftech.com/amd-rx-vega-benchma...
Me zanima kakšna bo cena? Okoli 550€? Pod pogojojem da so benchmarki legit

kakšen BS. Kako je pa zdej lahko tolk hitrejša .. anymal?

Lol, ko pa je Raja govoril, da bo RX Vega hitrejša od Vega FE ste pa vsi imel cel kup izgovorov kako je AMD crap in oh in sploh XD

D3m0r4l1z3d je 5. jul 2017 ob 12:01 izjavil:

Ločiti je treba kaj bi sam kupil, se oddaljiti od sebe in uvideti. Trenutno, če so benchmarki resnični, pomeni, da je na nivoju 1 leto starega konkurenčnega čipa. Kdor to vidi kot uspeh, je AMD fanboy supreme.

Ker govorit da je crap te pa ne naredi fanboya nasprotnega campa? AMD je dokazal, da imaš lahko nek svoj režim, pa deluje. RX400 in RX500 serije sploh niso imele top end parta. Dejansko so izdal samo mid end. In se je isto prodajal. Če ima primeren performance in ceno, koga briga s čem se primerja? Skor noben Vege ne čaka z namenom že kolk, eno leto? Kdor ima keš za menjat grafične kar tko si je itaq že omislil GTX 1080Ti. Če pa ti menjava ravno sovpada z novim releasom jo pa itaq daš med izbiro in te prav en drek briga al konkurira staremu čipu al pa ne. R9 Fury je bila tud izdana pozno, pa jih je folk pokupil. In jih še vedno uporabljajo. Tud ene ne moreš dobit rabljene. Medtem ko je GeForcev kar nekaj. I wonder why...

Hydros je 5. jul 2017 ob 12:18 izjavil:

se strinjam da to ni nek tehnološki čudež in da je na nivoju overclockane GTX 1080 ki je stara 1 leto vendar bo uspeh odvisen od cene če bo cena RX Vege podobna oziroma enaka GTX 1080 jo bodo kupili le AMD fanboyi ki so čakali na ta GPU od launcha GTX 1080 in pričakujejo GTX 1080Ti performance za ceno GTX 1070 vsi drugi pa imamo Nvidio v sistemu že 1 leto

Bolj širok spekter je:
- vsi, ki so šparali do sedaj in so rekli, da bodo videli, kaj RX Vega da od sebe
- vsi ki se odločajo nadgraditi sistem pa imajo prejšnje mid range/high end grafike ali starejše
- vsi, ki imajo Freesync pa gledajo za čim še močnejšim
- vsi, ki razmišljajo o nadgradnji in bi radi imeli Freesync

Tisti, ki je hotel karkoli imet in je imel denar je pač kupil že ob izidu Pascal.

1080ti je gpu iz avgusta 2016, oziroma takrat je bil dan na trg.

D3m0r4l1z3d je 5. jul 2017 ob 14:35 izjavil:

1080ti je gpu iz avgusta 2016, oziroma takrat je bil dan na trg.

Sam fanboy kretenikus se laze kdaj je bil gtx 1080ti izsan

tikitoki je 5. jul 2017 ob 15:51 izjavil:

D3m0r4l1z3d je 5. jul 2017 ob 14:35 izjavil:

1080ti je gpu iz avgusta 2016, oziroma takrat je bil dan na trg.

Sam fanboy kretenikus se laze kdaj je bil gtx 1080ti izsan

In a word: gp102

tikitoki je 5. jul 2017 ob 18:17 izjavil:

Sam fanboy kretenikus se laze kdaj je bil gtx 1080ti izsan

Upam ,da se sam delas neumenga.

Ah ne, Anymal samo malo izkrivlja besede. Kači se na die - GP102 (prvi Titan XP, prosumer model), ki je enak GTX1080Ti, ki je šele letos marca 2017 prišel na trg kot consumer model.

Nekateri pocenjujete crypto sceno. Pred zimo lahko pozabite na dobavljivost novih grafičnih kartic po normalnih cenah.

Zadnjič mi je nekdo, ki dela v eni večji spletni trgovini pri nas povedal, da so ob objavi, da imajo xyz grafično kartico na zalogi (dobili so 5 kosov) v roku pol ure dobili več naročil za 20+ kosov.
Če so naši trgovci tako na udaru kakšne morajo biti številke šele pri večjih trgovcih.

Senitel:

Ko sem spraševal, kako bi se obnašala Fury z GDDR5, sem imel v mislih en članek, ki sem ga bral nekaj časa nazaj, a nisem našel. Ti praviš, da ne bi bilo razlike.

Quote iz Rise Of The Tomb Raider Graphics Guide:

The AMD Radeon R9 Fury X kind of backs that statement up since it was able to allocate dynamic VRAM for extra VRAM past its 4GB of dedicated VRAM capacity. We saw up to a 4GB utilization of dynamic VRAM. That allowed the Fury X to keep its 4GB of dedicated VRAM maxed out and then use system RAM for extra storage. In our testing, this did not appear to negatively impact performance. At least we didn't notice anything in terms of choppy framerates or "micro-stutter." The Fury X seems to be using the dynamic VRAM as a cache rather than a direct pool of instant VRAM. This would make sense since it did not cause a performance drain and obviously system RAM is a lot slower than local HBM on the Fury X. If you remember a good while ago that AMD was making claims to this effect, but this is the first time we have actually been able to show results in real world gaming. It is awesome to see some actual validation of these statements a year later. This is what AMD said about this in June of 2015.

Note that HBM and GDDR5 memory sized can't be directly compared. Think of it like comparing an SSD's capacity to a mechanical hard drive's capacity. As long as both capacities are sufficient to hold local data sets, much higher performance can be achieved with HBM, and AMD is hand tuning games to ensure that 4GB will not hold back Fiji's performance. Note that the graphics driver controls memory allocation, so its incorrect to assume that Game X needs Memory Y. Memory compression, buffer allocations, and caching architectures all impact a game's memory footprint, and we are tuning to ensure 4GB will always be sufficient for 4K gaming. Main point being that HBM can be thought of as a giant embedded cache, and is not directly comparable to GDDR5 sizes.

To so zame sicer samo špekulacije in še vedno ne razumem, kako naj bi HBM2 in/ali HBCC vplival pozitivno na performans... Očitno pa je, da je AMD ene pet let nazaj razmišljal o takšni arhitekturi in sedaj bomo kmalu videli fruits of their labor.

Upam, da bo RX Vega na nivoju 1080 +/- 20%, odvisno od igre. Imam občutek, da bomo videli točno takšne rezultate.


---

ps:

Nekateri tukaj "tolčete" po AMDju, da eno leto kasneje prinaša nvidia performans. Ob tem pa pozabljate, da si je tudi Nvidia vzela zadnje tri leta in arhitekturo minimalno spreminjala - Maxwell v1 podlaga. Če gremo še dlje v preteklost, pridemo do G80, ki je bila podlaga za 4 leta. (Od tistih 320MB/640MB kartic do 200 serije - razen high end, če se prav spomnim.) Žal AMD po 7970 oz. 290X ni bil konkurenčen v high end segmentu, a so vseeno delali male izboljšave na arhitekturi in ostali vsaj cenovno konkurenčni z 380, 480/580.

Najmanj kar lahko upamo, če RX Vega ne bo na nivoju 1080, je to, da je nova arhitektura dobra podlaga za prihodnost. Jaz osebno "čutim na vodi" in mislim, da bomo pozitivno presenečeni že s to generacijo...

Tudi ta leak glede RX Vega 3D Mark 11 je zelo verjetno fejk anti-promocija. Kdo pravi, da ni krivec enostavno na Vega FE disejblal 8GB HBM2 v biosu, navil na 1630MHz in to testiral? Sedaj pa to prodajajo kot RX Vega leak? Namreč to bi se potem videlo kot 8GB kartica in ne 16GB.

Sigurno je fejk, mora biti vsaj na nivoju gp102 ali boljša, drugače brez veze.

Kaj, da bi po 14 mesecih izdali malo boljšo od gtx 1080 (gp104)? HBM2, 500gbps prepustnosti, state of the art 14nm, dozorel proces,...

Jst je 6. jul 2017 ob 12:53 izjavil:

Senitel:

Ko sem spraševal, kako bi se obnašala Fury z GDDR5, sem imel v mislih en članek, ki sem ga bral nekaj časa nazaj, a nisem našel. Ti praviš, da ne bi bilo razlike.

Quote iz Rise Of The Tomb Raider Graphics Guide:

The AMD Radeon R9 Fury X kind of backs that statement up since it was able to allocate dynamic VRAM for extra VRAM past its 4GB of dedicated VRAM capacity. We saw up to a 4GB utilization of dynamic VRAM. That allowed the Fury X to keep its 4GB of dedicated VRAM maxed out and then use system RAM for extra storage. In our testing, this did not appear to negatively impact performance. At least we didn't notice anything in terms of choppy framerates or "micro-stutter." The Fury X seems to be using the dynamic VRAM as a cache rather than a direct pool of instant VRAM. This would make sense since it did not cause a performance drain and obviously system RAM is a lot slower than local HBM on the Fury X. If you remember a good while ago that AMD was making claims to this effect, but this is the first time we have actually been able to show results in real world gaming. It is awesome to see some actual validation of these statements a year later. This is what AMD said about this in June of 2015.

Note that HBM and GDDR5 memory sized can't be directly compared. Think of it like comparing an SSD's capacity to a mechanical hard drive's capacity. As long as both capacities are sufficient to hold local data sets, much higher performance can be achieved with HBM, and AMD is hand tuning games to ensure that 4GB will not hold back Fiji's performance. Note that the graphics driver controls memory allocation, so its incorrect to assume that Game X needs Memory Y. Memory compression, buffer allocations, and caching architectures all impact a game's memory footprint, and we are tuning to ensure 4GB will always be sufficient for 4K gaming. Main point being that HBM can be thought of as a giant embedded cache, and is not directly comparable to GDDR5 sizes.

To so zame sicer samo špekulacije in še vedno ne razumem, kako naj bi HBM2 in/ali HBCC vplival pozitivno na performans... Očitno pa je, da je AMD ene pet let nazaj razmišljal o takšni arhitekturi in sedaj bomo kmalu videli fruits of their labor.

Pismo no o tem sem imel že milijardo postov tle gor...

Poraba RAM-a na GPU-ju, ki jo javi driver in posledično tooli ala GPUz je trenutna poraba rama na GPU-ju. Ta poraba rama nima kakšne velike povezave s tem koliko GB resource-v igra dejansko alocira čez D3D. Driver morda rabi ekstra stvari imet v ramu ker npr. tranzicije iz rendertargeta -> teksturo lahko rabijo ekstra korak, ker TMU-ji na GPU-ju ne znajo nujno prebrat tisto kar so ROP-i zapisal (zaradi kompresije). In ker driver kontrolira alokacijo lokalnega rama tudi ni nujno, da bo vse pristalo v GPU ramu. Ali ker ga ni dovolj, ali ker so druge lokacije bolj primerne za dani resource. Recimo, ko je NV v Fermi časih bila za AMD-jem v količini on board rama je driver specifično in namensko vse index bufferje pustil v sistemskem ramu in ko jih je GPU rabil jih je tudi bral direkt iz sistemskega rama.

VSI GPU-ji ZADNJIH 10 LET so sposobni hendlat memory overcommit. To pomeni bodisi uporabo resource-a direktno iz sistemskega rama. Bo bandwidth pač 16GB/s za branje tistega specifičnega resource-a in polni bandwidth za vse ostalo. Bodisi bo driver evictal nek redko uporabljen resource (ali več njih) iz GPU-ja nazaj v sistemski ram in fetchal potreben resource is sistemskega rama v GPU ram.

Pri tem je treba seveda gledat kaj igre dejansko počnejo in kaj se dogaja if frame-a v frame. Ene igre bodo naložile vse teksture in ostale resource potrebne za cel level ob loadingu. To pomeni, da boš v ramu imel teksturo in geometrijo tudi za finalnega level bossa, čeprav ga ne boš videl še 10 minut.
Druge igre že same obravnavajo GPU ram kot cache in nalagajo v RAM samo stvari, ki jih user lahko vidi v nekem doglednem času (virtual texturing). Igra lahko zelo dobro ve katere teksture lahko igralec vidi, ker konec koncev ve kje je kamera, kako hitro se kamera premika in katere teksture so "za vogalom".
Po drugi strani imajo grafični driverji ekstremno radi za cel frame komand pri sebi in iz tega sledi, da prav tako vedo katere teksture bo GPU dejansko rabil v kratkem. Poleg tega je tukaj komplicirana hevristika kaj se evicta v sistemski ram in kaj se ne evicta praktično pod nobenimi pogoji.

Že z 10 let starim hardware-om (to je kaj 1GB GPU rama max?) lahko developer alocira tudi 16GB resource-ov. Če bo igra sledila navodilom, ki jih dajejo IHV-ji (prvo alociraj pomembne resource) in se bo working set iz slike v sliko spreminjal dovolj počasi ti kot igralec ne boš ugotovil, da imaš premalo GPU rama, niti ti GPUz tega ne bo povedal.

Kar je sedaj glaven štos Vege je tole: recimo da imaš polno zaseden GPU memory. Na GPU pride Draw komanda, ki na koncu rabi en teksel iz ene 2k x 2k 32bit teksture (pač vidiš en pixel, GPU mora rabi in mora prebrat 16 bytov za filtering). Tradicionalno to pomeni, da bo moral driver ta scenarij vnaprej ulovit (Draw rabi teskturo, ki je ni na GPU), ugotovit kater resource (ali več njih) je najmanj uporabljan (LRU) in zasede vsaj 30MB ga ruknit iz GPU rama in uploadat 30MB na GPU (2k x 2k, 32 bit, full mip chain). Na Vegi driverju tega ni treba ugotavljat. Ko bo TMU hotel samplat ta teksel se bo zgodil page fault, GPU bo ruknil 64KB (velikost page-ov je sicer konfigurabilna) LRU page v sistemski ram in potegnil 64KB page v GPU ram in nadaljeval delo. 30MB vs. 64KB.
Seveda ti pa to NIČ ne pomaga, če igra hoče vsak frame na 8GB grafi dejansko teksturirat cel 16GB dataset. Vega FE je sposobna poteksturirat 400G texlov na sekundo (1,6TB če je vsak teksel unikaten).

Ja, vedno dobro napiše , itak ne bomo razumeli popolnoma, ker se vse na nekaj nanaša kar je preizkusil, preučil, naredil,... izkušnje potem vse povežejo v celoto, ki jo dejansko res samo on razume kar se tega tiče. Predvsem pa nam je lahko hitro jasno, da je ogromno dejavnikov in zato pač ostaneš pri branju rezultatov in potem en aggregate. Recimo Vega RX, ko bo izšla, vs. gp104 in gp102 v 15 modernih igrah. Tako pač je in za končnega uporabnika je to tudi edino zares pomembno.

HBC pač ni isto kot trenutno sharanje RAMa z grafičnim. To obstaja že od Windows Viste iirc. HBC gre precej preko tega.

Jst je 6. jul 2017 ob 20:14 izjavil:

Torej praviš, da bi Vega brez HBCC delala enako hitro?

Kje sem to napisal? Paging da veliko bolj fino kontrolo nad vsem skupaj. Sem dal primer trenutno moraš spravit v GPU ram kompleten resource (kar se v D3D12 dodatno zakomplicira, ker je resource cel heap in lahko vključuje tud 100 tekstur, kar je bil razlog za "požrešnost" po ramu prvih D3D12 iger BTW).
A ni čisto jasno, da se bo 64KB page evical/uploadal čez PCI-Ex hitreje kot kompleten 30MB resource? 64KB je mnogo manj kot 30MB. 4us je mnogo manj kot 1,875ms. 1,875ms je dip iz 60FPS na 49FPS by the way, ker moraš swapnit vsaj 60MB skupaj. Ali pa iz 140FPS na 92FPS. In če je vprašanje: kaj pa če rabiš cel 30MB resource? V primeru tekstur ga v enem frame-u nikoli ne rabiš! To je 2048x2048 32bpp surface + 1024x1024 32bpp mip + 512x512 32bpp mip + 256x256 32bpp mip + ... + 1x1 32bpp mip.

Jst je 6. jul 2017 ob 20:14 izjavil:

Senitel: To kar si napisal, je čisto normalna in znana pot skozi CPU-GPU[VRAM/SysRAM]. Če se izkaže, da je HBCC samo glorified memory controler... tudi prav. AMD pravi da ni. AMD je demonstriral, da špil laufa počasneje, ko je HBCC izklopljen. We'll see soon enough.

Seveda ni samo glorified memory controler... Velik problem pri tem bo (je?) driver. Kot že rečeno NV ima tudi page migration v Pascalu (in VM v že od Maxwella naprej, da lahko GPU sam migrira stuff brez CPU). Ampak zadeva (trenutno) NI vklopljena za grafičnem stacku.
Driver se bo moral odločit kaj sploh migrirat (če bo nek page dostopan samo enkrat na frame ga lahko mirno prebereš vsakič čez PCI-Ex). Potem bog ne daj da bi se kakšen page od render targetov migriral v sistemski ram. Bog ne daj da se ta "built in" page migration ne stepe s kakšnim software-skim page migrationom v igrah. Določene teksture se bodo morale vnaprej v veliki meri zmigrirat na GPU. Ker če bo pa vidna cela 2048x2048 tekstura na zaslonu se pa nočeš zanašat na to, da bo GPU page faultal in pobiral stvari "on the fly" k sebi... Ker bo faultnil 256x (pri 64K page size) in to bo še vedno pipeline stall. Stuff like that.
NV trenutno "pravi", da je to prekomplicirano. Se pa zna spremenit. Po drugi strani pa NV trenutno nima z ramom podhranjenih GPU-jev (no GTX 1060 3GB morda). Vega bo pa gotovo tudi v 4GB varianti...

Tule je lepo razloženo (vključno s profiler rezultati). Poglej si predvsem "What Happens on Kepler" in "What Happens on Pascal".

Ne, ni bilo mišljeno, da CPU porabi 40% svojega časa za GPU.

Na tisti predstavitvi Game Engine in tech demota je bilo mišljeno tako, da:

Game Engine je razdeljen na:

20% Game Mechanics / Internal World
5% I/O
5% Network
10% Sound
20% Fizika
40% GPU
----
=100%

(Te številke so iz riti potegnjene, razen 40% za GPU.)

Ne spomnim se več, kdo je imel to predstavitev in Q&A, ker je več kot 5 let, sigurno, če ne več.

D3m0r4l1z3d je 6. jul 2017 ob 20:25 izjavil:

itak ne bomo razumeli popolnoma

D3m0r4l1z3d je 6. jul 2017 ob 20:25 izjavil:

ki jo dejansko res samo on razume kar se tega tiče.

No, na tej točki bi te opomnil, da ti zase govori. Svojega neznanja ne posplošuj na vse.

D3m0r4l1z3d je 7. jul 2017 ob 08:13 izjavil:

Eno je da misliš, da razumeš, a ko bi te vprašal kaj in kako bi pa samo gledal. Napisal sem v smislu, da če se ne ukvarjaš z istim problemom, ne boš razumel enako kot nekdo, ki na tem dela že leta. Bom pa lahko tudi v tvojem imenu napisal, ker vidim, da nisi razumel že tega kar sem jaz mislil dopovedati, kaj šele Senitel pametovanje. Verjetno bolj razumeš od mene, ampak on je napisal glede neke kompleksne zadeve in če misliß, da si res razumel iz teh parih povedi kaj ta stvar dejansko dela in v katerih primerih to velja, vsaka ti čast.

Sej, če ni videl dokumentacije za HBCC potem tudi on ne razume, ampak špekulativno implicira delovanje glede na lastno poznavanje tematike - ugiba. Samo, da pri njemu to malo bolj realistično izgleda, ker zna metat okol ta prave termine.

Grey je 7. jul 2017 ob 08:32 izjavil:

D3m0r4l1z3d je 7. jul 2017 ob 08:13 izjavil:

Eno je da misliš, da razumeš, a ko bi te vprašal kaj in kako bi pa samo gledal. Napisal sem v smislu, da če se ne ukvarjaš z istim problemom, ne boš razumel enako kot nekdo, ki na tem dela že leta. Bom pa lahko tudi v tvojem imenu napisal, ker vidim, da nisi razumel že tega kar sem jaz mislil dopovedati, kaj šele Senitel pametovanje. Verjetno bolj razumeš od mene, ampak on je napisal glede neke kompleksne zadeve in če misliß, da si res razumel iz teh parih povedi kaj ta stvar dejansko dela in v katerih primerih to velja, vsaka ti čast.

Sej, če ni videl dokumentacije za HBCC potem tudi on ne razume, ampak špekulativno implicira delovanje glede na lastno poznavanje tematike - ugiba. Samo, da pri njemu to malo bolj realistično izgleda, ker zna metat okol ta prave termine.

Glede na to, da se to leta in leta razvija ter da ni nenadnih presenečenj ali revolucije, verjetno niti ne ugiba kaj dosti, kar pa ne pomeni, da se ne zmoti.

m0LN4r je 7. jul 2017 ob 09:28 izjavil:

Babica je po vsem tem prebranem rekla, da bo imela Vega Gaming "veliko" prednost v igrah, ki so ze zunaj. Reci pisi, eno leto star Doom ipd. naprimer ker je o igri ze vse znano, o enginu tudi, driverji so bili delno ze pofixani, ravno tako je bila tudi igra popatchana.

Zdaj pa samo vse to skup zmetat in optimirat v driver za Vego in HBC.

Vprasanje je, kako bo z HBCjem v igrah, ki bodo izsle po izidu Vege. Bo spet treba po vsakem izidu igre, cakat 1-2 mesca za wonder driver, ki bo potem izkoristil ta nov feature???

Sicer pa je IMO tudi to razlog za splavitev Vege FE, da se le ta razsiri in bo sodelovanje z devsi in AMD pri razvoju nove igre/driverjev steklo veliko lazje.
Lahko pa da se povsem motim in se do Navy ne bo spremenilo nic kaj prevec.

Ko bo Navi, bo tudi naslednik Volta pa bomo spet tam tam. Btw, imaš pa kul babico

Če ima grafična dodatne CAD in GL funkcije ne more biti hitrejša brez njih v igrah saj je logično ampak dobro prodaja je prodaja saj zato so jo dal prej v prodajo, pač stane več zato.

Kater Quadro?