Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz namaste #24208 üzenetére

    Bocs, de ez megint nem ilyen egyszerű. A TFLOPS és a blending teljesítmény igazából csak architektúrán belül lényeges. Elsődlegesen azért, mert az AMD és az NV ma már eléggé hibrid architektúrákat tervez. Nem igazán IMR-ek, de nem is igazán TBR-ek. Valahol a kettő között vannak, de az gyártótól függ, hogy mennyire húznak az egyik irány felé. Az NV a Maxwell óta inkább a TBR felé húz, ami miatt jóval aktívabban használnak mozaikos optimalizálást, mint az inkább IMR felé húzó AMD GCN. Ennek a hátránya, hogy jóval nagyobb blending teljesítményt igényel, viszont kisebb terhelés a memória-sávszélesség felé. Az AMD ennek pont az ellentéte. Nem igényel nagy blending teljesítményt, de nagyon igényli a memória-sávszélességet. Tehát már az eltérő architektúrák miatt is lényegtelen a direkt ROP és sávszél összehasonlítása, mert az NV-nek sok ROP kell, de kevés sávszél, míg az AMD-nek kevés ROP, de sok sávszél. Persze ezt relatív összehasonlításban kell érteni. A TFLOPS pedig azért erősen elméleti, mert a DX12 alatt is D3BC-n keresztül működnek a rendszerek, amely IR-t a 2000-es évek elején befutott architektúrákra húztak fel. Ma már egyáltalán nem úgy működnek a hardverek, hogy a D3BC jól mappelhető legyen rájuk. Ezért hoz a Microsoft a shader model 6.0-ban egy új IR-t, ami a DXIL. Microsofttól elszakadva ugyanezért hozott a Khronos is egy SPIR-V-t. Szóval az elméleti TFLOPS az tök jó, de nincs olyan PC-s hardver, ami nem SIMT modellt használna és ezáltal ne függene a teljesítmény a regiszterhasználattól, hiszen minél erősebb terhelés éri a regisztereket, annál kevesebb wavefront-warp/akármiwave futhat párhuzamosan, és annál rosszabb lesz a rendszer kihasználása. Ugye erre reakció részben a GCN4 utasítás-előbetöltése. A DXIL-en és a shader model 6.0-n már lehet látni, hogy a SIMT modell felé lépdel, hiszen mindegyik hardver ilyen már. Ettől nőni fog a hardver kihasználhatósága is, mindegyik hardveré.

    A DirectX 12 több szintre bontja a bekötési rendszer. Van a TIER_3, aminél az erőforrás direkten a multiprocesszorba kerül bekötésre. Ez az alapvető modell, és ennek vannak butított szintjei. A TIER_2 szint a mintavételezőbe engedi bekötni az erőforrást, és driverrutinra van szükség ahhoz, hogy az onnan átkerüljön a multiprocesszorra. Na most ez a driverrutin processzoridőt igényel. A TIER_1 szint esetében maga a bekötés úgy zajlik, hogy a host processzor végzi a teljes munkafolyamatot, és köti be az erőforrást a multiprocesszorba.
    Abból egyébként nincs semmi gond, hogy minden cég hardvere ideálisan működik a maga módján, és ha nem lenne az API, akkor ezek abszolút tökéletesek lennének, de az API létezik, és ebben vannak bizonyos szabályok, amelyeket követni kell az adott implementációnak. Szóval az NV-nek azért van szüksége arra a processzoridőt használó driverrutinra, mert abban a fránya DX12 API-ban megkövetelte a Microsoft, ugyanis a pure bindless modellre építették fel a bekötést, és a rosszabb modelleket ehhez igazították hozzá, ami áldozatokkal járt, hogy ez a három szint egyáltalán kompatibilis legyen egymással. Ez teljes mértékben egy szoftveres döntés volt, gondolva arra, hogy a DX12 itt lesz 2020-ban is, amikor már minden hardver pure bindless lesz. De egyébként dönthettek volna úgy is, hogy a DX12 bekötési modelljét arra húzzák fel, hogy elég a mintavételezőbe bekötni az erőforrást, és akkor az az NV-nek lett volna jó, de a jövő szempontjából nem ez tűnt a legjobb döntésnek.

    Persze, hogy nincsenek kötelező szabályok. Az MS csak azért ajánlja, amit ajánl, mert így működik az API gyorsan. Lásd Rise of the Tomb Raider, ahol nem követték az MS ajánlásait. Azóta mindenki ezeket követi, mert látványosan nem működik akkor a DX12, ha kifejezetten nem ajánlott RS modellt követnek a fejlesztők. Függetlenül attól, hogy az NV ajánlja ezt vagy nem.

    [ 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