2. Fórumok
  3. Videokártyák
  4. Majdnem harmadolja a teljesítményt a DirectX Raytracing a Battlefield V-ben
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD.hu témák
Keresés

Hirdetés

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

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

    Nem is tudtam, hogy a Mantle majdnem harmadolta a teljesítményt. WoW, ez hogy maradt ki. :)) Én úgy emlékeztem, hogy növelte.

    Azt ugye azért tudod, hogy a Mantle miatt létezik a DirectX 12 és a Vulkan. Lehet, hogy sokan elfelejtették már, de az AMD elmesélte régen, hogy a Microsoftnak szóltak, hogy a DX11-nek a feldolgozási modellje nem jó. Az Microsoft mondta nekik, hogy csináljanak akkor egy jobbat. És az AMD csinált egy prototípus API-t. A Microsoft azt felkarolta, és arra épül a DX12. Ennek a fejlesztése viszont sokáig tartott, így Repi megkérte az AMD-t, hogy ha már van ilyen prototípusuk, akkor csináljanak már neki egy saját API-t. Ez lett a Mantle. Ebből pedig ugye lett a Vulkan. Ez az oka egyébként annak is, hogy miért hasonlít ez a három API ennyire egymásra. Mindháromnak ugyanaz a prototípus az alapja. Ami megjegyzem, hogy ha nem létezett volna, akkor most DXR sem lenne, mert arra menne az erőforrás, hogy a feldolgozási modellt javítsák meg. ;)

    Ez lesz egyébként a DXR-ből is. Pár év alatt kiforrja magát, illetve megkapja majd a WinML-t, és majd az újabb hardverekkel teljesítménye is lesz.

    [ Szerkesztve ]

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

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

    Nem. Jó volt ez így. Ezt nincs igazán értelme a háttérben csinálni. Pont az a lényeg, hogy a közösség karolja fel, hogy amikorra tényleg lesznek jó sebességre képes hardvereke, addigra legyenek alkalmazások is.

    A probléma itt leginkább az, hogy úgy lett eladva, hogy ez már az aktuális generációra is jó. Pedig lehetett volna más előnyét is hangsúlyozni az RTX-eknek, van egy rakás, amiről szót sem ejtettek.

    [ Szerkesztve ]

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

  • #29 Abu85 HÁZIGAZDA Cifu #27
    Új Válasz #29
    Ú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 Cifu #27 üzenetére

    Fel persze. Amikor írsz egy új motort, akkor nem azt nézed, hogy most hogyan futna, hanem azt, hogy amikor megjelenik rá egy játék, akkor mire lesz képes. Ez az egész két éves távlatban egészen vállalható lesz. Akkorra azért már lesznek 2 TB/s-os VGA-k is.

    Lehet mondani, hogy ez így most fostalicska, de valójában muszáj így bevezetni, hogy két év múlva ebből legyen is valami. Ami nem lett volna muszáj az a ráépített hype, de az egy marketinghez kapcsolódó döntés volt.

    [ Szerkesztve ]

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

  • #35 Abu85 HÁZIGAZDA Cifu #32
    Új Válasz #35
    Ú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 Cifu #32 üzenetére

    Egy részükbe igen. Persze valószínű, hogy a többség ezt összefűzi majd a WinML-lel, mivel azzal csökkenteni tudják a számolt felbontást és AI-val felskálázhatnak. Alapvetően ne legyen abból félreértés, hogy a Microsoft a DXR-t a WinML mellé tervezte, csak hát utóbbi csúszik.

    [ Szerkesztve ]

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

  • #43 Abu85 HÁZIGAZDA Cifu #42
    Új Válasz #43
    Ú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 Cifu #42 üzenetére

    Az egész valós idejű számítógépes grafika trükkök sorozata. :)

    [ Szerkesztve ]

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

  • #65 Abu85 HÁZIGAZDA guftabi96 #62
    Új Válasz #65
    Ú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 guftabi96 #62 üzenetére

    Megoldani nem, de kitaláltak valamit, amivel kezelni fogják. Kicsit több memóriát igényel viszont. Azt nem tudom, hogy mikor építik be, elvileg a napokban, vagy akár már most is benne lehet a BF5-ben.

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

  • #75 Abu85 HÁZIGAZDA Anaren91 #73
    Új Válasz #75
    Ú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 Anaren91 #73 üzenetére

    De ha nem polírozzák át a világot, akkor meg nem látszik a technika előnye. Ördögi kör. :DDD

    (#74) b. : Vérpisti már konzolon headshotol auto-aimmal. ;]

    [ Szerkesztve ]

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

  • #139 Abu85 HÁZIGAZDA Cobra652 #136
    Új Válasz #139
    Ú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 Cobra652 #136 üzenetére

    Vannak olyan beállítások, amelyek low-on futnak Xbox One X-en. De olyanok is, amelyek ultrán. Ez fejlesztői forrásból van. Szóval nagyon meg van keverve. A legtöbb beállítás egyébként medium vagy ahhoz közeli egyedi konfiguráció. Nyilván az egész attól függ, hogy mi az adott beállítás limitje. Például memória van bőven az Xbox One X-en, így az ezt zabáló, de mást nem igazán terhelő opciók mehetnek magasra. Amiből relatíve kevés van az a fill rate. TFLOPS-okból sincs annyira sok, de például ami mondjuk ezt zabálja, kifejezetten a speciális műveletekkel, mint a gyökvonás, azokra van alternatív kód, ami a tipikusan lassú operációkat kerüli. Ez konzolon egyszerű, tudod, hogy mi fáj a gépnek, tehát tudod, hogy mit kell kerülni. PC-n nehezebb, mert annyiféle architektúra van, hogy az egyes operációk másképp fájnak az egyes GPU-knak.

    [ Szerkesztve ]

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

  • #144 Abu85 HÁZIGAZDA b. #141
    Új Válasz #144
    Ú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 b. #141 üzenetére

    Tudtommal az opciók azt határozzák meg, hogy milyen távolra lövi ki a sugarat a rendszer. Valószínűleg low-on nem annyira távolra, így kevesebb ütközés lesz. Mediumon pedig már elég távolra, így több ütközés lesz, aminél mondjuk a legtöbb jelenetben nem jelent sokkal több ütközést a high és az ultra távolsága. Emellett a low beállításnál az árnyalás kevésbé terhelő, míg medium-high-ultra szinten ez ugyanaz. Valószínű, hogy az árnyalás annyira drága művelet az utóbbi három opcióban, hogy mindegy mennyire távolra megy a sugár, az nem okoz nagyságrendi változást.

    Van már. Egy rakás új hardverünk (CPU-k, VGA-k) van, mennek a tesztek párhuzamosan. Csak nincs elég rendszermemóriánk, hogy annyira sok gép működjön egyszerre.

    [ Szerkesztve ]

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

  • #147 Abu85 HÁZIGAZDA t72killer #146
    Új Válasz #147
    Ú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 t72killer #146 üzenetére

    Ennek különösebb jelentősége most nincs, mert nagyon keveset változtak az API implementációk. Finoman szólva semmit. Ez mondjuk nem baj, de így az újabb driver nem sokat ér ám. :))

    [ Szerkesztve ]

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

  • #151 Abu85 HÁZIGAZDA Jack@l #148
    Új Válasz #151
    Ú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 Jack@l #148 üzenetére

    A DXR-ben meghatározható, hogy mekkora távolságig számolja a sugarat (RayT* függvények).
    Ha találat van, akkor ott több dolog is történhet, számos helyzetet lekezel a rendszer. Attól függ, hogy mit talált el, és arra mi van meghatározva, any hit vagy closest hit. Ha viszont nincs találat a meghatározott távolságig sem, akkor a miss-re meghatározott kód dönt arról, hogy mi történjen.

    [ Szerkesztve ]

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

  • #229 Abu85 HÁZIGAZDA t72killer #228
    Új Válasz #229
    Ú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 t72killer #228 üzenetére

    Lehet ilyet találni. Azok a motorok, ahol már nincs DX11 path, így nem szükséges a régi API korlátjait betartani az erőforrások bekötése során. Ilyen például a Forza Horizon 4. [link] - de amúgy ez sem 100%-ban a hardver eredménye, hanem az AMD explicit API-khoz tervezett drivere sokkal kiforrottabb. Egyszerűen előny, hogy három évvel hamarabb megkezdték a munkát az explicit API-k szempontjából. Nyilván hiába önti ebbe az Intel és az NV a pénzt, időt nem tud vásárolni, márpedig az explicit API implementációjánál ez a kritikus tényező.

    [ Szerkesztve ]

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

  • #232 Abu85 HÁZIGAZDA t72killer #231
    Új Válasz #232
    Ú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 t72killer #231 üzenetére

    Ezért írtam, hogy nem teljesen a hardverben van az előny a Forza Horizon 4-nél, hanem az AMD drivere működik hatékonyabban, viszont a driver előnye, ahogy kezeli a CPU-t, az 4K-nál már nem látszik annyira, mint Full HD-ben. A Forza Horizon 4-ben csak ez jön ki. De egyébként, ha raksz a GeForce mellé egy 16-magos Threadrippert, akkor az AMD driverelőnye csökken Full HD-ben is.

    A Turing hardverben feljött. Az NV-nek a gondja az explicit API-k szoftveres támogatása. Ebben van még tartalékjuk, mert ugye egy időben félreterveztek, illetve később is kezdték a munkát.

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

  • #236 Abu85 HÁZIGAZDA b. #235
    Új Válasz #236
    Ú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 b. #235 üzenetére

    Sajnos nem nagyon tesztelnek Threadripperekkel. Még az van belevésődve az agyba, hogy a kevesebb, de nagyobb órajelű mag a nyerő, de ez már nem univerzális igazság. Esetenként pont a több mag a jobb.

    Alapvetően DX12/Vulkan API mellett jót tesz mindennek a több mag, csak abban a környezetben, amit a Forza Horizon 4 használ fontosabb az NV-nek a több mag, mert nagyon más a terhelés a többi explicit API-t használó játékhoz képest. De ez nagyrészt az implementációjukból adódik. Azért mégis kb. három év különbség van az AMD és az NV implementációja között, és az a három év sokat ér ám, hiszen amíg az NV még csak tervezte a meghajtóját, addig az AMD már javában tesztelt. Nyilván az AMD meghajtója sem volt jobb három évvel korábban.

    Az a fő különbség egyébként, hogy nem túl jó irányt választott az Intel és az NV. Józan paraszti ésszel elvileg az a jó, ha minél kevesebb rétegből áll a meghajtó, így gyakorlatilag az API-hoz natív támogatást írsz. Az AMD ezzel szemben furcsa dolgot csinált még 2014-ben. Már akkor úgy épült fel a Mantle implementációjuk, hogy volt egy PAL, illetve ezen egy Mantle ICD, tehát a meghajtón belül rétegezett volt az implementáció. Józan paraszti ésszel ez hülyeség, mert teljesítményt vesztesz vele, viszont az AMD úgy tapasztalta a Mantle tervezése során, hogy ez a teljesítményveszteség elhanyagolható amellett, amennyi tempót lehet nyerni a PAL folyamatos optimalizálásán. Emiatt a DX12-t és a Vulkan API-t úgy támogatják, hogy raktak a PAL fölé még egy-egy ICD-t. Tehát minden erőforrást beleölnek a PAL optimalizálásába, és abból nyer a Vulkan, a Mantle és a DX12 meghajtó is. Az Intel és az NV natív támogatást írt eredetileg ezekre az API-kra, vagyis nekik egy optimalizálási munka dupla erőforrás és pénz, mert nincs rétegezve az explicit API-k támogatása. Azóta az Intel már megindult a rétegezés felé, így később olyan meghajtójuk lesz, mint az AMD-nek. Az NV-nek az a gondja, hogy nekik azért a DX12 meghajtójuk extrém bonyolult a binding emuláció miatt, tehát most azt újrakezdeni nem valami költségkímélő megoldás, így valószínűleg maradnak egy darabig a natív implementációnál, még akkor is, ha ma már úgy gondolják, hogy jobb a rétegezett. Innen már nehéz visszafordulni, így is változtattak az implementáción nemrég, és eléggé logikátlan lenne megint belenyúlni, mert lassan az Intel is izomból fog optimalizálni, az AMD pedig régóta ezt csinálja, szóval le kell nyelni, hogy nekik ez drágább lesz, és csinálni a meghajtó kigyúrását.

    Egyébként valószínűleg az NV és az Intel nem hibázott, amikor erre mentek. Azért az AMD-nek ott volt a Mantle, amin élesben tesztelni tudták még a legextrémebb meglátásaikat is. Akkor nem vállaltak nagy kockázatot, hiszen hasonló API még a kanyarban sem volt. Az Intel és az NV jóval később kezdte meg ezt a munkát, és ott már valószínűleg nem volt idő minden eshetőséget aprólékosan letesztelni. Na most ilyenkor azért jóval nehezebb jól dönteni. Nagy hátrány egyébként nem éri így az Intelt és az NV-t. Alapvetően több pénzt égetnek el, és lassabban tudnak dolgozni, de működni működik így is a meghajtó.

    [ Szerkesztve ]

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

  • #239 Abu85 HÁZIGAZDA b. #238
    Új Válasz #239
    Ú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 b. #238 üzenetére

    A Vulkan API-val eleve nem volt annyi gondjuk, mint a DX12-vel. A Vulkan nem bindless API. De itt nem egy API egy architektúrára írt specifikus implementációjáról van szó, hanem arról, hogy mennyire sok befektetés a teljes termékskálára optimális támogatást adni több explicit API-hoz. És ez itt anyagi szintű, illetve erőforrás-menedzsmentre (humán szempontból) vonatkozó probléma. Az már önmagában egy gond, hogy az API-k teljes termékskálán keresztüli támogatását többször annyi erőforrás befektetésével tudod biztosítani. Egy programozót és pénzt csak azért égetsz, mert a múltban hozni kellett egy döntést, és az nem sült el jól. Nyilván itt megjegyzendő, hogy az AMD pattoghat azzal, hogy ők jól döntöttek, mert a pénzüket és az embereiket most ráállíthatják mindenféle olyan fícsőrre, mint a Chill, az Overlay, a Link, az új vezérlőpult, meg a következő aktuális lófaszjancsiság, amit kitalálnak, amikor nem tudnak mit kezdeni a szabad kapacitásukkal, de azért úgy marha könnyű ám jól dönteni, hogy az éles bevetés előtt két évig egy saját API-n teszteled, hogy mi a jó. :D

    Nem függ a host CPU-tól ez. Itt az volt a gond, hogy az NV-nek hiányzott a tapasztalat egy saját explicit API-n. Ez nem az ő hibájuk, nyilván átgondolták, hogy mit csinálnak, de nem ugyanaz fejben lejátszani, vagy konkrétan lemérni a gyakorlatban. Az AMD ezt meg tudta tenni, ők nem. Mivel az Intel is ugyanarra indult, így nyilván ez tűnt papíron logikusnak. Na most ha beleöltél egy implementációba több évet, sokszázezer dollárt, és az az implementáció alapvetően működik, akkor van egy olyan íratlan szabály, hogy ne írd újra. Erre jó példák vannak az iparágon belül is, amikor az ATI még 2005 körül úgy döntött, hogy a nulláról újraírják az OpenGL meghajtót. Megtették, 2006-ra be is vetették, és javult-javult, csak hát elvertek egy rakás pénzt és erőforrást igen kevés extráért, eközben az újraírás időszakában még a régi meghajtót sem fejlesztették, mert ugye minek, az úgyis kuka lesz. Szóval alapvetően ha önteni is kell bele a pénzt, vagy akár fel is kell azt gyújtani, akkor is nagyon megfontolandó nulláról újrakezdeni. Főleg úgy, hogy igazából nem látni félelmetesen nagy problémákat a GeForce Vulkan és DX12 implementációin. Aztán persze lehet, hogy a háttérben már megkezdték a váltást, ahogy az Intel, csak nem verik nagy dobra.

    [ 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