- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- Milyen billentyűzetet vegyek?
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Így építsd a billentyűzeted!
- Házimozi belépő szinten
- Milyen egeret válasszak?
- Hobby elektronika
Hirdetés
-
Lunar Lander Beyond teszt
gp Nagyon sok évtizeddel az eredeti Lunar Lander megjelenése óta ismét ezen a címen jelent meg Atari logóval egy játék. Vajon mennyit javult a játékdesign a hetvenes évek óta?
-
A franciáknak elege van abból, hogy minden gyerek mobilozik
it Vissza akarják szorítani a gyerekek és tinédzserek közösségi média- és okostelefon-használatát.
-
iPaden is vége az App Store monopóliumának
ma Ősztől lehet alternatív alkalmazásboltból telepíteni az EU tagállamaiban.
-
PROHARDVER!
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Petykemano
veterán
Igen, csak amiről beszélsz, az 2020-ban lesz érzékelhető realitás. Látható, hogy hiába compute nehéz a vega 10, ez jelenleg - és a következő két évben se - nem hasznosul. Azt gondolom, hogy az intelnek készített Vega M pont ezért olyan, amilyen. Jól látható, hogy a vega56 és a vega64 közötti CU differencia alig-alig hasznosul. Nemsokára itt a vega 20. Tulajdonképpen ha ennyire közeledik ez a compute culling (hogy már mindjárt 2 év múlva meg is érkezik) bőven elég lett volna abba ilyen magasra húzni a CU-k számát. Persze világos, hogy ez csak a gaming tekintetében igaz, minden máshoz meg hasznos, tehát a lapkából emiatt nem lett volna kivágható.
Ha jól értem, amit mondasz arra lehet számítani, hogy az SE-k száma nem fog nőni, hanem csak A CU-k száma az SE-kben.
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
Akkor légyszíves mondd ki:
Valójában ma is lehetséges lenne 4x16-os tömbök helyett pl 6x12-es tömbök értelemszerűen azon az áron, hogy a teljesítmény/tranzisztor mutató romlana.De egyébként zárójelben kérdezem, ha ez így van, hogy nincs skálázódási akadály az SE-k számával kapcsolatban, ha mögé tudod tenni a szükséges multiprocesszor teljesíményt (ami elmondásod alapján tehát 3tflops / SE), akkor valamit nagyon rosszul csinál az AMD.
Egyrészt az nvidia kártyákban láthatólag jobban hasznosulnak a tflops-ok. 8-9tflops számítási kapacitással hozza azt, amit a vega 12tflops-szal. És a 11-12ftlops (+33% vs 1080) az ehhez képest 30-40%-kal jobb eredményt, miközben 50%-kal több az SM.
A te állításod tehát az, hogy
- az AMD 4x16-os tömbje a lehető legjobb megoldás és a 4SE-hez szükséges a 16 CU, vagyis a 3 tflops/SE. Ennek némileg ellentmondanak azok a tesztek, amelyek azonos órajelen hibahatáron belüli különbséget mutattak a vega56 és vega64 között.
- Az AMD ha a 12tflps számítási kapacitást 4 tömb helyett 6 tömbbe szervezné, akkor 2% és 7-8% közötti teljesítménytöbbletet adna.Másrészt az AMD akkor a polarist nagyon elronthatta. Ugyanis az is 4 SE-be van szervezve, miközben ott egy SE-re csak mindegy másfél tflops jut.
Vagy mégse? A vega64 több mint kétszer akkora számítási kapacitással rendelkezik, ehhez képest inkább csak 50-60%-kal erősebb annál (kivéve persze a 4K-t, ahol a compute tényleg elfogy a polarisban) Ebből az 50-60%-ből 15-20%pontot a magasabb órajel magyaráz. Tehát a 77%-kal több CU csak 30-40%-nyi többlet teljesítményben hasznosul. Itt azért lehet némi deficit, nem? (Különösen ha azt feltételezzük, hogy már a polaris is compute nehéz volt.)Harmadrészt ha tényleg a 3tflops/SE vezet jó eredményre, akkor az Intel miért volt olyan hülye (vagy miért hagyták, hogy olyan hülye legyen), hogy 24CU-t 4SE-be szervezzen, amikor ez nettó pazarlás?
Találgatunk, aztán majd úgyis kiderül..
-
#45185024
törölt tag
válasz Petykemano #35102 üzenetére
Nyugodj meg és egyél egy csokit.
DigitalFoundry végigveszi a pletyiket és a PS5-től egy íven át a Naviig végigbeszéli főleg a teljesítményeket.. Érdemes végignézni pont egy csokievésnyi idő...
Ez nem olyan okosan tudományos mint a Ti beszélgetésetek de egy picit populárisabb[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz Petykemano #35101 üzenetére
A compute culling nem közeledik, hanem már itt van! Ezt nem tudják halasztani, mert a poligonok számát ugyan lehet növelni, de beleesnek a hardverek a quadraster problémába, amit egyik API sem kezel. Vagyis ha növeled a poligonok számát, akkor növelni kell a kivágás hatásfokát, különben a hardver egyre több haszontalan munkát végez. Arra meg felesleges tranzisztorokat költeni, hogy egyre több úgy sem látható háromszöget számoljunk. Emiatt állt át minden nagy stúdió GPU-driven pipeline-ra. A jövőben ez természetesen fejlődik, mert például hasznosítható itt a rapid packed math, az aszinkron compute és a shader modell 6.0. Szóval igen, idén már nem csak szimpla compute culling lesz, hanem ennek az optimalizálása.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz Petykemano #35102 üzenetére
Persze, hogy lehetséges. Nem azzal van a baj, hogy nem lehetséges, hanem azzal, hogy nem éri meg.
A Pascalt nem arra tervezték amire a Vegát. Sosem volt cél, hogy működjön olyan terhelés mellett is, amin a Vega még vígan elvan. Ez az élettartam, amit beleterveznek. A megjelenés után kb. két év. Ez különösen látszik a professzionális alkalmazásoknál. A Vega még vígan működik, amikor egy Pascal már rég out of memory-t kiáltott. Ilyen egyébként a Polaris is, az is megáll kb. annál a határnál, ahol a Pascal feladja.
A Polaris belső buszrendszere nagyon eltért attól, amit a Vega használ. Nem tudott skálázódni az SE 12 CU-nál tovább. Hiába építettél volna be többet, azokra nem volt meg a busz sávszélessége. Ez egy fix limit, míg az optimális konfiguráció 9. A Vega esetében lecserélték a belső buszrendszert egy modernebbre, amely busz legalább kétszer gyorsabb is, így teljesen más konfigurációk is elérhetővé váltak. Be tudtak építeni úgy is 16 CU-t, hogy a busz bőven tudja őket etetni. Mehet egyébként még tovább is, bár a fix limitet nem adták meg, állítólag 28 körül van.
Az Intelnél nemrég kiderült, hogy rengeteg Vega részegység nem is volt nekik elérhető. A Semi-Custom üzletág még nem tudta őket beemelni a portfólióba, így abból kellett főzniük, amit az AMD felkínált. Nem kapták meg a hatékonyabb ROP-okat, a DSBR-t, a modernebb belső buszt, még az új nCU-t sem, ahogy a sokkal gyorsabb setup motorok is kimaradtak. Egyedül a HBCC-t tudták beemelni. Minden más Polaris alapú fejlesztés. Tudtommal a Semi-Custom idén még nem tud Vega dizájnt tervezni. De jövőre már igen, de akkor sem a 7 nm-es portot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
szmörlock007
aktív tag
válasz #45185024 #35103 üzenetére
Üdv
Hát nagyon kíváncsi leszek a cpu részre. Szerintem zen2-es magok lesznek benne, 6 vagy 8 mag, ami akkor is hatalmas előrelépés, hogyha igazából, főleg konzolnál a gpu-ra támaszkodnak inkább a fejlesztők. A gpu érdekes. Ha 2019 év végén jön akkor navi, ha viszont 2020 év végén akkor esetleg benne lehet a most még Next-gen -ként feltüntetett fejlesztés, ami (szigorúan csak a pletykák alapján) jelentősen eltérhet a jelenlegi gcn-től. Amúgy ha ez igaz, a 2020-as megjelenés reálisabb, márcsak azért is mert ez az amd-nek is jobb lenne. Hiszen nem feltétlenül lenne szerencsés, ha kijönne a gcn6(Navi)-tal a ps 5 erre rá egy évre jelentősen más architektúrával jelentkezne az amd. Ha már alapból az új arch-al jönne a konzol, akkor a gcn-hez hasonlóan a konzol életciklusa alatt segíthetné az új uarch optimalizálását.
Memória tekintetében pedig vagy gddr6, vagy ha 2020-ban jön, akkor a hbm3 sem azonnal elvetendő megoldás sőt. Ugyanis tervek szerint hbm 3 az dublázhatja az 1 stack által elérhető sávszélt és mennyiséget, ergó 2 stack-el lehetne hozni 16-32 gigát és 800-1000 Gb/s-es sávszélt. -
Looserke
őstag
2018-ban várható valami új középkategóriás VGA az AMD-től? Lassan itt az ideje, hogy lecseréljem az öregedő 7870XT-met és a monitorom is elég koros már. Ezért mindenképpen egy freesync-es monitor és valami AMD VGA kellene. Az RX580 árak kezdenek lassan normalizálódni (bár még mindig vagy 30-40K-val drágábbak, mint kellene), de ha pár hónap múlva jönne valami középkategóriás AMD mondjuk 12 vagy 7nm-en emberibb fogyasztással, akkor várnék még egy darabig...
-
Carlos Padre
veterán
"Az Intelnél nemrég kiderült, hogy rengeteg Vega részegység nem is volt nekik elérhető. A Semi-Custom üzletág még nem tudta őket beemelni a portfólióba, így abból kellett főzniük, amit az AMD felkínált. Nem kapták meg a hatékonyabb ROP-okat, a DSBR-t, a modernebb belső buszt, még az új nCU-t sem, ahogy a sokkal gyorsabb setup motorok is kimaradtak. Egyedül a HBCC-t tudták beemelni. Minden más Polaris alapú fejlesztés. Tudtommal a Semi-Custom idén még nem tud Vega dizájnt tervezni. De jövőre már igen, de akkor sem a 7 nm-es portot."
Ennyit arról, hogy jön idén a ps5
[ Szerkesztve ]
Genyó vagyok, ha hülye vagy megmondom.
-
#45185024
törölt tag
válasz szmörlock007 #35106 üzenetére
Teljesen logikus a gondolat meneted csak annyira ellentétes infók jönnek.
6:28-nál állítsátok már meg azt a videót. Káprázna a szemem ???
Mit láttok 2018-ra? milyen GPU-t és milyen memóriát ?[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Miben? Nekem volt egy darabig Vega 64-em itthon, és megnéztem rajta a Wolf 2-t a Radeon GPU Profilerrel. Egyáltalán nem tűnt úgy, hogy rossz lenne a hardver belső kihasználása. És ez ugye ez hardveres nyomkövető, tehát nem mérhet félre mint más profilozó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz szmörlock007 #35115 üzenetére
Később lett tervezve. Egészen más igénybevételre. Ezért van a Vega és a Volta között nagyon sok dizájnbeli hasonlóság. A Voltát már később tervezte az NV is, így ők is úgy építették fel a multiprocesszort, hogy az jó legyen 2019-re is. A Pascalt annyival korábban tervezték, hogy nehéz volt behatárolni a 2019-es igényeket.
Voltak ilyen dolgok régen is. Lásd GeForce 2 Ultra és GeForce 3 váltása. Az elején gyorsabb volt a GeForce 2 Ultra, mert a GeForce 3-at már más shader modellre tervezték. De az újabb shader modellben már a GeForce 3 volt gyorsabb.
Nem véletlen, hogy a shader modell 6.0-val hirtelen az NV és az AMD is problémának találta az LDS pressure-t, és reagáltak rá az architektúrában, míg a korábbi dizájnok ezzel a kérdéssel nem is foglalkoztak. Nem lettek az NV és az AMD mérnökei hülyék, hanem csak felkészültek valamire. Az már egy mérnöki kérdés, hogy miképpen, az AMD megoldása automatikusan működik, míg az NV megoldására direkten írt kódok kellenek, de a végeredmény ugyanúgy az LDS pressure probléma kezelése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ribi
nagyúr
válasz szmörlock007 #35115 üzenetére
Mert egy 200Le traktort sem hasonlítasz egy 200Le személy autóhoz gyorsulásban.
Tény, hogy közelebb van hozzá, de mégis teljesen más. -
Petykemano
veterán
Lehet, hogy neked már azt mondták az eligazításon, miután kiadták a drivert, hogy "NA itt van, eljött" (vagyis jöhet, hehe)
De ha tényleg itt lenne a compute culling, akkor a vega64-nek és vega56-nak a brutális compute teljesítményével számos tesztben kimagasló teljesítményt kéne nyújtania. Ehhez képest nem. Mert lehet, hogy a technológia kész, de még nincs itt. Ugyanúgy, ahogy a dsbr kész, de nincs itt, primitive shader kész, de nem kész. stbstb
Egyébként persze a cullingnak minden céljával egyetértek: spóroljuk meg, amit lehet. Ha néhány olcsón beépíthető CU-val megspórolható csomó setup, csomó geometria és még több CU és pixel engine, akkor kiváló. De ilyen játék ha van is olyan, mint a fehér holló.Bízzunk benne, hogy 2019-ben, amikor szerinted a Vegának még az életciklusa tartani fog, akkor a compute culling segítéségvel már tényleg el fogja érni a vega az 1080ti teljesítményét..
Egyébként ha már itt tartunk, nem gondolod, hogy az AMD számára problémás ez a hosszúra tervezett életciklus? Ha úgyis olyan könnyű szimulátorban tesztelni, akkor mi lenne, ha inkább 2-3 helyett 1-2 évre terveznék az életciklust és akkor például kijöhetett volna, hogy a gaming piacon a túltápolt CU-k nem fognak kifizetődni, mert 1-másfél éven belül nem fog elterjedni a a compute culling pl. Tehát elég csak a következő terméknél számolni azzal, a kurrens termékkel meg lehet fókuszálni a kurrens lehetőségekre és körülményekre.
Nekem úgy tűnik, mintha az AMD-nek első 1-2 lépésben lehet, hogy könnyebbséget jelentett, hogy nem építenek teljes sorozatot, ugyanakkor mégis úgy tűnik, hogy hosszútávon hátrány, hogy sokkal hosszabb ideig kell egy terméket aktívan támogatni. Például az nvidiának gyakorlatilag elég csak a pascalra fókuszálni, a maxwell már csak futott még kategória. Ehhez képest az AMD-nek futó generáció a polaris és vega is. Idén az nvidia félreteszi a pascalt és nexgen arch-ra fókuszál. Az AMD kihozza a vega20-at, ami legalább vega, kis szerencsével nem csak mobilon hozza ki a vega mobile-t, de hanem nyugdíjazza a polarist. Rosszabb esetben a polaris tovább él velünk. Bár biztosan örülnénk 2018 végén a Navinak, ahogy Pepe várja, de valójában akkor a mainstream polaris, a vega apu, mobil vega és performance vega és HPC vega (vega20) mellé bejönne egy harmadik architektúra, miközben legjobb esetben is csak a vega10 elnevezésű lapkát küldené nyugdíjba.
Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #35118 üzenetére
Ennek semmi köze a driverhez. A compute culling a motorokban szimpla compute shader.
A DSBR az egy driveres dolog. Majdnem mindenre engedélyezve van valamelyik módja.
Ugye primitive shader nem is lesz abban a formában, ahogy elképzelték. Ugyanazt meg tudja oldani a compute shader. A primitive shader innentől kezdve egészen speciális rendszer, elvileg lesz kiterjesztés, de olyan dolgokra fogják csak használni, amit például compute shaderrel képtelenség megoldani. A GPU-driven pipeline pont nem ilyen. Persze a compute megvalósítás nem olyan elegáns, mint a primitive shader, de végeredményben működik, és alig lassabb. Nagy előnye pedig az, hogy szabványos. Ráadásul a sebességbeli hátránya bőven kezelhető aszinkron compute-tal, tehát az ellenérv maximum annyi, hogy tényleg nem elegáns a kód, de eddig mindenki leszarta, hiszen ellátja a feladatát.
Nem játékok támogatják ezt, hanem motorok. Egy korábbi hsz-ben felsoroltam ezeket.
Mi a hosszú? Nem csak az számít, hogy legyen a piacon új hardver, hanem legyen is eladva a felhasználóknál. Azért mondjuk a DXR-nél nem véletlen, hogy az NV csak a Volta architektúráról beszélt, és amikor szóba jött a Pascal, akkor el is hessegették a kérdést. Ezzel szemben az AMD még drivert is fog kínálni a GCN-re, vagyis nem a fallback layerre építenek. De ha az aktuálisan kapható hardvereket nézzük, akkor is látni lehet már, hogy a nemrég kiadott fallback layer alapján egy Vega 10 simán veri a GP102-t DXR-ben, a GTX 1080-hoz képest két és félszer gyorsabb. És ez még csak a pure compute layer.
Ha azt hiszed, hogy a meghajtók írásánál ezek az architektúrák jelentik a nehézséget, akkor eléggé nagyot tévedsz. A legtöbb meghajtó eleve layered, tehát az implementáció oldalán megpróbálják annyira egységesíteni a dizájnt, amennyire csak lehet. Aztán a hardver felé majd egy low-level rétegben kezelik az eltérést. Akár száz architektúrát is tudnak így problémamentesen támogatni, mert a különbségek csak egy rétegen belül nyilvánulnak meg. Azt egyszer megírod és kész. A problémát a hardverek tesztelése jelenti, de az API-kra vonatkozó implementáció szempontjából az architektúraspecifikus rész a kód nagyon kis részét teszi ki. Ez a hagyományos API-knál jelentett problémát, de az explicit API-k esetén eléggé általános kódokat írnak. Sőt, az AMD nem is ír specifikus API implementációkat, hanem egy platformabsztrakciós rétegre húznak fel mindent. Egy külön réteg kezeli csak az explicit API-k különbségeit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Jack@l
veterán
Még mielőtt nagy temetkezésbe kezdenénk, várjuk már meg hogy mennyit esik az a "fallback" mód pascalnál. Mert a raytracing egy szimpla kupac gpu compute, semmi hókuszpókusz asyncron-al és barátaival...
GCN meg tök jó lesz hogy kap drivert, csak minek ha diavetítés. Az 1070-em már köhög 1280-as felbontás felett. (ugyanúgy fog a vega és alatta minden)A 2.5szer gyorsabbra meg jó lenne valami kézzelfogható mérés, nem amd-s dia amin ott van hogy egyes részfeladatokban, akár lehet az is.
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Abu85
HÁZIGAZDA
válasz Jack@l #35120 üzenetére
A ray-tracing maga egy compute probléma. Minden GPU-n compute shader lesz a számítás. Az esetleges meghajtók ebbe nem fognak beleavatkozni, maximum a denoisingra adnak valami alternatív, nem compute shaderen futó megoldást. A fallback mód csupán azokra a hardverekre van, amelyek egyáltalán nem kapnak meghajtót. Pascal és korábbi GeForce-ok, Intel IGP-k, állítólag a GCN1 és GCN2.
Aszinkron compute mindenképpen használva lesz, mert maga a sugárkövetés egy rendkívül jól beolvasztható probléma minden olyan raszterizációs számítás mellé, ahol a multiprocesszorok amúgy is jórészt pihennek. Itt mindig is az volt a gondunk, hogy nincs elég számításigényes compute feladat ide, de a sugárkövetés tökéletes. Maga a fallback mód is támogatni fogja az aszinkron feldolgozást, persze a DirectCompute implementációnak továbbra is joga lesz visszautasítani a parancsokat, és akkor az OS beírja ezeket a saját grafikai parancslistájába.
Jelenleg egyik gyártó sem ad még eredményt a DXR-ről, mivel a Microsoft még tervezi a kiterjesztést. Nemrég találtak benne pár komolyabb hiányosságot, amit őszre bele akarnak kalapálni. De mivel a fallback layer publikusan elérhető, így természetesen tesztelhető is az aktuális verzió.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Ok értem. Tehát lehetne akár 6 v 8 SE is. Csak eddig az AMD
1)"sajnálta" a tranzisztort
2) ugyanannyi CU mellett nem emelget volna lényegesen a teljesítménytJó, Köszönöm a választ.
Van azért még kérdésem: Ha a korábbi buszrendszer esetén az ideális a 9CU/SE, ahogy egyébként kB a hawaiinál is láttuk, meg a polarisnál, és a maximum a 12, akkor a fiji higy vitte a 16CU/SE konfigurációt?
A Fiji a nyers számok.tekintetében csak a textúrázókat és a CU-Kat.növelte. és nem is skálázódott a Hawaii konfigjáról a fijire,.valami szűk keresztmetszet volt.
Hihető lenne, hogy ez a szűk keresztmetszet nem valami geometria, vagy pixel motor volt, ami a Hawaii es a fiji között alig javult, hanem a belső busz skálázódása a 16 CU-ra, amit a Vega 10 javított az új busszal, ha nem az látszott volna sok esetben, hogy a Vega csupán annyival gyorsabb a fijinél, amennyivel magasabb frekvenciát el tud érni.Ez utóbbi azt sugallja, hogy vagy a Vega is olyan limites a belső összetevőiben, mint a fiji, vagy mégsem a CUk skálázódását 12 helyett 28-ra kitoló belső busz volt (az egyetlen) szűk keresztmetszet.
Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #35122 üzenetére
Minden GCN verzióban változott eddig a buszrendszer. Eltérő sebességű lett, sőt lapkánként sem ugyanaz. Igen a Polaris esetében visszább lett fogva, mert eleve nem volt betervezve nagyméretű lapka belőle. Miért is terveznél hozzá nagy, tranzisztorzabáló buszrendszert? Azért egy méretesebb konfiguráció pusztán a bekötés oldaláról legalább 500-700 millió tranzisztorral dobja meg az igényeket. Ha nem használod ki, akkor értelmetlen ennyi extrát beépíteni egy lapkába.
Feleslegesen találgattok. Ott van az AMD-nek a Radeon GPU profiler eszköze. Fiji, Polaris és Vega mellett minden explicit API-t használó játéknál megnézhető, hogy miképpen van kihasználva a GPU. Abszolút megmutatja a szűk keresztmetszeteket.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
Tehát a Vega érdeme az aktuális (+1 év) motorok jó hatékonyságú futtatása helyett az, hogy 2017 közepek felkészült egy olyan probléma kezelésére (raytracing), aminek az API szintű impementációja 2018 őszén jelenik meg?
A Vega 10 hónapja van a piacon és egy kézen meg lehet számolni hány compute cullingot alkalmazó motor van.
Ezek azért fontos tények, mert amikor megjelenik majd a következő nvidia kártya, a Vega ilyen jellegű képességei senkit nem fognak már érdekelni. Ahogy a fiji esetén is hiába várta bárki is, hogy majd kifizetődik a brutális compute teljesítmény. (Persze lehet, hogy az AMD így legalább el tudta adni Pro termékként, ahogy a vegát is) a fiji valójávan eléggé földbe állt.
Jövőre ilyenkor már senkit nem fog érdekelni, hogy az addigra megszülető 3 raytracing pilot game esetén a már meghaladott pascalt beéri a Vega10, mert a raytracinget kétésfélszer gyorsabban számolja.
Akkor mindenkit az fog érdekelni, hogy a nexgen nvidia hogy kalapálja el a Vega20 gpukat. Továbbra sem értem, hogy miért kellene a vegának 2 évvel későbbi terhelésre is felkészített lapkának lennie. Ki fog akkor még olyat venni? (Kivéve persze ha valaki kalkulál azzal, hogy bizonyos szegmensekben új termék.hiányában átnevezni kényszerül )Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
Én azért "találgatok", mert te mindent le csapsz azzal hogy minden így jó minden a lehető legjobb ennél jobb már nem is lehetne minden tökéletes minden hatékony Minden szuper. Ehhez képest Viszont bibós cikkéből azt lehet kiolvasni hogy az Amd generációról generációra illetve évről évre rosszabb és rosszabb hatékonyságú (perf/TR, perf/w) lapkákat hoz ki legalábbis a konkurenciához viszonyítva.
Es emiatt folyamatosan piacot veszít.Legalább ne mondd, hogy minden rendben van, minden tökéletes.
Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz Petykemano #35124 üzenetére
Ezek nem érdemek. Amikor egy GPU-t terveznek, akkor a gyártók az élettartamot figyelembe véve felvázolják maguknak a potenciális problémákat. Nem olyan dolgokat, hogy ray-tracing, mert az egy eljárás, és önmagában nem probléma.
Mik a következő időszak legnagyobb problémái?
- quadraszter: Nem tudjuk növelni a geometria részletességét, mert a GPU-k négyes pixelblokkokon dolgoznak. Egy újszerű raszterizáció ezt megoldaná, de a kompatibilitás miatt az API-ban kellene megoldani az egészet, vagyis amíg erre nem jön egy új pipeline, addig úgy lehet elérni a geometria részletesség növelését, ha a korábbinál hatékonyabbá teszik a kivágást. A Vega megoldása erre a primitív shader, de igazából kb. hasonlóan jó a compute culling. Ehhez kapcsolódó problémakör a túl sok ismételt vertex shader munka azokon a háromszögeken, amelyek normálvektorai a nézőpont irányvektorával 90 foknál nagyobb szöget zárnak be. Ezt csak a primitív shader tudja kezelni, erre nincs szabványos compute megoldás, de még egy ideig azért lehet élni nélküle, viszont 2018 végén már azért limitáló lehet.
- többletrajzolás: Ez is kb. eléggé para, mivel egy jó minőségű szimulációban ezrével kell leképezni a részecskéket, és bizony egy részecske sokszor nem csak pixelnyi méretű, és ugye ezek a kis mocskok még átfedik is egymást. Erre teljesen hardveres megoldás a Vegában a DSBR draw stream pipeline-ja. A régi hardvereknél kezelési lehetőség lehet a tiled compute kivágás mondjuk Harada2.5-tel, de az optimális a hardveres kezelés.
- memóriaallokáció: Elég sokáig téma volt, hogy bizony a VRAM kezelése borzalmasan nehézkes az új API-kkal, illetve a memóriák drágulnak, tehát nagy butaság lenne a jövőben is brute-force megoldásra építeni. Erre a Vega alternatívája a HBCC. Csak azt az adatot tartsd a GPU mellett, amivel tényleg dolgozik.
- LDS pressure: A teljesen statikus allokációk miatt az egyre komplexebb übershaderek egyszerűen kifutnak az LDS-ből. 32 kB nem elég, így egyre kevesebb wavefront futtatható a CU-n. Erre a Vega megoldása az LDS dinamikus particionálása.
Kb. ezek futottak át a mérnökök agyán, tehát nem létező effekteket vagy eljárásokat elemeznek, hanem csupasz problémákat ezek alatt. A DXR-t speciel eléggé scamnek tartják a fejlesztők a jelenlegi formájában. Erre igazából még az AMD se lő, bár nyilván 2-3 év múlva értelmes dolog lehet belőle, de ma még az is probléma, hogy pár kedvelt adattípust a DXR nem is kezel. Azért itt nincs teljesen hurráoptimizmus, ahogy a hype mutatja, mert azt nehéz megoldani, hogy összerakj 16 ms alatt egy 4K-s képet DXR nélkül. DXR mellett ugyanerre jó ha van 8 ms-od, tehát ha egy játékba ray-tracinget tervezel, akkor bizony a raszterizálást el kell kezdeni butítani, és akkor csak annyit érsz el, hogy harapdálod a kezed, a kérdés, hogy melyiket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#45185024
törölt tag
Friss reggeli zene, nem pudingoknak való vidék
New Raven Ridge Drivers (04/11/2018) ! Ryzen 5 2400G, Ryzen 3 2200G, Vega 3, Vega 6, Vega 8 ect
a Raven Ridge Drivers is beolvad az AMD vezető Driver ágába
HP Envy , azAcer Swift, az Acer Apire is megkapja az új driverét.
Nekem még meg kell szokni ezt a Vega 3, Vega 6 kifejezést.
RX Vega 3 az az laptopokba integrált GPU belépő szintű Ryzen 3-as APUkba akinek esetleg nem világos.[ Szerkesztve ]
-
veterán
válasz #45185024 #35127 üzenetére
A videót nem tudom most megnézni, kiderül belőle, mikor kapja meg a main drivert a Raven?
Mert AMD oldalán még mindig csak ez jön be desktop Raven driverre keresve: [link]Mondjuk arra is kíváncsi lennék, eddig miért volt rájuk más driver, mint minden egyébre.
[ Szerkesztve ]
solfilo
-
Petykemano
veterán
Ez nagyon patent.
Találgatunk, aztán majd úgyis kiderül..
-
#45185024
törölt tag
válasz solfilo #35128 üzenetére
Rossz helyen keresed:
Microsoft Updae Catalog ide írd be amit keresel pl "vega 3" satöbbi"eddig miért volt rájuk más driver, mint minden egyébre. "
A laptopok egyrészt egy másik világ ahol szokás erősen behatárolni milyen drivert engedek meg milyet már nem. Másrészt vannak itt tőlem szakavatottabb emberek aki majd elmondják neked a driveríró műhelyek belső dilemmáit, de azért gondold végig más a cégnév, szerződések kötik, és ama apró pikáns helyzetre is gondoljunk amikor Intel terméket AMD oldalon frissítenél ))Más: Kis szines ha már itt vagyok.
Hogy ne sérüljenek bizonyos emberek mentális állapotai ezért offba teszem
Random véletlenül leszólította egy riported Lisa Sue-t a GP-n.
Megkérdezte tőle ért e angolul Majd amikor azt mondta Lisa hogy Az AMDtől vagyok tudja, támogatjuk a Ferrarit, akkor a riporter zavartan adta vissza az élő közvetítés képernyőjét a stúduónak...
Szenzációs )[ Szerkesztve ]
-
veterán
válasz #45185024 #35130 üzenetére
"de azért gondold végig más a cégnév, szerződések kötik, és ama apró pikáns helyzetre is gondoljunk amikor Intel terméket AMD oldalon frissítenél "
Te miről beszélsz? Raven Ridge = Ryzen CPU + Vega IGP, két hónapja megjelentek, desktopon Ryzen 5 2400G (Vega 11) és Ryzen 3 2200G (Vega 8) néven. Ez minden, csak nem inteles cucc, amihez keresi az egész topik az Adrenalin drivert. AMD oldalán is illene, hogy fent legyen a legújabb driver.
Bár az MS odaláról sem derül ki, ez milyen driver, csak hogy a creators update-hez készült.Másképp fogalmazva a Vegára és a GCN2-es Kaverire is van Adrenalin, de a Vega IGP-re meg nincs AMD oldala szerint.
Az a videó tényleg nagyon adja!
[ Szerkesztve ]
solfilo
-
Jack@l
veterán
Na akkor fussunk neki újra:, semmiféle compute shader nem kell(elvileg) hozzá, hacsak nem shading/raszterizáció mellé részfeladatnak akarják bepakolni. Sima opencl vagy cuda, a denoisinghoz is...
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
Abu85
HÁZIGAZDA
válasz Jack@l #35134 üzenetére
A Microsoft DXR kiegészítése a DirectCompute API-t használja. Ezen fut. Nem tud OpenCL-en vagy CUDA-n futni, mert ezekre nem tudod lefordítani a DXR shader nyelvét, ami a HLSL 2017, de még a támogatott IR-ből, ami egyébként a DXIL, sem tudsz fordítani más platformra. Esetleg Vulkan API-n oldható meg a futtatás, ugyanakkor ehhez mindenképpen szükséges lenne direkt támogatás, amit a Microsoft nem igazán biztosít. Azzal önmagában nem mész sokra, hogy a DirectXShaderCompiler tud neked a HLSL shaderedből SPIR-V 1.3-at fordítani.
(#35135) gbors: Én inkább játékot kérdeztem, mert gondolom, ha ezt megnézted, akkor legalább kértél egy profilozást a hardverre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
"Nekem higgy, ne a szemednek"
Hidd el, minden optimális, nincs sehol semmilyen limit. Minden tökéletesen, de legalábbis megfelelően skálázódik, ami korlátozás ugyan volt, azt már átdolgozták és ugyan semmi látszatja (sic!), de hidd el, hogy volt, de átvágták.
Válaszok felvetődő kérdésekre nincsenek. Illetve a válasz az, hogy a probléma, a jelenség, a kérdés nem létezik, csak a következő két év várható előremutató előrelátó fejlesztési potenciáljai, amik a ma még csak kísérlet formájában felmerülő problémákra adott jövőbeli válaszok gondolatkezdeményei.
Találgatunk, aztán majd úgyis kiderül..
-
Malibutomi
nagyúr
Sracok egyeb okok miatt alig jutok mostanaban a forumra, ugyhogy leadom a topicot, mert nem tudok figyelni ra elegge (mint azt valoszinu eszrevettetek).
Ha valaki vallalna a topicgazdasagot, az jelezzeBodrik fele.
-
Jack@l
veterán
https://www.techpowerup.com/243441/amd-responds-to-nvidias-gpp-aib-partners-to-announce-new-radeon-exclusive-brands
Ez kell egy kissebségi cégnek, lábonlövésA hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
-
nagyúr
válasz Malibutomi #35139 üzenetére
Koszi az eddigieket
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
nagyúr
válasz Malibutomi #35139 üzenetére
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Plasticbomb
addikt
válasz Szeszkazán #35145 üzenetére
S ne feledd, ne hagyj egy vogont sem verset olvasni...
[ Szerkesztve ]
ArchLinux, Star Citizen, Subnautica+BZ, ASTRONEER, Grounded, DRAG, VOLCANOIDS, Space Engineers, Elite:Dangerous, Beyond Blue (TK-Glitch Proton)
-
#45185024
törölt tag
válasz Plasticbomb #35146 üzenetére
Mi ez a 42 trollkodás itt kérem szépen ? Én nem vagyok hajlandó egy négy részes trilógiáról beszélgetni itt
-
Jack@l
veterán
[ Szerkesztve ]
A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- CASIO órák kedvelők topicja!
- Kertészet, mezőgazdaság topik
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- iPhone topik
- Sorozatok
- Diablo 3
- Villanyszerelés
- Kerékpárosok, bringások ide!
- Újabb Samsungok telepíthetik a Galaxy AI-t
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- További aktív témák...
- Hibátlan - GIGABYTE GTX 1660Ti Windforce OC 6G 6GB GDDR6 VGA videókártya dobozos
- Sapphire NITRO+ RX 580 8G SE
- ELADÓ 32 DB Nvidia RTX 3060 Ti és 8 DB Zotac Gaming Geforce RTX 3080 Trinity / KOMPLETT BÁNYAGÉP
- Gainward Phoenix RTX3080
- ASUS ProArt GeForce RTX 4080 SUPER 16GB GDDR6X OC (ASUS-VC-PRO-RT4080S-O16G) Bontatlan új 3 év gar!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest