- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Az NVIDIA ipari AI-felhőt épít a németeknek, együtt az OpenAI és a Google
- Két új Ryzen közül választhatnak a kézikonzolok
-
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
-
-
Abu85
HÁZIGAZDA
válasz
Petykemano #40695 üzenetére
A compute culling már úgy 8 éve bőven velünk van. A háromszögek korábbinál hatékonyabb kivágása nem újdonság, nagyjából 10 éves projektek, amelyeket számos aktuális motor már évek óta támogat (szerintem a mi tesztcsomagunkban is alig van olyan játék, ami nem ilyen). Az más kérdés, hogy vannak akik még nem támogatják, mert nem tekintik kritikusnak azt a geometriai részletességet, amit ezzel el lehet érni.
(#40698) gbors: Mint írtam egyelőre csak a World War Z használ szabványos subgroup shadereket. De azt is leírtam, hogy a terminológia alapvető működése miatt egy játék nem elég a következtetésekhez, talán még húsz sem lesz az. Tényleg nagymértékben befolyásolja a teljesítményt a fordító, valamint az, hogy az adott GPU az adatmegosztásra milyen hardverállapotban kényszerül. A mai multiprocesszorokat arra tervezték, hogy a helyi munkacsoportok között a helyi adatmegosztással megosszák az adatokat a compute shader futtatásához beállított hardverállapottal. A subgroup azt követeli meg, hogy a helyi munkacsoportoknál kisebbeknél is legyen adatmegosztás, akármilyen hardverállapot mellett. A hardver nyilván képes rá, elvégre a compute shader támogatása ezt már lehetővé teszi, csak a hardverállapotok nagymértékben módosítják ám a multiprocesszor működését, amivel erősen javul vagy éppen csökken az adatmegosztás hatékonysága.
És akkor ott a szoftveres kérdés, mert a GPU-t azért lehet ám vezérelni driverből, tehát az se biztos, hogy ahogy ma működik egy GPU, az úgy marad a jövőben. Valszeg az AMD úgy marad, mert ők az AGS-en azt csinálják, hogy stateless lesz minden adatmegosztás, és gondolom ezt használják szabványosan is, de például az NV-nél már sok a kérdés, mert náluk nincs stateless mód. Emiatt még sokat kísérletezhetnek azon, hogy mi a legjobb. Valószínűleg nem az, ami most van, tehát az aktuális driverekkel a hardver még nincs a teljesítménye határán. -
Devid_81
félisten
Szal akkor 6xx nevvel dobjak majd piacra a Navit is 99%
Hacsak nem akarnak kavart mint nVidia a RTX 2xxx majd GTX 16xx-elSzerk: de belegondolva meg mindig Polarisnal jarunk...amig vilag a vilag kozottunk lesz ez a cucc komolyan
Legalabb attaknyolnak 7nm-re es GDDR5X-et neki vagy valami... -
Petykemano
veterán
Én értem, hogy "mostantól" majd a compute culling old meg mindent. De ez a mostantól azt jelenti, hogy 2019-tölti kezdenek majd el szivárogni és ez egy legalább 1-2 éves folyamat. Ez azt jelenti, hogy mondjuk legjobb esetben is 2020-ra mondhatjuk, hogy ez a technológia elterjedt.
És addig??
Mármint hogy nem mostantól, hanem amióta ez a probléma létezik. Az AMD legkésőbb a fiji debütálásakor 2015-ben szembesült azzal, hogy a geometria számítási képesség kevéske. Valószínűleg előbb. 2016-ban jött a polaris, amiből ha jött volna nagy változat, nem tudjuk, hogy 6SE lett-e volna, de valószínűleg 4, és meg se próbálták. Aztán 2017 Vega, amikor pont ugyanúgy jött szembe a gyorsvonat az alagútban, mint a fijinél. Végül a Vega20 esetén úgyszintén meg se próbálták.Tehát úgy tűnik, lassan 5 éve várnak arra, hogy "áh, minek kínlódjunk egy problémával, amikor már mindjárt megoldódik magátol". Okos dolog.
-
Z10N
veterán
AMD Radeon RX 640 and Radeon 630
Polaris 23 XT Radeon (RX) 550X ---> Radeon RX 640
Polaris 23 MXL Radeon 540X ---> Radeon 630 -
Abu85
HÁZIGAZDA
válasz
Raymond #40690 üzenetére
Nem tettem hozzá. Megírtam, hogy miről van szó. Amelyik alkalmazás így működik, ott a legkevésbé a hardver nyers háromszög feldolgozási képessége számít, mert sokkal-sokkal több időt tölt majd azzal a GPU, hogy a nem látható háromszögeket nagy hatékonysággal kivágja a lefutó compute shaderekkel. Jó példa a Deus Ex Mankind Divided. Hiába rendelkezik ez a játék az egyik legtöbb háromszöggel egy jelenetben, a geometriai motorokra rótt terhelés szempontjából mégis kíméletes, mert nagyon sok háromszöget kivágnak a compute culling shaderek a leképezés előtt (bőven a leképezés előtt, vagyis bizonyos shader lépcsők is megmenekülnek a többletterheléstől), így igen kevés felesleges munka lesz a raszterizálás során. Összességében tehát többet ér ennél a programnál a nyers TFLOPS, mert a háromszögekkel való munka nagyobb részét a compute shaderek teszik ki. A raszterizálás előtti nyers háromszögterhelés átlag alatti, annak ellenére is, hogy a végleges geometriai részletesség átlag feletti.
-
Abu85
HÁZIGAZDA
válasz
Raggie #40686 üzenetére
Az idei explicit API-s felhozatalból szinte mindegyik. De már az előző év végére is ez volt a jellemző. Azért csinálják ezt a fejlesztők, mert az AGS fordítója nagyrészt érti a PSSL shadereket, tehát ezeket nem kell újraírni, hanem van egy konverter, amibe beküldöd, és kiadod HLSL Ext. shaderként, amivel máris tud bánni az AGS valamelyik verziója.
A különbség most annyi lett, hogy a jövőben ezt valószínűleg nem AGS-sel képzeli el a piac, mert az alapvetően csak az AMD-nek előny, de maga a wave terminológia általánosan hasznos. Erre van a shader modell 6 és a Vulkan API-n belül a subgroup shaderek. A shader modell 6-ot még wave terminológiára nem használják, de Vulkan API-ra már ott a World War Z, ami subgroup shadereket is használ. Emiatt kavarodott össze az utóbbiban az erősorrend, mert a subgroup/wave terminológia (ugyanaz mindkettő, csak máshogy hívja a Microsoft és a Khronos) eltérő módon működteti a hardvereket a régi, soros feldolgozáshoz képest. Egészen konkrétan megadja annak a lehetőségét, hogy az egymástól független párhuzamos feladatok bármilyen módban párhuzamosan fussanak a multiprocesszoron belül, és meg tudják osztani egymással az adatokat, legyen szó bármilyen pici feladatról. A korábbi terminológia erre csak compute shaderben adott lehetőséget, és ott is csak a helyi adatmegosztást lehetett használni az adatok megosztására, de csakis a helyi munkacsoportok között, vagyis maga az adatmegosztás durva szemcsézettségű volt.
Látszatra ezek nem tűnnek nagy különbségnek, de valójában azok, mert a hardvernek vannak különböző állapotai, amelyeken belül a multiprocesszor némileg eltérően működik, és nehéz meghatározni, hogy egy ilyen váltásra a korábbi terminológiához tervezett hardverek hogyan reagálnak. Maga az architektúra fejlődik az AMD és az NV dizájnjaiban, de az ISA tekintetében az alap az AMD-nél még az öreg GCN, míg az NV-nél a szintén öreg Fermi, tehát amikor ezeket tervezték 2010-nél korábban, akkor nem nagyon volt szempont, hogy 2019-re mennyire változik meg a shader modell. Ezt igazán lekövetni új ISA-val lehet, de mivel a hardveres szálkezelés tekintetében még mindig nincs ott a GCN és a Fermi, hogy a limitek erősen látszódjanak, így egy darabig nem valószínű, hogy az AMD és az NV vált. 2020 után tuti, de az még később van.
DirectX 12-re támogatást lehet írni egy eredetileg DirectX 9-re tervezett játékra is. Nem éri meg, de ettől lehetséges. A régebbi leképezők alapvetően tudnak működni nagyon sok API-n. Vannak bizonyos leképezők, ahol már nagy hasznot hoz mondjuk a DirectX 11, vagy a 12. Előbbire tipikus példa szokott lenni a compute cullingos megoldások, amikor valami problémát compute shadereken keresztüli kivágással kezelsz, míg utóbbi leginkább akkor hasznos, ha maga az árnyalás a jelenet szintjén történik, és nem a fragmentek szintjén, ez ugyanis jelentősen növeli a rajzolási parancsok számát, hiszen már nem lesz erősen limitált a shadow casting fényforrások száma sem, és rengeteg effekt szimplán a jelenet szintjén megoldható, egyszerűen csak másolod az árnyalt objektumokat. Annyiszor tudod ezeket megjeleníteni, amennyi rajzolási parancsot költesz rá, a hardver csak egyszer számolja ki.(#40687) Raymond: compute-based triangle filtering
(#40688) gbors: A wave/subgroup shadereknél eléggé össze van keverve az erősorrend. Sok múlik a fordítón, illetve azon, hogy az adott program milyen intrinsics függvényeket használ, a 2010 előtt tervezett ISA-k mennyire rugalmasak ebből a szempontból, mert ezeken olyan sokat javítani nem lehet, maximum teljes újratervezéssel. Ezért baj itt tippelgetni, mert a World War Z Vulkan módja ugyan egyértelműen első fecske, de egy rakás olyan tényező van, amit még húsz fecske után sem fogunk igazán ismerni. Tehát a World War Z Vulkan módjából annyi vonható le következtetésként, hogy azokkal a subgroup shaderekkel, amiket a program használ, azokkal a hardverállapotokkal, amelyekben ezeket futtatják a GPU-k, azokkal a fordítókkal, amelyeket a gyártók jelenleg implementálnak, ez a teljesítmény. És a sok tényező miatt nem lehet azt mondani, hogy ez lesz a következő címnél is. Emiatt nehéz erre építeni. Simán lehet, hogy megfordul az egész, mert más kódokat kapnak a hardverek, más hardverállapotokban futtatják azokat, és máshogy fog működni a fordító. Régen ez azért volt sokkal egyszerűbb, mert ha adatmegosztás kellett a feladatok között, akkor arra egy mód volt, és erre a módra ki volt gyúrva a hardver (na jó a hardver nem mindig) és a fordító. Ma nagyon-nagyon sok mód lett erre, és ki tudja, hogy melyik állapotra van kigyúrva az adott hardver, és melyikre fordít hatékony kódot a fordító.
-
-
Raymond
titán
"Nm a háromszögről van szó, hanem arról, hogy a GPU felé mennyi adat megy. Egy GPU-driven pipeline motornál már a leképezés előtt ki lesz vágva egy rakás háromszög, amiért compute shaderek felelnek. Ettől még mérheted a GPU-k közötti különbséget a háromszögek terhelése szempontjából, csak a nagy terhelést a culling fogja jelenteni, ami viszont TFLOPS-okat zabál."
Ennek az egesz bekezdesnek se fule se farka.
-
Raggie
őstag
Abu, pár kérdésem volna, nem kötekedésből, hanem mert tényleg kíváncsi vagyok ezekre hogy jobban megértsem a helyzetet:
1) melyik rakás új játék használ wave intrinsics shadereket ?
2) Azért az eddigi tapasztalatok alapján igenis számítani fog mindíg is a nyers ereje a kártyáknak. Egy átmeneti rövid időszakon kívül, vagy átmeneti egy-két játékon kívül mindíg kiegyenlítődik a helyzet és kábéra a nyers erősorrend szerint alakulnak a kártyák teljesítményei. Mi az ami miatt most szerinted ez nem így lesz?
3)Hogyan tud Dx12-es lenni az A4 engine úgy, hogy nem lett jelentősen átírva? És még gyorsan is fut... -
Abu85
HÁZIGAZDA
Eléggé. Az A4 Engine nem lett jelentősen átírva, ezért is fut eléggé gyorsan.
Nm a háromszögről van szó, hanem arról, hogy a GPU felé mennyi adat megy. Egy GPU-driven pipeline motornál már a leképezés előtt ki lesz vágva egy rakás háromszög, amiért compute shaderek felelnek. Ettől még mérheted a GPU-k közötti különbséget a háromszögek terhelése szempontjából, csak a nagy terhelést a culling fogja jelenteni, ami viszont TFLOPS-okat zabál.
(#40683) Petykemano: Eleve az a probléma ezzel, hogy egy rakás új játék wave intrinsics shadereket használ, és ezek még a GCN-en belül sem szabványosak, tehát az lesz a leggyorsabb architektúra, amely a legtöbb intrinsics függvényt kapja a culling kódokon belül. Mindegy, hogy a hardver mit tud elméletben, ha nem ugyanaz a kód fut rajtuk. Szóval jelentősége lesz ezeknek, csak nem a hardvertől fog függni, hanem attól, hogy az egyes GPU-kon milyen nem szabványos optimalizálásokat engedélyeztek.
A szabványosság is para ebből a szempontból, lásd a World War Z-t, ami először csinálja azt, hogy szabványosan elérhető intrinsics függvényeket használ minden hardverre a cullinghoz is. Aztán ez jól megkavarta ám az állóvizet, és nem azért ver a Vega mindent, mert annyira gyors maga a hardver. Szóval a hardver az intrinsics függvények terjedésével, főleg a szabványosokkal nem pont egy egzakt kiindulási pont, mert nagyon sok függ magától a kódtól. Az a hardver lesz a legjobb, amelyiken maga a shader, illetve ennek a fordítása a leghatékonyabban fut, ettől a hardvernek nem kell nyersen a leggyorsabbnak lennie.
-
HSM
félisten
A zöldek szvsz amin óriásit nyernek, nem csak az órajel. Hanem a sávszélességet sokkal kímélőbben használó ROP-ok.
Illetve, a szoftveres ütemező miatt sokat tudtak trükközni a DX11 alatt driverből a CPU kárára, ami miatt kb. duplaannyi rajzolási paranccsal is elbírtak.(#40679) Abu85: Nekem az tetszett, mikor azt írta, hogy a Tahiti igazából nem is DX12.
-
Petykemano
veterán
Abu, ha szerinted ez hülyeség, akkor megtennéd, hogy írsz egy cikket ertől és végrehajtod ugyanezeket a teszteket modern szoftvereken megmutatva ezzel azt, hogy ennek miképpen nem lesz jelentősége a következő 1-2 évben, nem pedig majd 3-4 év múlva, amikor már nem is fogunk emlékezni arra, milyen architektúra jelent meg idén.
-
Petykemano
veterán
"ha megfelelő fogyasztás mellett (vagy úgy egyáltalán...) képesek lennének tartani a konkurencia órajeleit... De ezen a ponton vérzik el az összes, hogy vagy egyáltalán nem is tud olyan magas órajelekre felmászni, vagy ha véletlen fel tud akkor 300+ Wattot kér hozzá."
Nekem meggyőződésem, hogy az nvidia kártyák energiahatékonyságánák és a magasabb frekvenciának is az oka a lényegesen jobb culling. Vagyis az nvidia valójában ugyanahhoz a képhez, ugyanahhoz a fpshez az nvidia kevesebbet dolgoztatja a magokat.
A nem tömbösíthető műveleteken talán majd segít a SuperSIMD. Valamikor
-
Petykemano
veterán
Nem véletlen a fejlesztési irány, de le vannak.maradva. a DCC az egyik ilyen, ahol azt mondják, hogy lényeges, mert ez kényszeríti a kártyákat másfélszer nagyobb sávszél kiépítésére, ami nagyobb fogyasztással,.felsőbb szegmensben meg a drága hbmmel.jár.
A másik meg ez a geometria, meg a culling. A primitive discard accelerator a polarisban hozott.valamit. a vegában az nggnek (meg a primitive shadernek) kellett volna hoznia - elvileg azt, amit a doomban láttunk.
Olvastam olyan véleményt, mely szerint a dsbr (ami most driverből ilyen per game van aktiválva (+finomhangolva?)) Működéséhez jelentős geometriai kapacitás szükséges - hogy megállapítsa a hardver,.hogy mekkora mozaik részekre kell felbontani. De mivel pont ebben nem jeleskedik a gcn (a nagyobb lapkák), ezért a dsbr haszna csekély, kevéssé tud hasznosulni.
Az órajel fontos, mert az egész lapka működését gyorsítja. Tehát érthető ez az irány is. Ugyanakkor azt még mindig nehezemre esik elhinni, hogy egy Vega64 ne teljesítene jobban 4x16 helyett 6×10 felállásban 50-100MHz-cel kisebb órajelen.
Mármint persze gamingben, és ezzel nyilván meg is válaszoltam a kérdést.A cikk azzal zárja, hogy a tahiti-Tonga-polaris átmenetben hiába vált látványosan erősebbé a geometria kapacitás, alig valamekkora előrelépest jelent csupán a végleges gaming teljesítményben. Remekül megállapítottuk, hogy a 2×8CU-t nem annyira a geometriai kapacitás fogja vissza. De hát ezt kár láttuk a hawaiiban is, ami viszont előrelépes volt a tahitihez képest és a 10-11cu vs 8-9CU különbségét hozta a polaris órajelből. És azt is láttuk, hogy a fiji.mennyire nem volt előrelépés a 4×16 felépítéssel.a hawaiihoz képest.
Kíváncsi vagyok, hogy vajon a Navi, ami gémingre készül, visszatér-e az ideálisnak tűnő 10-12CU/SE arányhoz és születik-e majd 6SE-s változat, vagy bízunk az okos megoldásokban? (Ngg)
Elő kéne venni újra azt a leaket a 20CU-s gfx1010-ről, ami radeon Vii-nek mutatta magát...
-
Abu85
HÁZIGAZDA
válasz
Petykemano #40675 üzenetére
Tehát megvizsgálták a hardvereket a régi programokon, miközben a legtöbb mai motor már GPU-driven pipeline. Ügyes.
-
Tyrel
őstag
Eeegen ezt már régóta mondogatom, hogy igazán nem is lennének lassabbak az AMD kártyái a konkurenciánál, ha megfelelő fogyasztás mellett (vagy úgy egyáltalán...) képesek lennének tartani a konkurencia órajeleit... De ezen a ponton vérzik el az összes, hogy vagy egyáltalán nem is tud olyan magas órajelekre felmászni, vagy ha véletlen fel tud akkor 300+ Wattot kér hozzá.
Igazán ha egy program ill. grafikus motor jól van megírva, jól van optimalizálva modern architektúrákra, és jól párhuzamosítható / jól tömbösíthető műveleteket végez, ezeket is kevés 'blocking call'-al, akkor jól fut a Radeonokon is, de ha homokszem került a gépezetbe és nem ütemezhető hatékonyan a feldolgozás, onnantól kezdve kb. csak az órajel számít ill. az segít abban, hogy átrágja magát a GPU a kritikus pontokon... és ezekben az esetekben az nVidia kiütéssel győz. Nem a driver jobb meg nem is feltétlen az architektúra, csak simán benne van +2-400 MHz és azzal nyer.
Nagyjából pont ugyan ez van a CPU piacon is, a Ryzen-ek párhuzamos feldolgozásban jók, de ha kéne a magas single-core teljesítmény, ott az Intel röhögve nyer, mert az ő chipje felmászik 4,7 - 5,0 GHz-ekre ilyen asszimmetrikus terheléseknél, a Ryzen meg ott ragad 4,2-n... Full ugyan azzal a gonddal küzdenek CPU és GPU fronton is már rég. Ha ezt sikerülne megoldaniuk végre, onnantól bőven méltó ellefelek lehetnének gaming fronton is.
-
válasz
Petykemano #40675 üzenetére
Jó cikk
-
HSM
félisten
válasz
Petykemano #40675 üzenetére
Azért nem véletlen mentek rá a Vega-nál többek között az órajel növelésére, főleg a Radeon VII-nál, nincs is bekapcsolva az összes CU, de az órajel közelíti a 2ghz-et, ami azért így már masszív előrelépés a Polarisok többségéhez képest.
-
Petykemano
veterán
GCN geometry teszt
- Tahiti (2SE), Tonga, polaris
- volt-e fejlődés?
- a geometria képesség hogy képeződik le a tényleges teljesítményben?
- Mit tud ehhez képest a radeon vii? -
#82819712
törölt tag
válasz
Devid_81 #40663 üzenetére
Chiplet, chipset, moduláris, WDDM 2.0, stack ez a sok szakszó és a kedves magyar szakma meg nem fordít semmit magyarra mi ?
Azért fontos mert chiplet igen, meg mert sok ember nem hiszi és mégis tovább él a hír talán mert...
Az EPYC az egy annyira korszakalkotó fejlesztése AMDnek hogy sokáig fogja meghatározni a piacot.
A modularitás egy szép eszme csak Amd az egyik legnagyobb visszahúzó erejét a GloFo-t előnnyé tudta kovácsolni ez ebben a sikertörténet. Mindenki érti az IO előnyeit, a külön elhelyezett és cserélhető memóriavezérlőt stb és kikerülnek a GPUból részek, amiről itt már sokat beszélgettek, az hogy ez mikor csorog le és milyen formában arról sokan gondolnak sok félét (warning adored elmélkedés az új frontierről warning)
de ha a Navi GPU is chipletes lenne az nagyon megváltoztatná a piacot és tényleg csak a mikor a kérdés. -
HSM
félisten
válasz
huskydog17 #40664 üzenetére
Nem állította.
Így szólt az eredeti hozzászólás: "Magyarán megszületett a második teljes értékű 16 GB-os játékkártya AMD oldalon."
Ezzel szemben a te állításod, amire írtam, hogy ezt senki nem írta: "Akárhogy nézzük ez nem mezei konzumer játékos VGA."A prosumerben benne van a játékos felhasználás is, tehát a fórumtárs eredeti állítása megállja a helyét. Azt te keverted bele, hogy mezei meg konzumer, nyilván így nem igaz, de ezzel nem a fórumtárs állítását cáfoltad meg.
-
Devid_81
félisten
válasz
Petykemano #40662 üzenetére
Chiplet ize, azt akartam irni en is, de nem jott ossze
-
#82819712
törölt tag
Csak nem kopik ki az a 3600 G az APU köztudatból, most is viszi tovább mindenki a 12 mag mellett is, majd 3 ezer szavazattal jól el is van.
-
HSM
félisten
válasz
huskydog17 #40657 üzenetére
"Ugye tudod, hogy a machine learning és data center között elég szoros kapcsolat van?"
Nem nyert.Attól, hogy datacenterekben is van gépi tanulás, attól még nem lesz egy GPU datacenter, csak mert képes rá.... Ez elég gyenge érvelés volt.
Az AMD honlapján is világosan szerepel a specifikációknál, hogy "Platform: Desktop". Nem datacenter, vagy szerver, mint az Instinct MI25-nél, hanem desktop, mint a Vega56-nál is.
"Akárhogy nézzük ez nem mezei konzumer játékos VGA."
Senki nem is állította ezt. Ez egy tipikus prosumer kártya mezei asztali számítógépekbe. A munkaállomás, asztali gép pipa, de hogy se nem szerver, se nem datacenter, az 100%. -
huskydog17
addikt
Bocs, igen nem csak datacenter, hanem AI is az egyik fókusz a Frontier kártyánál, leírtam ,de ugyanakkor datacenterbe is alkalmas:
"AMD claims the Frontier Edition is the "world's first" GPU geared for AI (Artificial Intelligence), creatives, and science pioneers."
"Nvidia just announced its new Tesla V100 based on the Volta architecture, so it's not surprising that AMD is firing back with details of its new Frontier Edition. Vega marks AMD's re-entrance into the high-performance desktop GPU arena, but it also serves as a platform for penetrating into the data center market.""Vega Frontier Edition’s Target Market: AI, Machine Learning, and other Professionals" - [link]
Ugye tudod, hogy a machine learning és data center között elég szoros kapcsolat van?
Tesla P100/V100 ellen megy. Akárhogy nézzük ez nem mezei konzumer játékos VGA.
#40656: Minden bizonnyal.
-
HSM
félisten
válasz
huskydog17 #40654 üzenetére
Az nem datacenter, sosem volt.
Alapvetően tartalomkészítőknek és játékfejlesztőknek készült, azért volt driverből kapcsolható, hogy játékos vagy profi driverrel menjen.
-
#82819712
törölt tag
Egy beszélgetésnek a témáját vágtam be, mert itt beszélgetni szokás.
de mehet a PR is ha az jobb.
Rethink Performance with AMD Radeon™ Pro Software
(Radeon Pro Software Adrenalin 2019 Edition.) -
schwartz
addikt
válasz
huskydog17 #40651 üzenetére
milyen második 16 GB-os játékoskártyáról
A Vega Frontier az 16Gb.
-
huskydog17
addikt
válasz
#82819712 #40650 üzenetére
Szerinted így teljes értékű?
"Please note that the following gaming features will not be available when using AMD Radeon™ Software Adrenalin 2019 Edition software with AMD Radeon™ Pro graphics cards:
Enhanced Sync, Performance Monitoring, Radeon™ Chill, Radeon™ Game Advisor, Radeon™ Overlay, Radeon™ Settings Advisor, Radeon™ WattMan, Upgrade Advisor"
És milyen második 16 GB-os játékoskártyáról beszélsz?
Pepe, számodra egy külön jótanács: először olvass, értelmezz és csak aztán kommentelj!
-
#82819712
törölt tag
válasz
Petykemano #40647 üzenetére
Eltőrlik a driver választást.
Radeon Pro WX and Vega FE owners can now choose either the Pro driver or the usual Adrenalin driver to install
Magyarán megszületett a második teljes értékű 16 GB-os játékkártya AMD oldalon.
Jöhet a Minecraft 8K. -
Tyrel
őstag
Szerintem még pár év és ugyan olyan lesz mint a tesszeláció vagy az anizotróp szűrés, ezeket is ha régen bekapcsoltad letérdelt a vas, most meg sokszor már nincs is külön gomb rá, csak alapértelmezetten be van kapcsolva és kész, észre se veszed már ill. nem látszik meg az fps-en...
Idővel felnőnek hozzá a GPU-k, addig meg kár erőltetni, úgy is nagyon bénácska még azon a kevés hardveren ill. abban a kevés játékban amiken/amikben fut egyáltalán...
-
válasz
Petykemano #40640 üzenetére
Továbbra is a játékok és jatemotorok nagy része nem tudja a Cryengine felé eljárást kamatoztatni, tehát ilyen szemszögből mindegy mire gondolsz. Jelenleg csak ez a motor és azt hiszem a PS exkluzív játékok között vannak voxelizaciora épülő motorok, de ezt Abu jobban tudja.
Dedikált hardver nem kell, ha rendelkezésre áll megfelelő számítási teljesitmeny és savszel a DXR nel sem,jo példa erre a Volta, ami 80 FPS sel futtatja a BFt -max RT vel.Na igen, de teljesen más egy konzolos hardvert osszevetni egy desktop VGA val.
Hiába Navi alapú, ha az lesz. Igazából semmi közük egymáshoz, olyan mintha egy passatba beledobnal egy Hemi motort (konzol)sajat szerelobrigaddal, és ugyan azt a teljesítményt varnad el az 2.0 TDI tol.
Magyarul az hogy konzolon tudja nem azt jelenti hogy GDDR 6 rammal 256 vagy 384 bites busszal ez természetes lesz PC-n. Egyébként valószínűleg 3 féle xbox verziót dobnak piacra.Azt is elkepzelhetonek tartom, hogy a RT kizárólag a felhős stream játékok kiváltsága lesz.
-
beef
őstag
válasz
#82819712 #40643 üzenetére
Használtak ray tracinget a fáknál ?
Azt nehéz megállapítani a fix kameraszög miatt, lehet hagyományos eljárás is. A táblán és a szemüvegen viszont van.
Ami biztos, hogy az engine egy korai alfa verziója fut, mert egy kerék a bal oldalon maradt. Ezt úgy tudom már javították a 0.6.650-ben a changelog alapján. -
#82819712
törölt tag
válasz
Petykemano #40641 üzenetére
Latency teljes kibeszélése még nem volt ilyen mély include human latency ... mint a Stadia Streaming Tech-en.
Video: Latency Under Load: HBM2 vs. GDDR6
Használtak ray tracinget a fáknál ? -
válasz
Petykemano #40641 üzenetére
Az se biztos, hogy egyáltalán gondolsz valamire.
-
Petykemano
veterán
Hát abban egyáltalán nem vagyok biztos, hogy a navira gondolok -e, és ha igen, melyikre.
Az xbox hardverre viszont igen. Csak nem tudom, hogy kliens vagy cloud hardverre-e.Nem biztos, hogy ehhez kell dedikált hardver. Mármint a cryengine sugárkövetését a vega 56 1080p-ben 30fps futtatta. Ha jól emlékszem, a Vega 10 lapka még csak fp16-ot tudott. (Mi25) és az int8 (mi60), vmint int4 (120tops) a vega20-ban érkezett meg. Ha a (egy) navi is tud ilyet, az talán elég lehet eka normális futáshoz egy 10-14 tflopsos xboxban is.
-
válasz
Petykemano #40638 üzenetére
A Navira gondolsz illetve az erre alapuló Xbox hardverre?
-
Abu85
HÁZIGAZDA
A voxel a háromszögek problémájára jelent itt megoldást. A pixelekhez nincs köze. Amúgy a többi stimmel, azt viszont nem zárnám ki, hogy a Microsoft nem vezeti be a voxeleket. A DXR is ugyanúgy fejleszthető, csak nyilván a voxelekhez megint új hardverek kellenek. Na meg az sem ártana, ha minden motor tudna hatékony voxelizálást, de akár erre is hozható lenne valami API, csak ez már nem olyan egyszerű probléma.
-
válasz
#82819712 #40635 üzenetére
DXR Microsoft megoldása , nem Nvidiáé, egy iparági szabvány eljárás. DXR-t lehet támogatni, de nem voxelizációs megoldás, mint a Crytek féle és a mai legtöbb grafikus motor NEM voxel alapú, hanem pixel( javítva : háromszög) alapú, amire jelenleg a Microsoft DXR eljárása van.
Senki nem tehet arról, hogy a DXR féle raytracing erőforrás igényes, nem kell ehhez kitalálni semmiféle igényt, mert ez adott dolog,hanem egyszerűen ez van ha egy Óriás cég ( Microsoft) egy fele tereli a piacot. -
#82819712
törölt tag
válasz
Petykemano #40634 üzenetére
Ezek a trükkös tükrök...
Tehár RTX ..., Vega 56 ami a piacon már 99-ért is kapható igen ,
Igen köszönjük ezt vártuk, erről beszéltek ködösen eddig..."Ezért korlátozott sugárzási reflexiókat nagyon fényes felületekre, például tükrökre, ablakokra és pocsolyákra korlátoztunk. A meghatározott „fényesség” küszöbérték alá eső felületeknél a hagyományos cubemap-okat használhatják." Yepp.
.-"A drone tükröződése a tükör repedt darabjaiban ugyanúgy működik, mint ahogy azt elvárná".. Yepp
-"elhelyezhetjük az animált tárgyakat a tükrökről, tudva, hogy az animációk pontosan tükröződnek ezekben a tükrökben."
Ez az amikor nem kitalálsz egy igényszintet hanem egy igényhez alakítod a eljárást (sugárkövetés), annyit amennyi kell , ott ahol kell. -
Petykemano
veterán
RayTracing in Cryengine - Neon Noir
"It runs in 1080p with 30 fps on a Vega 56. Reducing the resolution of reflections allows much better performance without too much quality loss. For example in half-resolution mode it runs 1440p / 40+ fps. At the moment we don’t benefit from any additional performance that modern APIs like Vulkan or DX12 or dedicated hardware like the latest generation of graphics cards could give us. But of course, we will optimize the feature to achieve an uplift performance from these APIs and graphics cards.
One of the key factors which helps us to run efficiently on non-RTX hardware is the ability to flexibly and dynamically switch from expensive mesh tracing to low-cost voxel tracing, without any loss in quality. Furthermore, whenever possible we still use all the established techniques like environment probes or SSAO. These two factors help to minimize how much true mesh ray tracing we need and means we can achieve good performance on mainstream GPUs. Another factor that helps us is that our SVOGI system has benefitted from five years of development.
However, RTX will allow the effects to run at a higher resolution. At the moment on GTX 1080, we usually compute reflections and refractions at half-screen resolution. RTX will probably allow full-screen 4k resolution. It will also help us to have more dynamic elements in the scene, whereas currently, we have some limitations. Broadly speaking, RTX will not allow new features in CRYENGINE, but it will enable better performance and more details. "
-
válasz
#82819712 #40626 üzenetére
Tegyuk hozza, hogy ez tovabbra is full AdoredTV...
Adored TV mentions that AMD has issues with the efficiency of the 7nm chips, energy consumption and heat development would be high for specifically the Navi 20 samples. To compensate AMD would only be able to lower clock, which would be lower than 7nm Radeon VII. Navi 20 GPUs (premium GPU) would be delayed until the first quarter of 2020. The midrange NAVI video cards would still be released in the third quarter of this year.
The source of the information is difficult to trace, the information new, however, can't be dismissed either. Please take common sense and the usual disclaimers in mind.
Pepe, nem kene az uj accal is tultolni as AMD fanatikussagot....
-
Raggie
őstag
Ez megint nulla értékű hír. Kizárólag az AdoredTV forrásból kreált kis clickbait cikk... egyáltalán nem venném komolyan. Tényleg lelőhetné már valaki azt a csávót.
SZERK: (#40626) meteoreső: nem csodálom hogy egyezik az Adored jelzéseivel, mert konkrétan csak az összeirkálva egy cikkben...
-
-
Z_A_P
addikt
-
-Solt-
veterán
válasz
Zartszelveny #40623 üzenetére
Írj privátot holnap, itt nem offolnék már ezzel.
-
Abu85
HÁZIGAZDA
válasz
Petykemano #40620 üzenetére
-
Petykemano
veterán
"One thing I'm still confused about with GCN and my Google-fu is failing me (asking console devs on Twitter might be the easiest route but hopefully someone here knows as well): transcendental/special-function is 1/4 rate on GCN, but do they stall the entire pipeline for 4 cycles, or can FMAs be issued in parallel for some of these cycles?
Everything I've found implies that they stall the pipeline for 4 cycles, which is pretty bad (speaking from experience for mobile workloads *sigh* maybe not as bad on PC-level workloads) and compares pretty badly with NVIDIA which on Volta/Turing is able to co-issue SFU instructions 100% for free and they don't stall the pipeline unless they're the overall bottleneck (as they've got spare decoder and spare register bandwidth, and they deschedule the warp until the result is ready; obviously they can't co-issue FP+INT+SFU, but FP+SFU and INT+SFU are fine).
It feels to me like at this point, 1 NVIDIA "CUDA core" is actually quite a bit more "effective flops" than an AMD ALU. It's not just the SFU but also interpolation, cubemap instructions, etc... We can examine other parts of the architecture in a lot of detail as much as we want, but I suspect the lower effective ALU throughput is probably a significant part of the performance difference at this point... unlike the Kepler days when NVIDIA was a lot less efficient per claimed flop than they are today.
The "Super SIMD" patent is an interesting opportunity to reverse that for AMD, especially if the "extra FMA" can run in parallel to SFU and interpolation instructions and so on... I really hope it gets implemented in Navi and the desktop GPU market gets a little bit more exciting again!
"
Szakvélemény, abu?
-
.Ishi.
aktív tag
válasz
Petykemano #40618 üzenetére
Igen, pontosan erre gondoltam én is. Kíváncsian várom, hogy mi lesz a hozzáállásuk az új kártyákkal kapcsolatban.
-
Petykemano
veterán
válasz
.Ishi. #40617 üzenetére
"ne legyen gyárilag szénné húzva, csak azért, hogy pár százalékkal jobbnak tűnjön egy grafikonon"
Pedig sajnos az AMD az utóbbi időben pont ezt csinálta: húzott 5-10%-ot a kártyán annak ideális frekvenciáján túl, ami eredményezett mondjuk 5-10% gyorsulást az ideálishoz képest 30-50%-os többletfogyasztás mellett.
Persze Te megteheted, hogy power limitet állítasz, de végső soron az 5-10%-kal hosszab csíkot kifizeted úgyis.
...
Én abban reménykedem, hogy ez a hozzáállás amiatt volt csak, hogy a gyártókapacitás a GF-nél limitált, de legalábbis nem rugalmasan skálázható volt. -
.Ishi.
aktív tag
válasz
Petykemano #40602 üzenetére
"a gcn sok energiát zabál - és ezt is várjuk tőle."
Én igazából csak azt várom, hogy akármilyen kártya is jelenjen meg (ami nekem megfelel), ne legyen gyárilag szénné húzva, csak azért, hogy pár százalékkal jobbnak tűnjön egy grafikonon.
-
Abu85
HÁZIGAZDA
válasz
#82819712 #40607 üzenetére
A Google eleve kevés peremhálózati szerverbe rakott még GPU-t. Azt a 7000-et nem egy hónap alatt fogják feltölteni, hanem inkább egy év alatt. Valószínűleg a V340-eket sem cserélik le még, hiszen azok jól működnek ám, csak ha van Navi, akkor az alacsonyabb üzemeltetési költséggel beépíthető, márpedig a Stadia esetében ez a lényeg. Főleg úgy, hogy 7000 szervert kell megtölteni GPU-kkal. De ez nem egyik napról a másikra lesz.
Az is lényeges, hogy a Google az nagy megrendelő. Az AMD simán csinál nekik olyan hardvert bármiből, amire igényük van. Nem egy nagy mérnöki munka egy NYÁK-ra két Navit rakni.
-
hokuszpk
nagyúr
válasz
Petykemano #40606 üzenetére
akkor nincs miert aggodni. Lisa ura a helyzetnek. vagy ilyesmi.
-
#82819712
törölt tag
válasz
Petykemano #40610 üzenetére
Fogyasztás:
1. Vega Pró ha a hatékonyságuk miatt veszik energiahatékony ,vagy csak több usert képes ellátni a v340-nél / user akkor is az.
Ez igaz Gamerbe lecsorgó felsó kat. kártyára is... ha lecsorog.
2. Navi diszkrét DDR6 miatt többet fog fogyasztani mintha HBM-en lenne, power hungary -zik adored a 590re (joggal mert 12-n is sokat fogyasztott) ezt lehet tovább vetíteni, de a 7nm EUV meg a két új működő fícsör segíteni fog.
3. APU na ez azért érdekes mert ugye tudjuk hogy itt van IO és azt is tudjuk hogy ez 14nm-es nem 7, ez is plusz fogyasztás (azért nem 12 mert vannak useful userek hálánk mindig üldözni fogja)Csak egy az örök titok ha a Stadiának annyira nagyon kell a késletetésmentesség miért nem vezetékes a kontrollere.
-
Petykemano
veterán
válasz
Raymond #40609 üzenetére
"[...] Ide kellenek olyan megoldások, mint a Navi, mert a V340-nél jobb hatékonysággal működik.
[...]
Google nagy megrendelő, így nekik nem kell megvárni a fejlesztés alatt álló Radeon Pro megoldásokat, hanem szállítja nekik az AMD idő előtt. Ezért cserébe sokat fizetnek." -
Raymond
titán
válasz
Petykemano #40608 üzenetére
Miert? Veszi?
-
#82819712
törölt tag
Elhiszem amit mondanak a Stadiáról ez a közvetlen kapcsolat dolog oké csak azt mondja meg valaki ha a mai V340 es ssd-s Vegákat leváltják a szerverparkokban ami jelenlegi forintos áron olyan 1.8 milió per darad és kicserélik mint Abu írta egy már létező Navi HBM-es Pro kártyára szintén ssdvel mondjuk túlárazva 4-5 milláért és mondjuk 2-4 játékost tud kiszolgálni egy ilyen kártya egyszerre full hd képpel vagy 4k-n 1-2-t akkor mennyibe fog kerülni nekem egy óra játék vele...ebből 1 szerverpark is hatalmas összeg hát még " 7000 peremhálózati szerver "
De legalább értem mért megy fel az Amd részvény. -
awexco
őstag
válasz
Cyberboy42 #40595 üzenetére
Nyugodj meg a saját gépeden render idő
-
korcsi
veterán
-
hokuszpk
nagyúr
válasz
Petykemano #40602 üzenetére
en mar nemnezem ezt a csokat, annyit aruljatok el, a beepitett embereire hivatkozas van-e a videoban ?
Új hozzászólás Aktív témák
Hirdetés
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.
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- One mobilszolgáltatások
- Temu
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- iPhone topik
- Víz- gáz- és fűtésszerelés
- The First Berserker: Khazan
- Házi hangfal építés
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- További aktív témák...
- LG 55G4 - 55" OLED evo - 4K 144Hz & 0.1ms - MLA Plus - 3000 Nits - NVIDIA G-Sync - FreeSync Premium
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Lenovo ThinkPad T14 Gen 4 üzleti notebook - i7 1360P 24GB DDR5 RAM 512GB SSD Iris Xe W11
- Szerezd be most az érzékelhető különbséget! Akár 0% THM-re
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged