Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A dolog ennél bonyolultabb. Valójában a problémát a DirectX 12 jeleneti az alkalmazáson belül. A Borderlands 3 a Microsoft ajánlásait követi a DirectX 12-re, ami azt jelenti, hogy az erőforrásokat a leíróhalmazba rakják. Ez az AMD-nek és az Intelnek jó, de az NVIDIA hardvereinek, köztük még az Ampere-nek is nem ideális. A GeForce-okhoz az az ajánlott, hogy az erőforrások a root signature-be kerüljenek.
Ezt az ajánlást némelyik program teljesíti, némelyik nem. A helyzet nem olyan egyszerű, mert a root signature-t nem buffer viewekre találták ki. Ha ide helyeznek erőforrást, akkor számos formátum nem is támogatott. Ilyenkor a leíróhalmazok alkalmazása elkerülhetetlen, és ezzel az NVIDIA hardverei teljesítményt veszítenek. Ezért van az, hogy az AMD minden DirectX 11-ről DirectX 12-re váltásnál előnyt kap, míg az NVIDIA esetében vagy előnyös ez a váltás, vagy hátrányos. Attól függ a pozitív vagy negatív irány, hogy a buffer viewek a root signature-ben vagy leíróhalmazokban vannak.
Ha lehet a fejlesztők beleerőszakolják ezeket a root signature-be, mert az AMD és az Intel hardverei ilyen működés mellett is jól érzik magukat, a GeForce-ok pedig csak így működnek optimálisan, de mivel ez egy nem ajánlott működési mód, a Microsoft nem készítette fel minden formátum támogatására, így sokszor nincs választásuk a fejlesztőknek, és muszáj leíróhalmazt használni, azt pedig a GeForce-ok annyira nem szeretik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A bonyolultat arra írtam, hogy az AMD-nél miért lesz mindig pozitív hatása a DirectX 12-re való váltásnak, míg az NV-nél miért lesz néha negatív. Egyszerűen az AMD DirectX 12 implementációja és hardveres sok mindent megeszik, míg az NV DirectX 12 implementációja és hardvere kicsit finnyás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD-ben lesz dedikált RT részegység. [link] - itt leírtam, hogy mi lesz a két implementáció között a különbség.
(#65) Malibutomi: Nem az Int32 a lényeg. Abból viszonylag kevés van egy programban. A legnagyobb gond a függőség, mivel mindkét feldolgozótömb ugyanazt az ütemezőt használja. A SIMT dizájnoknál a függőség korábban azért nem volt gond, mert feldolgozótömbönként egy külön volt, tehát egymástól függő wave-ek ugyan kerültek az ütemezőre, de ezeket sosem lehetett párhuzamosan futtatni két feldolgozótömb hiányában. Az Ampere egy ütemezőre két FP32-es feldolgozótömböt rak, és ott már lényeges, hogy két wave csak akkor futhat egymás mellett, ha nem függnek egymástól. Ez sokkal sűrűbben jelent problémát, mint az, hogy van Int32-es feladat.
Egyébként erre lehet optimalizálni, a probléma az, hogy piszok nehéz, és alapvetően sok haszna sincs a befektetett humánerőforrásnak, mert ha egy operáció függ a másiktól, akkor azt sosem lehet majd egymással párhuzamosan futtatni.
Az Ampere-re majd kell külön optimalizálni, mert amíg a két konzol kifejezetten azokat a shadereket szereti, amelyek az adatlokalitásra vannak optimalizálva, addig az Ampere ezt kifejezetten utálja. És ez egy lényegesebb kérdés, mint 16+16 co-issue módra gyúrni, mert sokkal többet vesztesz a rossz statikus erőforrás-allokációval, mint azzal, hogy nem működik a második FP32-es feldolgozótömb.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#78
Abu85
HÁZIGAZDA
Malibutomi
#76
Abu85
HÁZIGAZDA
válasz
Malibutomi
#76
üzenetére
Ez azért nem ilyen egyszerű. Az UE4-et a Vulkan implementálása óta Radeonon fejlesztik, tehát alapvetően az újabb motorverziók már eléggé szeretik az AMD-t. A régi motorverziók voltak kedvezőek az NV-nek.
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
ph A vállalat három játékból mutatott teljesítményadatot, de sokat ezekkel nem lehet kezdeni, mivel fontos részletek nem ismertek.