- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
- AMD GPU-k jövője - amit tudni vélünk
- Kezdő fotósok digitális fényképei
- Milyen monitort vegyek?
- Nvidia GPU-k jövője - amit tudni vélünk
- ZIDOO médialejátszók
- Lenovo Legion és IdeaPad Y széria
- AMD Navi Radeon™ RX 6xxx sorozat
- Házimozi belépő szinten
- Intel Core i3 / i5 / i7 4xxx "Haswell" és "Haswell Refresh / Devil's Canyon" (LGA1150)
- AMD FX
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Én úgy vettem észre, hogy viszonylag gyorsan megvan, bár ez nyilván függ az adott gyártó shader fordítójának sebességétől. Viszont ez okkal van így. DX11-ben ez nincs, helyette random lagok vannak. Ezért használnak inkább DX12-t a játékhoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#88750080
#11
üzenetére
Amely shader cache csak akkor hasznosul, ha már egyszer megtörtént a fordítás, és cache-selve lett az eredmény, amit majd később le lehet hívni. Tehát először mindenképpen akadást fog okozni.
Az a trükk, amit leírtál addig működik, amíg az egyik gyártó nem jön a meghajtójával, ami megakadályozza azokat a rajzolásokat, amiket erre a trükkre használ a fejlesztők. És jellemző, hogy jönnek ezek a meghajtók, mert jobb eredményeket lehet velük kihozni egy gyors benchmark alatt. Aztán, hogy hosszabb távon szopás? Hát, a hardvereket 5 perces programfuttatások alatt mért eredmények adják el, addig kell csúcssebességet elérni.
DirectX 12-ben sem tökéletesek erre a megoldások. Nyilván nem egy kedvező dolog, hogy xy DX12-es játék előre lefordít mindent, ami gyakorlatilag driverfrissítésenként 10-15 perces kávézás. Van már erre is terv, hiszen valaki lefordítja az adott hardver és szoftverkombinációra, amit a driver megfoghat, és feltölthet egy szerverre, és a játékok akár onnan is leszedhetnék a kódot. Az kérdés, hogy ki mikor élesít egy ilyen megoldást publikusra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#88750080
törölt tag
Nem kételkedem abban, amit mondasz, bár a fejlesztők problémáját nem igazán értem.
A "random" shaderfordítás dx11-ben kb. azt jelenti, hogy a DXBC shaderkódból a driver "valahol" saját GPU-kódot fordít, jellemzően akkor, amikor a háttérszálon az aktuális Draw-híváshoz összerakja a teljes pipeline-t. Ez nagy shadereknél időigényes lehet, akadozásokat okozhat, de pont ezért létezik idétlen idők óta a shader cache. Még a fordítás előtt lehet a pipeline-ból egy hash-t számolni, és ha megvan valahol a cache-ben, akkor további teendő nincs is, csak fel kell használni. Ezt közvetlenül valóban nem tudja befolyásolni az API-t hajtó játék, ellentétben a dx12-vel, ahol neki kell átvennie a driver szerepét, és kézzel összerakni mindent. Ellenben ha nagyon kell, dx11-ben is ki lehet kényszeríteni a korai fordítást, induláskor az összes lehetséges általunk használt pipeline-verzióval rajzolunk valami kamu dolgot egy képernyőn kívüli területre, és onnan kezdve azok be is kerülnek a külső és belső cache-be. A dx9-es ATI demók pl. mind ezt csinálják, induláskor egy külön bitkolbász jelzi, hogy holt tart a "Warming caches" folyamat.
(zárójelben: egyébként ez a dx11-es probléma talán dx12-ben is megvan, mert a gyors fordítás érdekében a driver tud egy optimalizálatlan shader verziót fordítani, a végleges legyártását pedig kiszervezi egy háttérszálra, majd suttyomban kicseréli arra, ha végzett vele. Ezt kb. csak letiltani lehet vmi flaggel inicializáláskor, és ezt is csak arra találták ki, hogy ha valaki pontos performance-méréseket akar végezni, akkor ez ne zavarjon be)A shaderfordításos probléma inkább ott szokott jelentkezni, amikor egy játék menet közben fordítgat HLSL-ből DXBC-re (az amúgy is lassabb mint kódról kódra), mert olyan temérdek variánst képes használni, de ennek nincs köze az API-hoz. A Gothic 3 volt ilyen, lépten-nyomon akadozott szó szerint minden fűszálnál. Na ezekre tényleg nem marad nagyon más megoldás, mint első induláskor 5 perces malmozás keretében előre lefordítani az összeset, és egy lokális fájl-cache-ben eltárolni őket.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Igen. Pont azért jött ki rá a patch, mert a DirectX 11-es módot nem akarták minden kódváltoztatásnál újraprofilozni a gyártók, így végül DirectX 12-re áttért a stúdió, csak ez a leképező később lett elérhető. Ezzel megoldást találtak arra a DirectX 11-es problémára, amit a régi API-val nem tudtak kezelni, mert nem befolyásolhatták a futószalagkreálást. Egyszerűen együtt kellett élni a random shader újrafordításokkal, amit szarnak tekintettek, mert túl sokszor történt meg. Ha játszod, és kipróbáltad a játékot DirectX 12 módban, akkor tapasztalhattad, hogy az első indítás sokkal tovább tart. Ez azért van, mert előre lefordítják a shadereket, hogy runtime fordításra ne is legyen szükség, ezáltal meg tudják javítani a DirectX 11-es leképező számukra kezelhetetlen gondját. Amúgy az Elex 2-nek nem kellene DirectX 12, de nyilván jó oka volt rá a fejlesztőknek áttérni, mert nem tudtak mit kezdeni a sok rendszertelen shader fordítással a régi API-n. Persze elfogadhatták volna, hogy ez van, ezt kell szeretni, de kerestek rá megoldást, és ez szerintem dicsérendő.
Teljesen jó a BF5 DX12 módja. Csak abban játszom. Egyszerűen gyorsabb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#88750080
törölt tag
Nem vagyok nagy gémer, de azt gondolnám, igen (Hitman pl). A "béta" módú dx12 az kb. az API megjelenése utáni időkben volt jellemző, amikor a meglevő dx11-es kód alapján rittyentettek gyorsan egy dx12 path-t, nem törődve a két API implicit/explicit jellegéből adódó performanszbeli különbségekkel. Nem is emlékszem már, melyik játék (talán pont a Shadow of the Tomb Raider) fejlesztése kapcsán olvastam valahol, de ott pl. a dx12-es ágat "meghagyták" egyszálasnak (a dx11 alapján), amiből önmagában következik, hogy egy NV/AMD dx11 implementációnál csakis lassabb lehet, mert ők az API-hívások "backend tartalmát" háttérszálra szervezik ki (de pl. az Intel régi drivere nem). Ez tipikusan az a dx12-es megoldás, aminek értelmes ember neki sem állna, de gondolom, minél hamarabb virítani kellett vmivel a nagyvilág felé.
Mivel manapság a játékfejlesztés kb. a meglevő nagy motorok vmelyikére történő kontentpakolást jelent, gondolom, mostanra már konszolidálódott a helyzet, mert azokban az engine-ekben azóta kikalapálták a normál háttér- vagy többszálas API-meghajtást.
[ Szerkesztve ]
-
#88750080
törölt tag
Oké, ezeket értem, hull shader, tesselator, domain shader, meshletek, stb...
Pont erre mondom, hogy ha ezek vagy ezek ekvivalensei nincsenek meg a vulkánban, akkor nem lehet linuxra koppincsolni a dx12-t teljes mértékben.
Szerintem a stream-output is csak azért került bele szabványosított módon, hogy a dx11-et teljes mértékben lehessen "implementálni" linuxon, addig kb. a kutyának sem hiányzott.[ Szerkesztve ]
-
waterman_
aktív tag
eddig is létezett a mesh shader, de nvidia írta az első verziót ( VK_NV_mesh_shader ), ami rosszul teljesített minden más gyártó hardware-én. most összehoztak egy megvalósítást ami kb minden gyártónál használhatóan fut, tehát mostmár a vulkan api része lehet, ami nem gyártó specifikus, a neve is más lett ennek ( VK_EXT_mesh_shader )
ezen kívül nem csak az a különbség hogy DX12 api-t portolhatnak linuxra, hanem a teljes grafikai pipeline kapott egy update-et. csak pár dolog ami extra teljesítményt adhat: meshletenkénti culling, a fixfunkciós tesselatorok helyet programozható funkciók. meshletenként lehet compute szerű shadereket is indítani.
Egy leírás a mesh shaderről - [link]..egy sikátorba talátak rám, egy régi frigóba próbátam viszatérni a főd légkörébe..
(aztán erre is jött ki dx12 patch)
(Bővebben nem fejtem, ki nem biztos, hogy felfognád.)Új hozzászólás Aktív témák
Hirdetés
ph A friss kiterjesztés rendkívül hasonlít a DirectX 12 működéséhez, ami megkönnyíti majd a portolást a két API között.
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest