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

• #49862 Abu85 HÁZIGAZDA

  Új Válasz 2025-10-03 10:11:18 #49862

  Ú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

  Annyit hozzátennék, hogy az egyes gyártók között az egységes API-k mellett is nagyon eltérő a Vulkan és a DirectX 12 implementációja. Sőt, az AMD-nél nincs is külön implementáció, egy közös PAL rétegen keresztül kezelik mindkét API-t, és csak a különbségeket menedzselik az ICD réteggel.

  A lényeg az, hogy részben hardveres sajátosságok miatt más az egyes erőforrások kezelésének és menedzselésének menete, ami nagyon röviden így néz ki:

  Az NVIDIA még az explicit API-knál is erőteljesen épít egy úgynevezett push bufferre, ami azt a célt szolgálja, hogy a lehető legtöbb metaadattal lássák el a hardvert, miközben ritkítják a futószalagok kiürítésének számát. Ennek az ára a nagy memóriaigénye, illetve a CPU oldalán több munkára van szükség, hogy a driver push bufferét megfelelően menedzseljék. A bekötés tekintetében pedig az NVIDIA előre gyorsítótárazza a leírótáblát, és utána ezt csak szükség esetén módosítja. Ez megint több memóriát és CPU-időt eszik, viszont az állapotváltások minimalizálhatók, amire eleve haknis az a fajta működés, ahogy az NV drivere feldolgozza az adatokat.

  Az Intel sok tekintetben épít a CPU-ra. Amit csak tud a CPU állít össze, és a GPU-nak elég csak beolvasnia. Nagyon sok munkát megspórol így maga a GPU, mert kész futtatandó assemblyket kap a CPU-tól. De mivel ez így működik, nehéz batch-elni, és egy rakás dekódolási munkával jár már a CPU oldalán, hogy a GPU dekódolási munkája megelőzhető legyen, ami nagyobb többletterhelést ad.

  Az AMD épít a legkevésbé a CPU-ra, mert maga a PAL úgynevezett leírócsomagokat dolgoz fel. Ez nincs külön kezelve az API-kban, de maga a Mantle eleve olyan jellegű feldolgozással készült, amilyen jellegű nagyvonalakban a DirectX 12 és a Vulkan, és emiatt a két szabványos API-ba is beletervezték az egyes erőforrások feloszthatóságát. Mondhatni ez egy Mantle örökség, amit a Microsoft nem vett ki a prototípus kódból, és a Khronos is továbbvitt, hogy a hardver számára optimalizálható legyen a valós feldolgozás, miközben az API maga a finom részleteket elmaszkolja. Az AMD drivere tehát majdnem mindent ilyen leírócsomagokban kezel, és ezek a csomagok elképesztően picik, miközben teljesen függetlenek egymástól, tehát nem számít, hogy esetleg két csomag nagyobb műveletet bont meg, azokat a hardver össze tudja rakni belül, ha a két csomag megérkezik számára. A drivernek csak azt kell menedzselnie, hogy a két csomag egymás után fusson be. Mivel így minden munkamenet nagyon picire van szabva, a processzoridő is elég kevés lesz velük. Ráaádsul a sok eltérő csomag miatt nagyon párhuzamosítható az egész, szépen lehet osztani a munkát 4-5-20-30 magra. Utóbbi a kulcs az AMD-nél, mert nem azért olyan hatékony a drivere, mert valami elképesztően szűkre van szabva a munka. Ők is használják a CPU-t rendesen, csak nagyon párhuzamosítva, hogy a kis csomagok feldolgozása jól menedzselhető legyen, jól be lehessen illeszteni ezeket a meglévő magok szabad kapacitására.

  A fenti különbség felel azért, amit láthatunk a tesztekben, ha gyengébb CPU mellé kerülnek a hardverek. Például egy tipikus hatmagos CPU egyik nagy hátránya az, hogy mindenképpen lesz egy-két mag, ami jobban lesz terhelve. Ez nagyon tipikus a többszálú feldolgozáskor. És a program terehelése mellett még az NV és az Intel drivere is főleg egy-két magot terhel, mert nagyobb munkákat csinálnak meg. Az AMD előnye itt onnan ered, hogy a driverük nem terhel be nagyon egy-két magot, hanem szépen szétosztja a munkát az összes mag között. És ezért lehet látni azt például a HUB overhead tesztjeiben is, hogy mennyivel jobban bánik a CPU-idővel, mert gyengébb CPU-val sem jön erőteljesebb CPU-limit.

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