2. Fórumok
  3. Videokártyák
  4. Inkább program oldalról támogatná a primitive shadert az AMD
Keresés

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

  • #69 namaste tag con_di_B #67
    Új Válasz #69
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    namaste

    tag

    válasz con_di_B #67 üzenetére

    Igen, a SIMD16 vektor egységek így működnek.
    A bekötés az csak a leíró betöltése és tárolása a skalár regiszterekben, illetve ha szükség van az erőforrásra, akkor regiszterekben lévő leírót elküldi a textúrázó vagy a load-store egységnek.
    Pontosan erről van szó, a skalár egység egy kis része a CU-nak, ezért nem tehető felelőssé a magas fogyasztásért. A funkcióit az NV hardverek különféle részegységei ugyanúgy ellátják.

    "Persze ha csökkentik a feszültséget, akkor először a skalár egységet kapcsolják le, ugye?"
    Ezt nem kell komolyan venni, nyilván nem így működik. Arra akartam utalni, hogy a magas fogyasztásért inkább a magas feszültség tehető felelőssé.

    Már az első GPU-k is parancslistával működtek. Az NV1 (1995) gyakorlatilag csak textúrázni tudott, még semmi T&L, shader, vagy compute nem volt és az elvégzendő feladatokat parancs bufferbe kellett beírni.
    A Kepler GK110-ben van Grid Management Unit és Work Distributor a compute feladatokhoz, a Fermiben csak Work Distributor.
    Az Intel IGP-k leírása publikus, megnézném hogyan dolgozik össze a CPU-val.
    Az AMD azért erőlteti az async compute-ot, mert raszterizálásban illetve ROP-ban korlátos, ezért ha grafika számolása közben compute feladatokkal is tudja etetni a CU-kat, akkor növeli a kihasználtságot és a teljesítményt.

  • #61 Petykemano veterán con_di_B #57
    Új Válasz #61
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Petykemano

    veterán

    válasz con_di_B #57 üzenetére

    Az amdt nem egy optimális üzemmód érdekelte, sose volt drága tíz-száz wattokkal fizetni pár százalék többletteljesítményért.
    Valamit csinál az energiatakarékos mód.
    Csinálhatná ezt is, amit mondtál.
    Vagy le is kapcsolhatna CU-Kat...

  • #59 Abu85 HÁZIGAZDA con_di_B #56
    Új Válasz #59
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

  • #52 Raysen623 addikt con_di_B #48
    Új Válasz #52
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Raysen623

    addikt

    válasz con_di_B #48 üzenetére

    Mind a két gyártó másra használja el az ALU-kat, ez már jó ideje látható. A piacot viszont az viszi el, aki nem csak legyártja hanem marketinggel meg is támogatja. A termék ugyanis nem fogja magát eladni, hiába pazarolnak el több ALU-t a hw képességek fejlesztésére. Ha nincs mögötte jó marketing és hw support, akkor nem lesz rá fejlesztés. AMD itt b@szta el évekkel ezelőtt és ezért is futnak jobban a zöldeknél a játékok.

  • #50 Petykemano veterán con_di_B #48
    Új Válasz #50
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Petykemano

    veterán

    válasz con_di_B #48 üzenetére

    ez a programozható skalár ALU azért fura magyarázat mindenre, mert
    - az hogy lehet, hogy ha ez így sokmindent elvégez magában, magának, más módszer meg sokmindent átterhel a CPU-ra - és eközben a másik gyártó módszerével a teljes rendszer fogyasztása is kisebb, meg nem nagyobb a processzorterheltség sem?
    - milyen előnyt is hozott eddig ez?

    Lehet, hogy a vega egy ilyen két generáció közötti öszvér. Mármint nincs baj azzal, hogy ha beépítenek funkciókat a hardverbe, amivel kísérletezni akarnak, amit próbálgatni akarnak, fejleszteni akarnak, kipróbálni akarnak. Csak ne tessenek már egy kísérleti senki által nem adoptált és a piaci viszonyokból kiindulva várhatóan senki által nem adoptálandó megoldást - idő előtt - sikerhozó fícsörként reklámozni.

    Vagy ez úgy ment, hogy odament a marketinges a mérnökhöz, hogy megkérdezze, mit tud a gép?
    - Hát semmit, relatív nagy mértékben sikerült növelni a frekvenciát. finomítottunk pár dolgot, de semmi extra.
    - 4 év alatt, ennyi? NEmá, öregem, így hogy adjam el? nincs benne semmi újítás? Mi a szart csináltatok ennyi évig? ENnek már 1 éve kint kéne lennie!
    - Hát a főnök azt mondta, növeljük a compite teljesítményt, így bekerült a feles pontosság..
    - Feles pontosság... ez nem hangzik valami jól. Mire jó ez?
    - Matematikai műveletek. GYorsabban számol feles pontossággal. De ehhez az szükséges, hogy két műveletet egybecsomagoljon. Érted. Mert valójábnan 32 bites...
    - tehát Gyors összecsomagolt matematika. Rapid Packed Math. Ez jó! Mi van még?
    - Van ez a High Bandwidth Memory, ami most már..
    - HBM. ennek ninsc jó PR értéke... igen, figyelek
    - a fijinél problémát jelentett....
    - ez akkor egy fiji leszármazott?
    - hát... tulajdonképpen igen,
    - GCN... mennyi is? 5..
    - Igen 64 CU, mint a fiji, de megújítottuk és most már sokkal...
    - NCU - Next Compute Unit
    - Aham. Na szóval a HBM-re visszatérve, a fijinél prioblémát jelentett a memória mennyisége, és most már úgy működik ténylegesen, ahogy a fijinél szerettük volna, tehát hogy tulajdonképpena viszonylag kis mennyiségű fedélzeti memória képes amolyan Cache-ként működni. Nem kell minden adatot betölteni, hanem a rendszermemóriából tud lapozni. Ez kurva jó lesz, majd meglátod, amikor az SSD
    - High Bandwidth... Cache! Hmm. kicsit összetéveszthető a micron HMC-vel. Meg most akkor a HBC az a memória?
    - Nem, a memória az a HBM. EZ a képességet egy beépített Cache Controller csinálja, ami nem csak...
    - HIgh Bandwidth Cache Controller. HBCC. Ez az. Na mi van még?
    - Megújítottuk ezt, meg azt, megnöveltük az L2$ méretét...
    - A vásárlókat nem izgatja a cache mérete, de mindegy, figyelek, mondd tovább
    - Hát nem tudom, ez van kész.
    - EZ van kész? Mi nincs kész?
    - Figy, a főnöknek van egy terve, de ez még csak kísérleti stádium. Rájöttünk, hogy csinálta az nvidia, de még túl későn kezdtünk bele a beépítésbe. Még nem az igazi.
    - Jó, de mi?
    - Az egyik az, hogy raszterizáláshoz felosztjuk a képernyőt és hát oylan mint a Tile based rasterizer. DE még nincs kész.
    - Jó, akkor legyen valami hülye neve, valami, amit senki se ért, de jól hangzik. Majd kitalálom.
    - De ne, ezt ne írd le, ez még csak kísérletezgetés egy új technológiával. A múltkor is ,amikor a színtömörítéssel próbálkoztunk, úgy adtátok el, mint valami csodafegyver.
    - Sajnálom, már kimondtad. Na mi a másk
    - Na jó, szóval a főnök azt mondta, hogy nagy compute teljesítményű gép kell olcsón. DE a józsival kitaláltuk, hogy ha a képkockákat még a rajzolás előtt kivágjuk, akkor sokkal kevesebbet kell dolgoznia és gyorsabb lesz. Ez egy elég primitív módszer a shaderkapacitás felszabadítására, de működik...
    - Primitive shader.. aha
    - Csak hát ehhez sajnos a programot úgy kell megírni. Kiváló megoldás lenne, de nem tudom hogy fogjuk elterjeszteni
    - Nyugi, megoldjuk. MAjd azt mondjuk, hogy minden kap driveres támogatást.
    - De de az nem fog menni, vagy hát iszonyú sokat kellene dolgozni
    - NCU, HBCC, DSRB, primitive shader.... kösz, Béla, ennyi volt, ez így már talán elég lesz, hogy eladjuk a hülyéknek a nagy semmit. Csak tudnám, mit csináltatok 4 éven keresztül.... jézus, ennek a fele kamu, mi lesz itt ha kiderül.
    Mindegy, majd a bányászok úgyis megveszik.

  • #49 Abu85 HÁZIGAZDA con_di_B #48
    Új Válasz #49
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    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.

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

Hirdetés