2. Fórumok
  3. Videokártyák
  4. Meghozta a mesh shadert a Vulkan új verziója
Keresés

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

  • #11 #88750080 törölt tag Abu85 #10
    Új Válasz #11
    Ú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

    #88750080

    törölt tag

    válasz Abu85 #10 üzenetére

    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.

  • #7 #88750080 törölt tag M0ng00se #6
    Új Válasz #7
    Ú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

    #88750080

    törölt tag

    válasz M0ng00se #6 üzenetére

    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.

  • #5 #88750080 törölt tag waterman_ #4
    Új Válasz #5
    Ú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

    #88750080

    törölt tag

    válasz waterman_ #4 üzenetére

    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.

  • #3 #88750080 törölt tag
    Új Válasz #3
    Ú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

    #88750080

    törölt tag

    Kösz, hogy megkímélsz tőle, épp kérni akartam.

  • #1 #88750080 törölt tag
    Új Válasz #1
    Ú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

    #88750080

    törölt tag

    Magyarra lefordítva, végre linuxra is le lehet koppincsolni ("portolás") a DX12 ezen részét, kb. ennyi értelme van annak az egész API-nak.

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

Hirdetés