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

• #36054 Abu85 HÁZIGAZDA huskydog17 #36050

  Új Válasz 2018-07-04 10:36:25 #36054

  Ú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 huskydog17 #36050 üzenetére

  A szeretetcsomagot a Vulkan miatt kapták. Ezzel az API-val RenderDoc nélkül nem nagyon tudsz elboldogulni, és a RenderDoc ma már eléggé hozzá van kötve az RGP-hez, ami viszont megköveteli a Radeont (Fiji vagy újabb). Másképp a debug-profilozásra vonatkozó interoperabilitás, mint idei húzófícsőr nem működik. Az egyébként tervben van, hogy a jövőben biztosítanak más profilozónak is interoperabilitást, de ahhoz előbb nyílt forráskódúvá kell tenni az adott profilozót.
  Az Intel GPA esetében szó van erről, de még csak most alakították át a szoftveres részleget, és nemrég döntöttek arról, hogy egyre több dolgot tesznek nyílt forráskódúvá. Időbe fog telni, amíg erre átállnak. Mindenesetre nagyon jó a Vulkan driverük, tehát van keresnivalójuk ezen a területen. Amikor kész lesz a saját pGPU-juk, akkor már fejlesztőeszközökben is elérhetik azt a szintet, amit az AMD ad. Addig pedig a Kaby Lake-G-vel úgyis profitálnak mindenből, amit az AMD csinál. Ügyes volt aki ezt kitalálta.

  Ahogy írtam az RPM az már nem egy zárt megoldás. Természetesen az AMD-nek működnek még az erre vonatkozó kiterjesztései, de ezt maximum akkor érdemes használni, ha kell DX11-es portot szállítani. Az ugyanis szabványosan semmiképpen sem megoldható, csak az AMD kiterjesztéseivel. DX12-től kezdve viszont ezekre nincs szüksége egy fejlesztőnek, egyszerűen ott van benne a shader modell 6.2-ben a szükséges tudás, ahogy a Vulkan 1.1 is támogatja. Hardveres szempontból pedig lényegesen jobb a szabványos megoldás, mert az AMD zárt konstrukciója ma már csak Vegán működik, míg a szabványos GCN3/GCN4/GCN5-ön és Intelnél a Gen8-től felfelé, valamint működni fog a következő generációs NV-n is. És nem kevés sebesség van ezekben a packing optimalizálásokban. Egyes eljárásokat a duplájára lehet velük gyorsítani. De még a rosszabbik struktúrával is 2/3-dal gyorsabb lesz a számítás. És ami még kedvező, hogy automatikusan kezeli a regiszter/LDS pressure problémát, amitől egyébként a Croteam és a FWH is rohadtul szenved egy ideje, mert szoftveresen az übershaderekre épülő programozási módszerekkel nem lehet velük mit kezdeni. Egyszerűen a statikus erőforrás-allokáció marhára pazarló. Akkor is be kell foglalni az erőforrást, ha alig fogod használni, és amíg a shader fut, addig nem szabadítható fel, függetlenül attól, hogy a programozó tudja, hogy marhára feleslegesen van befoglalva.

  [ 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