Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    TL;DR... jobb lesz. :D

    #4 tibaimp : Hát ha minden képességet nem is, de az erőforrások dinamikus bekötését a GCN2+, az RDNA összes, a Turing összes, az Ampere összes, illetve a gen9+ biztosan támogatja. De szerintem, amire van TIER_3-as binding, arra rá lehet emulálni.

    [ 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 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.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • 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.

    [ 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 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.

    [ Szerkesztve ]

    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