Hirdetés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz Petykemano #47748 üzenetére

    Nem. Azért tűnnek furának, mert az utóbbi időben a GPU-kból eltűntek a co-issue és dual-issue feldolgozók, de régen igen sűrűn voltak ilyenek bevetve. Talán emlékszek még az R600-ra, ami szám szerint 320 FP32-t használt, de úgy, hogy 1+1+1+1+1 co-issue módban üzemeltek a multiprocesszorok (és ez igaz volt egészen a GCN-ig, bár az utolsó dizájnok már 1+1+1+1 co-issue módra váltottak vissza). Ezzel szemben ment az NV-nek a G80-ja 128 FP32-vel, de mindenféle co-issue nélkül. De itt az Intel is, ami 4+4 co-issue multiprocesszort használ. Az utóbbi időben ezek a trükkök kikoptak a GPU-kból, mert a komplex kódokban nagyon nehézzé vált a co-issue mód kihasználása, de hardveres szinten ezek azért megfontolandók, mert a tranzisztorköltsége nem nagy a nyers ALU-knak. Ami igazán viszi a tranyót az az ütemezés, az adatbusz, a regiszterek, stb. És pont ezt kerülik meg ezek a co-issue módok, amik valami speckó helyzetet kihasználva hozzácsapnak némi extra kapacitást a rendszerhez. Ezzel kvázi dupla ALU-t kapsz anélkül, hogy jelentős tranzisztorköltsége lenne, cserébe nem olyan a multiprocesszor utilizációja, hogy azt a dupla ALU-t olyan hatékonyan lehessen felhasználni, mintha erre ráterveznéd az ütemezést, a regisztereket, az adatbuszt, stb. Ezért sem tudja az RTX 3080 a nyers paraméterek alapján nagyjából háromszoros előnyét háromszoros fps-re váltani a 2080-hoz képest. Ebből az NV szerint kétszerest abszolvál a gyakorlatban, bár mondjuk nyilván minden szentnem maga felé hajlik a keze, de most tegyük fel, hogy hoz ennyit. Tehát az FP32 utilizáció lényegesen rosszabb lett, de arányaiban azt kell nézni, hogy a befektetett tranzisztorköltséghez képest mit javult.

    Az efféle módokról egyébként az teljesítményingadozás miatt álltak le a gyártók, mert az R600-ra például jellemző volt, hogy valahol nagyon alázott, valahol pedig nagyon szar volt, és ez attól függőt, hogy egy adott alkalmazásban mennyire lehetett kihasználni a specifikus működési módokat. Ha például egyáltalán nem lehetett, akkor az R600 320 ALU-jából használható maradt 80 (az NV például külön ezzel szopatta az AMD-t, hogy teleírta a fejlesztőknek leadott kódjait függőséggel). Tehát a teljesítménye jó részét elvesztette. Valószínű, hogy az egész co-issue-féle trükközés a sugárkövetés miatt tért vissza, mert oda eleve kell int32, és azokat az ALU-kan nem volt nagy meló megtoldani FP32-vel, még csak komoly tranzisztorköltség sem.

    Manapság egyébként a gyártók pont azért nem tudják jelentősen megszopatni egymást a fejlesztőknél, mert nem alkalmaznak semmilyen co-issue trükközést, de régen keményen szívatták egymást, hogy direkt limitre rakták az adott dizájn működését, és úgy elvették tőle a benne lévő teljesítmény jó részét. De ennek már majd 10-15 éve, azóta szerintem jó útra tértek, és biztos nem fogunk majd ilyen szopatást látni az AMD-től és az Inteltől. :D

    (#47755) b. : Szerintem félreérted, én régen nagy híve voltam ezeknek a megoldásoknak. :) Az R600-at pont emiatt tetszett nagyon, mert egy rakás ALU kapacitást raktak bele ilyen trükkökkel. Nyilván ezek a megoldások kikoptak, de újszerű GPU-kat kell tervezni az új igényeknek, és ha belegondolok, hogy int32 kell a sugárkövetésnek, akkor nagyon is jó ötlet azt kiegészíteni FP32-re is. Tranzisztorköltségben nagyon kicsi lábnyoma van, és ha a kódok 20%-a képes kihasználni, akkor már megérte. Emiatt írtam, hogy nem azt kell nézni, hogy maga az utilizáció kifejezetten alacsony lesz (ez jellegzetessége a trükkös dizájnoknak), hanem azt, hogy a trükközés nélküli állapothoz képest mennyi tranyót emésztett fel az extra teljesítmény kinyerése. Ilyen szempontból az R600-hoz hasonlóan bizonyosan előnye van az Ampere-nek is. Örülök is neki, hogy az NV ezeket a trükközési formákat hozza vissza.

    Az utolsó mondat egy poén, ezért van mögötte fejecske. :))

    [ 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