Keresés

Új hozzászólás Aktív témák

  • Abu85

    HÁZIGAZDA

    válasz con_di_B #56 üzenetére

    A cache-miss lehetőséges, de a Vega 10-ben ~45 MB-nyi SRAM van, ennek egy jelentős része csak a mozaikos feldolgozáshoz tartozik. Alaposan fel van tehát duzzasztva a korábbi GCN dizájnokhoz képest. A Fiji-ben például ~10 MB-nyi SRAM van.

    Nem csak viszonylag. A HBM2 a Vega 10-en 6 wattos TDP keretet kap. Ugyanennyi egy 64 bites GDDR5-ös konfigurációra lenne elég.
    A magas fogyasztásról alapvetően a skalár ALU-k tehetnek. Direkt megkérdeztem anno. Viszont ezeknek köszönhető az is, hogy a Vega 10 és úgy általánosan a GCN hardveresen támogatja a resources binding és heap legmagasabb szintjeit. Az Intel itt papíron jó, de tudni, hogy trükköznek. Nekik ugye annyiban könnyebb a helyzet, hogy ott a processzor ugyanazon a lapkán, ráadásul közös az LLC, tehát van lehetőség olyan turpisságokra az implementációban, amelyek dedikált GPU-val vállalhatatlanul lassúak lennének. Ergo vagy van skalár ALU és akkor megoldható a DX12 teljes támogatása, vagy nincs skalár ALU és akkor csak minimum szinten van resources heap, de persze ez meg kevesebbet fogyaszt. Az éremnek két oldala van. A választás persze messze nem egyértelmű, ha az lenne, akkor mindenki támogatná a DX12 összes funkcióját.

  • Abu85

    HÁZIGAZDA

    válasz gbors #51 üzenetére

    Így mérik a hatékonyságát a mozikos hardveres optimalizálásoknak. Elvégre ezek arról szólnak, hogy mennyi bájt/frame-et tud spórolni. Ha hozza a tipikus 25-35%-ot BF4-ben, akkor rendben működik a hardver. A BF4 azért jó példa, mert az direkten még nem optimalizált az efféle hardverekre, tehát mindenki nagyjából ugyanolyan hátrányból indul. A BF1 már egy kicsit más. Abban már van Pascalra és Maxwellre optimalizálás, míg a Battlefront 2-ben a Vegára is. Itt már erősen közrejátszik a szoftveres tényező, mert nem minden hardverre ugyanaz a paraméterezés. De persze itt is meg lehet nézni, hogy mennyit spórol, csak a szoftver is segít neki.

    (#54) con_di_B: Az AnvilNext konzolon már úgy van megtervezve. Csak PC-re ez nincs átmentve, mert a port leragadt a DX11-nél. :DDD

  • Abu85

    HÁZIGAZDA

    válasz con_di_B #48 üzenetére

    A programozható skalár egység azért elég fontos tényező. A fogyasztás egy jelentős részéért tényleg ez felel, cserébe hardveresen lehet támogatni a DX12-ből mindent.

    Alapvetően jól működik a DSBR az eddigi mérésekből. BF4-ben megvan egy bő 30%-os megtakarítás a memória terhelésére (bájt/képkocka) vonatkozóan. Ennél nem igazán működnek jobban az egyéb mozaikos rendszerek. Sőt, 25-35% közötti a tipikus megtakarítás a BF4-ben, tehát a Vega a 33%-jával a takarékoskodóbb opciók közé tartozik, de ha csak 25% lenne, akkor is hatékonynak mondható a bevetett mozaikos technika. Tehát egyáltalán nem lehet azt mondani, hogy rosszul van kiegyensúlyozva itt a rendszer. Aztán persze per alkalmazás szintjén a fejlesztők is szoktak manapság optimalizálni a mozaikos leképezésre, tehát programfüggően lehetnek eltérések. De ezt az új programok megoldják.

  • Abu85

    HÁZIGAZDA

    válasz hapakj #39 üzenetére

    Itt nem az architektúráról van szó, ami egyébként nem skalár, hanem SIMT. Maximum az ALU skalár. A vezérlésről beszélünk, elvégre minden GPU multiprocesszorában van egy fixfunkciós branch egység, ami ellát valamilyen előre betervezett funkcionalitást. Egyedül a GCN tér el ettől, mivel ennek a multiprocesszorában egy programozható integer skalár egység van, ami a CPU munkáját teljesen ki tudja váltani. Minden memóriahozzáférés, akár a szűrt adattal visszatérők is beleprogramozhatók a shaderekbe, mert lényegében erről szólnak a bindless szintek, hogy a CPU-t ne terheljék a fejlesztők ezzel a feladattal. Na most a programozhtóság megkövetelése miatt ezt nem tudod csak úgy fixfunkciós blokkal megoldani, ide kell egy olyan programozható integer skalár egység, ami megcsinálja a proci feladatát.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #34 üzenetére

    a) Szerintem az NGG helyére jó a GPGPU culling aszinkron compute-tal és az RPM-mel. Látszik a Wolf 2-ben, hogy működik, a Far Cry 5 is ilyet használ. Az NGG-vel szemben mindenképp az az előnye ennek a megoldásnak, hogy nem csak a Vega GPU-kon fut, hanem mindenen, mert szabványos compute shaderekrúl van szó. Ergo lehet, hogy több munkát kell belefektetni, de megéri, mert a Vega GPU-k mellett minden más hardver profitál az eredményből. Konkrét mérések nincsenek, de nem lepődnék meg rajta, ha egy ilyen GPGPU culling pipeline async compute és RPM mellett gyorsabb lenne, mint az NGG maga. Öszvér megoldás, de sebességben jobb és szabványos. A piac ezen nyer.

    b) A konzolok nem támogatják a primitive shadert. A PS4 Proban van superstencil, erre épülhetnek olyan effektek, amelyeket normális sebességgel csak primitive shaderre lehet átültetni.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #30 üzenetére

    Az algorimusért. Ha valaki integrálni akarja, akkor az pénzbe kerül. Azért ilyen rendszert nem két perc kidolgozni, amit most látsz a Radeon Software-ben, az nagyjából négy év munka eredménye. De a többség bele sem fog, mert az AMD-nél vannak olyan szabadalmak, amelyekkel betámadható egy Chill-másolat.
    A fejlesztőknek azért érné meg a programba való integrálás, hogy a Chill ne csak Radeonon működjön, de ehhez ki kellene fizetni az AMD-nek a licencet, vagy ha saját rendszert írnak, akkor a kapcsolódó szabadalmakról kell megegyezni.
    Igen, azért fizet az Intel. Egyelőre csak a Kaby Lake-G-re. De igazából maga a rendszer üzemképes lenne Intel IGP-vel is, ha hajlandó a cég megfizetni.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #27 üzenetére

    A Chillnek simán lenne támogatottsága. Sokkal bonyolultabb AMD-only dolgokat beraknak a mai játékokba, lásd shader intrinsics, ami konkrétan alternatív shadereket igényel, vagy RPM, amihez specialis header kell. Itt a probléma tényleg a licenc lehet, mert amíg a shader intrinsics eszközei GPUOpen-en elérhető MIT licences megoldások, addig a Chillért keményen fizetni kell. Jól jelzi, hogy eddig erre csak az Intel volt hajlandó. A HiAlgo felvásárlásával ugye a szabadalmak is az AMD-hez vándoroltak, tehát lemásolni sem könnyű.

  • Abu85

    HÁZIGAZDA

    válasz Abu85 #25 üzenetére

    Annyit hozzátennék, hogy igazán kellemes lenne ezt a PC-s játékokba integrálni. De gondolom az AMD nagyon drágán méri a licencet. Elvégre eddig csak az Intel fizette meg.

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #24 üzenetére

    Nem csak ez a lényege. A Chill nagyon bonyolult rendszer. Igazából olyan, mint a frame pacing a multi-GPU-knál, csak itt scene pacingről van szó. Egyszerűen a hardvert vezérlő szoftver még elég sok OS funkciót megpróbál befolyásolni, hogy maguk a jelenetek kontrollálva, egyenletesen érkezzenek meg a GPU számára. A kontrollt ugye maga az input befolyásolja. Ha akció van, akkor a jelenetszámítás nincs korlátozva, míg ha csak nézel előre, vagy maga az input látszólag lassú, akkor a jelenetszámítás vissza lesz fogva. Ez igazából több előnnyel jár. Egyrészt az a tapasztalat, hogy a játék során követik egymást a lassú és gyors részek, és a lassú részeknél nincs szükség 100 fps-re. Itt spórol a hardver. A scene pacinggel járó alacsonyabb késleltetés igazából csak egy mellékterméke a működésnek, mivel valahogy muszáj szabályozni a terhelést, és az az ideális, ha a jelenet számítása lesz kontrollálva. Mivel ez nagyon egyenletessé teszi a GPU számára is a terhelést, így minden inputhoz tartozó kép gyorsabban megérkezik a kijelzőre, mint a klasszikus, nem szabályozott dupla vagy tripla pufferes koncepcióval. Ezért szeretik az eSportolók, de ez tényleg csak az algoritmus mellékhatása, valójában nem volt cél a késleltetés minimalizálása.

  • Abu85

    HÁZIGAZDA

    válasz smc #20 üzenetére

    Mert a "beállítottam valamit és én úgy gondolom, hogy az általam használt programokban és driverbeállításokban, megfelelő eszközök híján stabilnak tartott", és "a ténylegesen stabil" között óriási a szakadék. Az AMD nem csak egy meghajtómódot kínál, hanem hozzávetőleg egy tucatot. Ráadásul olyanokat, amelyek ugyanannak a kártyának a terhelés melletti átlagfogyasztását akár a harmadára is csökkentik. Tehát mondjuk a Vega 56-nek nem csak 210 wattos TDP mellett kell stabilnak lennie, hanem 100-230 wattos, gyakorlatilag majdnem 1 wattonként paraméterezhető tartományban. Hazaviszed a kártyát, de 200 helyett 100 wattos átlagfogyasztást akarsz? Az Adrenalin meghajtó óta a te döntésed. Ráadásul nem is fogod megérezni, mert akkor spórol, amikor nincs akció a jelenetben.

  • Abu85

    HÁZIGAZDA

    válasz smc #18 üzenetére

    Akkor ezt tegyük tisztába. A fogyasztáson ez igazából nem sokat csökkenthet. Persze a sávszélkímélés játszik, de a Vega 10 HBM2-t használ. Nagyjából 4 wattos az innen keletkező igény. Ez nem GDDR5-GDDR5X, ami ~400 GB/s-os sávszél mellett lezabál 25-35 wattot, hanem nagyságrendekkel takarékosabb HBM2. Ahol az NGG mód segít az a hatásfok. Elvégre kivág egy csomó fals pozitív háromszöget, így alapvetően növeli a feldolgozás teljesítményét. Ez érthető, a GPU nem költ erőforrást a szükségtelen adatokra, de a szükséges adatokat kiszámolja. Viszont ha nincs szükségtelen adat, attól még a szükségeseket ugyanolyan párhuzamosítással kalkulálja a hardver, csak a munka lesz kész gyorsabban. Ami a fogyasztáson segít az az NGG IWD része, de az már be van építve a driverbe. Segíthet persze a fogyasztáson a primitive shader, ha eleve korlátozza valami a számítást, ilyenkor nyilván számít, hogy a szükségtelen adatokkal nem kell foglalkozni, vagyis több lehet az üresjárat. Ez mondjuk a gyakorlatban nem egy ritka dolog, tehát valamennyit ért volna.

  • Abu85

    HÁZIGAZDA

    válasz BenceShearer #14 üzenetére

    Egyáltalán nem. A Vega és általánosan a GCN amiatt fogyaszt többet, mert egyedül a GCN-ben van skalárfeldolgozó, így amíg a többi hardvernek bizonyos API funkciókhoz (pure bindless bekötés, bővített erőforráshalmaz) a host processzor segítsége kell, addig a GCN önmagától képes elvégezni ezeket a feladatokat, mert van egy programozóható skalár egység a multiprocesszorokban. Az NV fixfunkciós egységeket alkalmaz a vezérlésre, amelyek nem programozhatók, így nyilván kevesebbet is fogyasztanak. Viszont emulálni kell bizonyos API funkciókat. Az Intelnél sok dologra eleve a CPU-magok vannak befogva, mert ugyanazon a lapkán találhatók, mint az IGP.

Új hozzászólás Aktív témák

Hirdetés