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

• #30459 Abu85 HÁZIGAZDA namaste #30457

  Új Válasz 2017-09-20 09:48:58 #30459

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

  Nem az a lényeg, hanem az, hogy az a zöld paca egy kihasználhatatlan CPU idő. Láthattad, hogy ahogy átléptek deferred contextre egy picit javult a sebességük (azt is elmondták, hogy sokan veszítenek egy ilyen lépéstől), de még mindig használhatatlan volt a CPU jelentős része. Amint pedig átléptek explicit API-ra elkezdett a programjuk működni. Magát a gondolatmenetet a demós rész után folytatják itt. [link]

  Nem az számít, hogy van-e dedikált cache a hardverben. Az NV korábban többször hangsúlyozta az előadásain (főleg a gyorsabb DX12-es meghajtót bemutatón), hogy óriási különbség van aközött, hogy a hardver mire képes és az API mit enged meg. Például a D3D12-nek a kötött implementációja nem engedi meg, hogy egy compute shader közvetlenül a konstans pufferbe írjon, ezért a fejlesztőknek erre strukturált puffert kell használni. Ugyanakkor a GeForce-on csak a konstans pufferre van fast path, míg egy strukturált pufferre nem, tehát ennek az írása és olvasása lassabb. Például a Hitmanre van egy külön kidolgozott meghajtórutin a 384.76-os drivertől kezdve, amely a strukturált puffer tartalmát mindig átmásolja egy fast pathot lehetővé tevő pufferbe, és azzal dolgozik a hardver (persze ezt csak a Hitmanre tudják használni, mert feltételei vannak ennek meghajtó oldali trükknek, de ennél a játéknál tényleg használ). Ezzel egyébként az a gond, hogy egy ilyen optimalizálást akkor lehet használni, ha a játékot alapját képző leképezőt már nem fogják frissíteni, illetve a kidolgozása is hónapokat vett igénybe. Az NV is mondta, hogy kockázatos a módszer, mert ha jön egy leképezőbe nyúló patch, akkor onnantól kezdve lőttek a Hitman futtatásának, amíg nem veszik ki a meghajtóból a gyorsulást biztosító trükköt.

  Az tök jó, hogy van driver csak az a baj, hogy a Microsoft az implementáció egy kis részét maga oldja meg. Egyfajta univerzális meghajtót ír, és azt kell használnia mindenkinek. Igazából nem sok indoka van annak sem, hogy a compute shader közvetlenül ne írhasson a konstans pufferbe. Ez a limitáció a Qualcomm és az ARM miatt lett meghúzva, de az Intel, az NV és az AMD is támogatná ezt a lehetőséget, ha meglenne. Viszont így, hogy nincs meg, azok a hardverek hátrányt szenvednek a DX11-hez képest, amelyek meghajtója kifejezetten épített arra, hogy a hardver gyorsabban tud olvasni a konstans pufferből, mint egy strukturáltból. A GCN-nek és az Intel cuccainak ez amúgy nem számít, mindegyik pufferből ugyanolyan gyorsan olvasnak.

  Az NV-nek egyébként a vertex fetch-re és a statikus bindingre van még fast path-ja. Előbbi nem számít, mert a hiánya elég kevés veszteséget okoz, míg utóbbi még nem számít, mert a hiányát akkor fogja megérezni a hardver, amikor bindless bekötést használ a program.

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