Hirdetés

  2. Fórumok
  3. Videokártyák
  4. AMD vs. INTEL vs. NVIDIA
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák

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

  • #33896 Abu85 HÁZIGAZDA Petykemano #33895
    Új Válasz #33896
    Ú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 Petykemano #33895 üzenetére

    Nagyon szép a marketing, csak ha megnézed a DXR-t, akkor az jelenleg csak 16 és 32 bites lebegőpontos formátumot támogat. A tensor magok 8 bites fixpontos ALU-k. ;)

    Eleve az AMD mondta, hogy ők is tudnak rá drivert csinálni, GCN3-tól felfelé van is már tesztcsomag. Egyébként egy olyan dologról vitázunk, aminél a Remedy elmondta, hogy 1920x1080 pixeles felbontáson, pixelenként egy sugarat, virtuálisan maximum 4 méteres távolságig kilőve a számítások nagyjából 5 ms-ig tartanak. Na most egy sugár az nem sok, és a 4 méteres távolság sem az, tehát iszonyatosan szűk térben alkalmazható technikáról van szó, ami a 60 fps-hez mért képszámítás harmadába kerül és akkor ez csak Full HD. 4K-n ez 20 ms, ami a 30 fps-hez mért képszámítás kétharmada. És akkor még nem számoltál semmit, amit ki tudnál rakni a kijelzőre.

    A packing alkalmazható a DXR-en belül, hiszen támogatott a shader modell 6.2 16 bites lebegőpontos formátuma. Persze ettől az ég óvjon minket. :U
    Elmondom neked, hogy miért csinálják ezt a sugárkövetést a gyártók. Az AMD-nek és az NV-nek is ugyanaz a koncepció mögötte. Mindegy, hogy DXR, vagy Vulkan-féle GPUOpen, vagy egy esetleges Vulkan szabvány, a probléma az, hogy a PC-s GPU-kat a jövőben nem igazán lehet úgy skálázni, hogy ne növekedjen meg a multiprocesszor:raszter arány. Viszont ahogy távolodsz a konzolok arányától, ami amúgy 8:1 körüli, úgy lesz egyre több idle lyukad az architektúrában. Tehát tök jó, hogy megvan a GPU-ban az ALU, csak a shadereket nem olyan multiprocesszor:raszterre optimalizálták, amilyen az új, erősebb GPU-ké. Viszont a sugárkövetés egy marhára függetleníthető folyamat a raszterizációtól, vagyis meg tudod azt csinálni, hogy ezt felhasználod az idle lyukak betömésére az aszinkron compute segítségével. Ettől még mondjuk egy újabb, mondjuk 16:1-es arányú GPU nem lesz jobb grafikára, de van egy rakás szabad ALU kapacitása sugárkövetést számolni. :D Nagyjából ennyi a koncepció mögötte.

    Egyébként ez a sugárkövetéses dolog nem rossz, csak lesznek majd olyan árnyoldalai, hogy ha nem lesz meg a teljesítmény, akkor maga a sugárkövetéses rész a programon belül túl egyszerű, hogy bármit is elvegyél belőle, emellett a 32 bites lebegőpontos formátum eléggé zabálja a memóriát is (értem a 16 bit opció, csak aki látott már ilyet, az tudja, hogy nem éppen reális), miközben van erre sokkal jobb formátum is, ami pont nem támogatott. Tehát iszonyatosan kell majd a memória, ami miatt félő, hogy kisebb textúrarészletességet szállít a fejlesztő, vagy rosszabb minőségű modelleket, mert azzal a sugárkövetés memóriaigényét is levágja. Vagyis összességében többet vesznek majd el a raszterizálás minőségéből, mint amennyit a sugárkövetés egyáltalán hozzá tud tenni az egészhez. Nézd meg a Metro Exodust sugárkövetéses trailerét.

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