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

• #154 Abu85 HÁZIGAZDA namaste #152

  Új Válasz 2018-05-21 11:21:07 #154

  Ú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 namaste #152 üzenetére

  CPU-n fut a binding API.

  Oda tölti be az adatot. Ez egy igen speciális módszer, amit az NV kitalált a Keplernél. Alapvetően működik, mert a SRV-ket és a samplereket a binding API nélkül is be tudja tölteni a mintavételezőbe. Azt senki sem állította, hogy elegáns módszer, de megcsinálja, amire kitalálták. Nagyon sokat egyébként nem lehet tenni egy slotalapú architektúránál, annyira mélyen kellene belenyúlni a dizájnba, hogy leginkább trükközéssel lehet menni a pure bindless felé. Az AMD-nek csak azért egyszerű a dolga, mert ők amikor a nullához közeli állapotról tervezték a GCN-t, akkor eldöntötték, hogy memóriaalapú lesz, így pedig nagyon kedvező a pure bindless dizájn megvalósítása. Kell egy skalár ALU a CU-ba, ami megoldja a feladatot. Ha már kész az architektúrád, akkor rengeteg korábban meghozott döntést szükségszerűen hordozni kell a következő dizájnra is, amíg nem váltod le az egészet.

  Az NV váltott implementációt. A problémájuk az, hogy hiába hozott a Microsoft nekik egy külön bekötési szintet a DX12-ben, akkor is hátrányban vannak az Intelhez és az AMD-hez képest a feature szempontjából. De a Microsoft nem törődik igazából az API alatt meghúzódó részletekkel, tehát érdektelen számukra, hogy egy TIER szint támogatását a gyártó hogyan éri el. Ezért az NV is átállt egy pure bindless megvalósításra. Ehhez alkalmaznak egy extra réteget az API alatt, ami gyakorlatilag elrejti a hardver képességeit, és megfelelő támogatást ad az API felé, miközben a különbségeket kezeli a hardver felé. Gyakorlatilag emuláció. Ezt nem kizárt, hogy az NV kérte, mert a Microsoft még az utolsó pillanatban is változtatott annyit a binding modellen, hogy egyszerűbbek legyenek a szoftveres trükkök.
  A regiszterhasználat az NV szerint attól függ, hogy a program mit csinál. A legrosszabb eshetőség, ha divergens módon dinamikusan indexeli az erőforrás-leírót. Ebben az esetben maximum 16 darab 32 bites regiszter a terhelés aktív warponként. Ez a worst case. De maga shader fordító fel van már készítve rá. Ha ilyen terhelést fejthet ki egy shader, akkor limitálja az aktív warpok számát. A Volta esetében az összevont L1 gyorsítótárban is lesznek trükkök erre a működésre.

  [ Szerkesztve ]

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

• #156 Abu85 HÁZIGAZDA namaste #155

  Új Válasz 2018-05-23 09:51:15 #156

  Ú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 namaste #155 üzenetére

  A DX12-ben binding API biztosítja az erőforrások bekötését, ha erre a hardver nem képes önmaga. Gyakorlatilag a meghajtóba írható erre egy implementáció, ami elhelyezi az erőforrás-leírókat egy tömbbe. Amikor a warp vagy wavefront, illetve általános nevén a wave futni kezd, akkor ezt a tömböt fogja igényelni elsőként, amit már a CPU-n futó binding API előkészített olyan formába, hogy a GPU megfelelően működhessen. Az adatok elérése innentől kezdve pufferbetöltés vagy textúra mintavételezéssel valósítható meg. Attól függ, hogy szűrt vagy nem szűrt minta kell.

  Attól, hogy egy textúrázótól elvárható ez, még meg kell neki mondani, hogy hol vannak. Gyakorlatilag az erőforrás-leírók kvázi pointerek. Ehhez kell a binding API. Hacsak a hardver nem képes arra, hogy az esetlegesen shaderekbe programozott memóriaeléréseket értelmezze. Erre van a Tier2 és a Tier3 szint. Előbbi esetben az SRV-ket és a samplereket be lehet tölteni a binding API nélkül, mert le lehet programozni a memóriaelérést a shaderben. Utóbbi esetben pedig ez minden erőforrásra leprogramozható.

  Az NV erre nem tért ki. Ők csak felvázolták, hogy ez a worst case. Ha egy shader így működik, akkor az nagyon fel tudja zabálni a regisztert. De állítólag ez még így is előnyös, mert a legtöbb esetben az újabb meghajtókba épített emulációnak pozitív hozadéka van. Csak néhány eset az, ahol hátrányos. Valószínűleg arra számítanak, hogy a fejlesztők nem hülyék, és mérlegelik ezeknek az eseteknek a használatát. Nem mondták meg, hogy mit tárolnak. Forrást nem tudok adni, ez egy telefonkonferencia volt, nem tudom, hogy felvették-e.

  [ 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