Hirdetés

  2. Fórumok
  3. Egyéb hardverek
  4. Nagyon komoly újításokat hoz a shader modell 6.6
Keresés

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

  • #18 Abu85 HÁZIGAZDA dabadab #17
    Új Válasz #18
    Ú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 dabadab #17 üzenetére

    A mai GPU-kban statikus erőforrás-allokáció van, vagyis a regiszterek és az LDS tekintetében a shader fordító egyszerűen betöltet mindent. Ez a program oldaláról csak annyiban kontrollálható, hogy a regiszternyomást mennyire optimalizálják, de ennél direktebben ebbe nem tudnak beleszólni, nem elég okosak hozzá a mai hardverek.

    Nem tudtam, hogy a Microsoft az senki. Köszi a felvilágosítást. :C

    "min16float"
    Az újabb HLSL verziókban már jól működik.
    A régebbi nyelv, a 2019-es HLSL verzió előtt, amit még az FXC-hez terveztek ugyan kellettek trükkök, hogy ne 32 bites legyen az alignmentálás, de elég egyszerűen megoldható volt.
    Kellett egy CPU-oldali kód, ami uintbe csomagolta a konstans és pufferadatokat, és ezek kezelhetővé váltak a GPU oldalán két sor kód beírása után. Másképp ugye aligha futott volna például a TressFX a játékokban, hiszen az exkluzívan packed mathot használt FP16-ra.
    Ma már ezek nem kellenek, a Microsoft megoldotta ennek a támogatását trükkök nélkül is.

  • #15 Abu85 HÁZIGAZDA dabadab #14
    Új Válasz #15
    Ú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 dabadab #14 üzenetére

    Hát mik tárolják? Pufferben vagy textúrában vannak. Mindkettő erőforrás.

    Packed math eddig FP16-ra volt. Int8 natív vagy mixed módban volt, de nem packedben.

    Hát miről? Béláról?

    Te tudod? :))Én azért jó négy oldalt írtam erről korábban. [link] - ettől az oldaltól kezdve.

    Maga a meghatározás azért fontos, mert a modernebb hardverek, mint az RDNA, már nem csak egy wave-méretet támogatnak hatékonyan, hanem kettőt is. Arról a shader fordító dönt, hogy egy shadert hogyan fordít le. Viszont a shader model 6.6-től kezdve a fejlesztő megmondhatja, hogy a shader fordító 32 vagy 64 lane-es wave-et használjon az RDNA-n például. Más hardveren ennek sok értelme nincs, mivel a min és a max wave-méret megegyezik, de nyilván ez egy jövőnek szánt funkció, egyre több hardver lesz olyan, mint az RDNA, így hosszabb távon a multiprocesszorok többféle wave-mérettel is hatékonyan tudnak majd működni.

  • #13 Abu85 HÁZIGAZDA dabadab #11
    Új Válasz #13
    Ú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 dabadab #11 üzenetére

    A szintűt kivettem, ha ennyire zavar.

    A lebegőpontos értékeket erőforrásokban tárolják.

    Senki sem írta, hogy a packed math új.

    Pont az a lényege, hogy ezt megadd, mert amúgy a meghajtó fordítójának szabad keze van benne.

    Vagyis egy paraméter legyen meghatározva, hiszen egyetlen egy wave-méret jó a shadernek. ;) Ha több is jó, akkor felesleges attribútumról van szó, hiszen a fordító jobban tudja, hogy mi a jó a hardvernek.

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