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

  • Abu85

    HÁZIGAZDA

    válasz Jack@l #17466 üzenetére

    Annyira egyszerűen képzelitek el ezt, de megközelítőleg sem az. A 32 bites ALU ugyan tudna 8 bites operációt futtatni, de odaveszne a teljesítmény, mert csak egyet támogatna. Ha azt akarjátok, hogy négy 8 bites operáció legyen elvégezve egy 32 bites részelemen, akkor ahhoz packing stratégiát kell alkalmazni. Na most a DXR egyszerűen nem támogat packinget, jelenleg csak 16 és 32 bites lebegőpontos formátumot kezel, és tudjuk jól, hogy a 16 bites formátum a vertex pozíciókhoz nem elég jó, pláne nem sugárkövetésre. A többi DirectX 12-ben találhat formátumot a DXR egyszerűen nem kezeli, nincs benne definiálva. Egyedül a Microsoft layere engedi meg a 10 bites minfloatot denoisingra, de azzal meg sokra nem megyünk, mert nincs olyan hardver, ami támogatja, emellett denoisingra sokkal kedvezőbb inkább drivert írni, és akkor akár le lehet menni 4 bit integerig is, ráadásul megkerülhető a default layer packing limitációja is.

    Egyébként a hardverek sok mindent csinálhatnának, de a DXR első körben nagyon limitált lesz, főleg azért, hogy kevés legyen vele a munka a gyártói oldalon. Nagy fejlesztői támogatása nem lesz, mert aki DXR-t rak a játékába, az nem tudja futtatni a programot a mostani Windows környezetben. A rendszer minimum igény lesz az októberi frissítéssel felvértezett Windows 10. Alatta nem jut túl az inicializáláson a program. A Vulkan lenne jó, mert az nem kötné a vásárlókat a legújabb Windows 10 verzióhoz, de ott meg a Khronos annyira nem erőlteti ezt, túl kiforratlannak tartják még. A GPUOpen-féle Vulkanos sugárkövetés pedig ugye egy API felett elhelyezkedő réteg, annak semmi speciális igénye nincs, viszont nem is a grafikus API része.

    [ 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