Hirdetés

  2. Fórumok
  3. Videokártyák
  4. Jön a Variable Rate Shadinget elemző 3DMark teszt
Keresés

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

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

    Persze. Csak a probléma az FP16-tal, hogy az valójában nem FP16, hanem packing. Tehát ahhoz, hogy használd, kompatibilis kódot kell írni, amibe ugye becsomagolsz két operációt egy FP32-es VGPR helyre. Na most erre három mód van. Az egyik a DX12-nek az újabb verziója, az októberi Windows 10-től kezdve, a másik a Vulkan pár kiterjesztése, a harmadik pedig az AMD kiterjesztései.

    Az AMD kiterjesztései a legegyszerűbbek. Működnek DX11/DX12/Vulkan API-n. Előbbi kettőhöz AGS kell, míg utóbbihoz AMD_gpu_shader_half_float. Na most ezeket azért kedvelik a fejlesztők, mert nagyon sok kód meg van előre írva, tehát egyszerű beépíteni, ráadásul a kód 100%-ban kompatibilis az NV és az Intel hardvereivel is, csak nem futtat rajtuk packed adattípust. Vagyis beépítetted a funkciót az AMD-re, a többi hardvernél pedig lábon lőtted magad, bár futni lefut.

    A Microsoft esetében az a gond, hogy hiába tudja a hardver, majdnem a legújabb Windows 10 verzió kell hozzá, illetve a shadert is HLSL 2018-as specifikációknak megfelelően kell írni, vagyis le se fordítható korábbi Windows operációs rendszeren, ergo a játék futtathatóságát a Windows 10 október 2018-hoz vagy újabb kiadáshoz kötnéd. Ezzel nem a bal lábad lövöd ki, hanem a jobbat. De legalább működik az összes kompatibilis hardveren, csak kizártál egy rakás, régi Windowson ragadt játékost, és ahhoz, hogy náluk fusson a kód, keményen át kell ám írni, vagyis nem olyan kényelmes a megoldás ez, mint amit az AMD kínál, hogy out-of-box megy mindenen, csak nem biztos, hogy gyorsan.

    A Vulkan megoldása egészen kellemes. Az AMD_gpu_shader_half_float kiváltható a KHR_16bit_storage és a KHX_shader_explicit_arithmetic_types kiterjesztéssel. A probléma az, hogy az utóbbi egy nem véglegesített kiterjesztés, tehát a Khronos ugyan dolgozik rajta, de még megváltozhat a specifikációja, vagyis ha írsz rá egy kódot, akkor ugyan működni fog Windows 7-től fölfelé a kompatibilis hardvereken, de ha a kiterjesztést a Khronos véglegesíti, akkor azonnal kell a patch a játékhoz, mert a KHX_shader_explicit_arithmetic_types támogatása kikerül a meghajtókból.

    Szóval összességében úgy áll a helyzet, hogy a szabványos megoldások, illetve ezek lehetősége jó dolog, de a Microsoft túlságosan új Windows verzióhoz köti a működést, a Vulkanban meg nem végleges még egy szükséges kiterjesztés, amitől nehéz rávenni egy fejlesztőt, hogy támogassa. Végeredményben tehát marad az AMD out-of-box megoldása, ami meg nem működik Intelen és NV-n. Mindenképpen lábon lövöd magad, bármelyiket is választod...

    A packingot mindig be kell építeni. Ez magától nem működik. Persze ez ma nagyrészt annyi, hogy elviszik az AMD kódját, és kész, de ha szabványos megoldás kell, akkor ahhoz majd szükséges egy kis munka is. Nem olyan jelentős persze, de a mostani copy-paste-nál több, de azzal legalább működne minden megfelelő tudású hardveren.

  • #13 Abu85 HÁZIGAZDA FLATRONW #12
    Ú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 FLATRONW #12 üzenetére

    Mert így csak egy pipeline-ra kell tesztelni ebből a szempontból a játékot, ugyanis mindegy, hogy milyen minőségben számol, a végül kiírt adattípus ugyanaz marad. Igen a konvertálás is teljesítménybüntetéssel jár, de nem jelentőssel.
    Erre amúgy van megoldás, nem kötelező így csinálni, de kb. ott megbukik a buli, hogy a szükségesnél több esetben kellene külön kódutat kezelni, ez pedig nem valami kellemes a karbantartás szempontjából.
    Az AMD erre nem ír elő semmit. A fejlesztők szabadon eldönthetik, hogy miképp kezelik a packing implementálását. Egyébként eleve már az RPM beépítése nem valami kellemes, mert sok külön kódot eredményez, tehát logikus a fejlesztők részéről kompromisszumokat kötni. Ezen a szabvány segítene, de kb. hozzá se nyúlnak, eddig mindenki az AMD saját megoldását implementálta, ami ugye nem valami nagy ötlet a többi hardver szemszögéből, persze DX11-re nincs más megoldás, de a DX12 és a Vulkan már kínál szabványos opciót. A DX12-es az októberi Windows 10 óta működik, a Vulkan megoldása OS-től független.

  • #9 Abu85 HÁZIGAZDA FLATRONW #8
    Új Válasz #9
    Ú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 FLATRONW #8 üzenetére

    Persze, hogy észrevehetetlen. Ahol nem történik FP16-on a számítás, a konvertálás ott is megtörténik. Tehát attól, hogy lassabban számol egy FP32-es hardver, még nem fog szebb képet kirakni, mert át lesz konvertálva az adat. Egyébként valószínűleg ki lehetne mutatni a különbséget, de úgy nyilván nem, hogy az FP32-es eredményt mesterségesen lekonvertálják.

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

Hirdetés