2. Fórumok
  3. Videokártyák
  4. Vélemény: az Ampere megmutatta, hogy miért nem szabad felülni a pletykáknak
Keresés

Hirdetés

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

  • #77 arabus addikt do3om #75
    Új Válasz #77
    Ú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

    arabus

    addikt

    válasz do3om #75 üzenetére

    a karácsonyi fa szezon?vagy mi?
    2600xt januárban jelent meg és akkor?
    megvettem februárban.
    ja vagy törvényszerü hogy akkor most be kell jelenteni.
    annyira ne várd mert dá-dá lesz.

    Xeon Platinum 8490H,8468H,Ryzen 7500F,Gigabyte B650M K,Xeon Phi,i9 7960X,i9 7920X,Xeon w2135,Gskill royal 4400,Gskill Trident Z,Pico 4,Red Devil 7900XTX,Asrock W790 WS,Fury Pro RDIMM 6000,Z590,Intel Cryo,Intel 11900F,Ryzen 5600,Radeon 7600,Radeon 6800...

  • #89 Abu85 HÁZIGAZDA do3om #75
    Új Válasz #89
    Ú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 do3om #75 üzenetére

    Hol is köhögtem, hogy balfaszok az NV-nél?

    Az AMD-nél nem tudom, hogy röhögnek-e. Nekem a TUL-hoz van egy kontaktom, és ő nem izgul. Ma is beszéltem vele, leírtam itt: [link] - effektíve ők a megjelenés előtt 2,4x gyorsabbra számolták a 3080-at a 2080-hoz viszonyítva a 3DMark TSE-ben. Ebből ~70+% lett a gyakorlati pontoknál. Ezt a különbséget nem értették, de már elérhető a whitepaper, ami leírja, hogy az Ampere függőséglimites architektúra lett, így már ők is ~80% pluszt számolnak papíron. Most nyilván az early driver benne lehet, ebben a különbségben, csak némi órajelskálázás, de ugye a papír már nem különbözik annyira a gyakorlattól, mint amikor korábban számolták.

    (#80) cskamacska: A technikai cikket itt többen hiányolták, hogy miért akkora a TFLOPS, amekkora. Ha nem írom meg, akkor az a baj, ha megírom, akkor meg az. Döntsétek már el végre. :))

    A programozás szempontjából mindegyik dizájn esetében számít valamennyit, hogy optimalizálnak rá. Mindegyik architektúra alapvetően kihasználtságlimites, tehát a megadott számítási teljesítmény minden esetben elméleti. A kihasználtságlimiten azt értjük, hogy az adott multiprocesszoron futhat egy fix mennyiségű munkamenet. Ezek számát az határozza meg, hogy egy adott shader mennyi regisztert és compute feladat mellett mennyi LDS-t igényel. A kihasználtságlimit ott jelentkezik, ha nem lehet elég munkamenetet betölteni, mert nincs elég statikusan allokálható erőforrás rá, így az egyes munkamenetek közötti váltásnál a multiprocesszor nem biztos, hogy tud dolgozni, mert az adat beérkezéséig nem lesz elég szabadon futtatható feladat.
    A legtöbb mai GPU-architektúra ilyen, lásd GCN, RDNA, Fermi, Kepler, Maxwell, Pascal, Turing, az ARM Malik közül a legújabbak, stb. ... ezeknek a dizájnoknak a jellegzetessége, hogy már a felépítésük ellehetetleníti a függőség kialakulását.

    Az alternatív dizájnokat a függőséglimites architektúrák képviselik, amikor az történik, hogy az ütemező képes úgy kiosztani a munkameneteket, hogy bekövetkezhet a függőség. Tulajdonképpen ezek a hardverek is kihasználtságlimitesek valahol, csak nagyobb esély van arra, hogy mielőtt elfogy a leköthető erőforrás, bekövetkezik valami függőség, ami hamarabb limitálja feldolgozást. Ilyen architektúrának tekinthetők például az Intel GenX és Xe dizájnok, az AMD régi Terascale-ja, illetve az új Ampere.

    Viszont mindegyik rendszernek van valahol egy limitje, és az optimalizálás abból áll, hogy azt a limitet próbálod elkerülni. A kihasználtságlimit esetében a legfőbb stratégia, hogy egy shader a lehető legkevesebb regiszternyomást fejtse ki, compute esetén itt még bejön a képbe az LDS-nyomás is. Minél jobb az erőforrások allokációja, annál több munkamenet lehet bekészítve, hogy átlapolja memóriaelérést.
    A függőséglimit annyi pluszt visz ebbe a buliba, hogy arra is figyelni kell, hogy lehetőség szerint minimális legyen a konkurens munkamenetek egymástól való függése. Tehát nem elég, hogy jó legyen az erőforrások allokációja, az sem mindegy, hogy miképp fogsz számolni. Erre is vannak különböző programozási stratégiák, az AMD például évekig nyomta ezt, és az Intelnek még közelebb van az Ampere-hez a dizájnja, tehát az erre vonatkozó tudásbázis elég nagy, az NV-nek nem kell a nulláról vinnie az egészet, nem újdonság ez.

    A fordítókat is majd ehhez kell igazítani, mert azon is múlik, hogy az adott shaderből mit tud kihozni. Felerősödhet a shader csere, hiszen ez az elmúlt években nem volt annyira túlerőltetve a meghajtó oldalán az AMD és az NV szempontjából sem, de a függőség bevisz egy olyan tényezőt a képbe, ami több fordítóoldali optimalizálásra ad lehetőséget.

    Önmagában tehát a függőséglimit nem egy rossz irány, ha az lenne, akkor senki sem alkalmazná, az Intel se, az AMD sem csinált volna ilyen dizájnt sok-sok éve, meg persze az NVIDIA sem most. Ezeknek megvannak a maga előnyei, illetve maga hátrányai. Az előnye kétségtelen, kis tranzisztorköltségből tudsz bedobni ALU-kat co-issue módra, tehát az extra számítási kapacitáshoz nem kell ezekhez az ALU-khoz saját ütemezőt rendelni, és ez viszi ám el a sok tranzisztort, meg a regiszterek, nem pedig maga az ALU. A hátránya szoftveres oldalon keletkezik. Többet kell optimalizálni a fordítón, illetve magán a programkódon, hogy a kódfuttatás optimális legyen. És ez egy proven technology szintű dolog, ha nem működne, akkor az AMD nem tudott volna jó eredményeket elérni a Radeon HD 5000-es sorozatban. Meghajtókat pedig folyamatosan lehet hozni a termékhez, tehát ha találnak xy címhez pár százaléknyi extrát, pár shader cseréjével, akkor kiadnak egy új drivert és kész. Az AMD is elég sokáig ezt csinálta a TeraScale időkben, megjelent egy játék, nekiestek, és volt, hogy még másfél hónap múlva is extra tempót találtak hozzá, tehát a koncepció működik. Ma már ez ritkább, nincs annyi lehetőség szoftveres oldalon egy kihasználtságlimites architektúrával, gyorsabban jutsz el arra a pontra, amikor a program optimálisan fut, de humánerőforrás ma már elég sok van a driverbe épített fordítók megírására, tehát az NVIDIA számára ez nyugodtan bevállalható volt.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

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