Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Gomez1984
#2717
üzenetére
Persze, hogy fekszik, amikor az egészet Infinity Cache-re és SAM-re optimalizálták. Így azért nem nehéz. Az Infinity Cache-ből főleg sokat lehet nyerni, ha úgy írják meg a leképezőt, hogy feküdjön neki.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3005
Abu85
HÁZIGAZDA
AsakuraDave
#3002
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3002
üzenetére
A Surface Format Optimization még a régebbi DirectX 9-es játékokra van. Az Xbox 360-as időkben több játék az R11G11B10 render targetekre volt tervezve, mert ezt támogatta az Xbox 360, de PC-n ez hiányzott a DirectX 9 API-ból. Emiatt PC-n FP16 render targetek voltak alkalmazva, csak nem ehhez tervezték a játékot. A hardverek viszont támogatták az R11G11B10 render targeteket, így az AMD és az NVIDIA a fű alatt csinált egy cserét a driverben, így a játékokat mindenképpen R11G11B10 render targetekkel futtatták, amellett, hogy FP16 render targetek voltak előírva a programkódban.
Ez bizonyos körökben felháborodást keltett, így az AMD még sok-sok éve úgy döntött, hogy ezt a kényszerítést kikapcsolhatóvá teszik, így a felhasználó eldöntheti, hogy él-e ezzel az optimalizálással, és a konzolokhoz tervezett rendszerrel futtatja a PC-s portot, vagy úgy, ahogy a PC-s portot tervezték. Az NVIDIA driverében is benne volt ez, csak nem tudtad kikapcsolni opcionálisan.
Az újabb DirectX verziókban már van R11G11B10, tehát a meghajtóoldali optimalizálás, illetve maga a kapcsoló értelmét vesztette. Az NVIDIA kiszedte egy-két éve az optimalizálást, míg az AMD meghagyta a szabad választás lehetőségét, hátha valaki futtat valami régebbi DirectX 9-es címet futtat, és dönteni akar arról, hogy milyen render targetekbe szeretné, hogy dolgozzon a program.
A Tesselation Mode, az egy tesszellációs optimalizálás. A meghajtó oldalán kontrollálni lehet a tesszelláció működését. Az AMD optimized különböző programspecifikus profilokat használ, amit az AMD kézzel állított be, hogy leszűrje a hardver a túl pici háromszögeket generáló tesszellálást. Ennek azért van lényege, mert ha a háromszög túlságosan kicsi, akkor csak számításokat pazarolsz rá, de haszna valójában nincs, sehol sem jelenik meg információként. Ezzel úgy lehet teljesítményt nyerni, hogy közben nincs látható hatása a képminőségre. Manuálisan is be lehet ezt állítani, de ott már a felhasználó szabad kezet kap, és az már okozhat képminőségromlást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3007
Abu85
HÁZIGAZDA
AsakuraDave
#3006
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3006
üzenetére
Manuálisan nem, de az NV-nek ugyanúgy vannak ilyen profiljai, csak nem teszik kikapcsolhatóvá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Ami egy olyan teszt, hogy hasonlóval játékokban nem is fog találkozni egy hardver, mert a játékok környezete nem statikus. Mozogni fog benne minden, és erre nem elég statikus BVH gyorsítóstruktúrát generálni. Másrészt egy combos RT effekt, mint amilyet például a Godfall használ zabálja a VRAM-ot. 5-6 GB-ot, csak az effekt szintjén, és akkor mág mást nem is töltöttünk be a VRAM-ba. Előbb fel kell küldeni a VGA-k memóriáját 20-30 GB közé, hogy az RT-t combos formában lehessen alkalmazni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3080
Abu85
HÁZIGAZDA
Cthulhu Dawn
#3079
Abu85
HÁZIGAZDA
válasz
Cthulhu Dawn
#3079
üzenetére
Nem jó lesz, hanem már jó. Nézd meg azokat a játékokat, amik fejlesztésénél rendelkezésre állt a Navi 21. Watch Dogs: Legion és Dirt 5 például. A Godfallra még nincs összehasonlítás, ott az RT effekt nagyon durvára van szabva, így 5-6 GB VRAM-ot is igényel. Majd később arra is össze lehet hasonlítani, amint megjön a szabványos kód is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3086
Abu85
HÁZIGAZDA
AsakuraDave
#3083
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3083
üzenetére
Itt egy Legion mérés. [link]
#3085 Donnie : Arra bizony. Nagyon messzire lövi a sugarakat, kb. hatszor messzebbre mint a legtöbb játék. Ez azért eléggé problémás a mai hardvereknek, de ennyire messzire számolni igazából memóriazabáló.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3088
Abu85
HÁZIGAZDA
AsakuraDave
#3087
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3087
üzenetére
Le van mérve benne az RX 6800 XT és a 3080 bekapcsolt RT-vel. Mi mást szeretnél még?
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3090
Abu85
HÁZIGAZDA
AsakuraDave
#3089
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3089
üzenetére
Hazudik egy elismert újság? Mi okkal tennék?
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3092
Abu85
HÁZIGAZDA
AsakuraDave
#3091
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3091
üzenetére
Tehát mindenki hazudik, aki nem azt írja, amit te szeretnél olvasni? Ezt úgy hívják, hogy valóságtagadás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ilyet nem mondtam, de világos, hogy van hiteles sajtóterméktől mérés ebben a konkrét kérdésben, de mivel nem azt mutatja, amit ő látni akar, így rögtön rossz az eredmény, és majd ő megmutatja a "valóságot". De arra nem tud válaszolni, hogy egy elismert újság miért hazudna az ügyben, hanem feldobja, hogy biztos lefizették őket, vagy a TPU-t egy másik mérésnél, vagy csak szarul teszteltek...
Csak a jegyzőkönyv kedvéért. A Guru3D is nagyon közel mérte a WD: Legionban a 6800 XT-t a 3080-hoz. 1440p-ben, amiben az eTeknix mért rendre 52 vs. 54 fps-ről beszélünk. [link] - gondolom őket is lefizették, hazudnak, rosszul mérnek ...pick one.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
=WiNTeR=
#3096
üzenetére
Ezt nem tudja senki, egyelőre ellentmondásosan nyilatkozik mindenki. Az NV azt mondta, hogy szabványos RT van a játékban, tehát működnie kell, az AMD pedig azt, hogy bármilyen szabványos RT-t futtatni tudnak.
#3097 p87 : Be kell kapcsolni az RT-t, hogy működjön.
#3102 AsakuraDave : Következő kérdés. Miért nem ezt méri az említett két, hiteles oldal tesztje?
#3112 arn : Csak hibrid RT létezik ma a játékokban. Úgy 10 évig nem is lesz más.
#3121 gabo423 : A 3DMark feature tesztje védekezik az Infinity Cache ellen. Úgy van felépítve, hogy több effekt is direkt teleszemeteli a cache-t. Ez koncepció, mivel ha ezt nem teszik meg, akkor a Radeon le tudja menteni a teljes BVH gyorsítóstruktúrát (ami egyébként 40 MB) egy olyan memóriába, amit 1,6-1,9 TB/s-mal ér el, így ez alapvetően határozná meg a teljesítményt, vagyis nem tudná a teszt mérni az RT részegység sebességét. A teszt azonban erre kíváncsi, nem arra, hogy az Infinity Cache-ben elférne a teljes statikus BVH, és akkor a feldolgozás során el se kellene hagyni a GPU-t a munkával. A sebességvesztés jelentős részét nem az RT egységek okozzák, hanem az a véletlenszerű memóriaelérés, ami miatt a GPU folyamatosan a memóriát címzi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3141
Abu85
HÁZIGAZDA
AsakuraDave
#3140
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3140
üzenetére
Én csak kérdéseket teszek fel. Van két oldal is, ami ugyanazt méri, de te mást. Sőt, hozok egy harmadik oldalt is. [link]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3146
Abu85
HÁZIGAZDA
AsakuraDave
#3145
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3145
üzenetére
Nekem bónusz kérdésem is van. Az árnyékok le vannak véve, vagy tényleg ilyen rondák?
#3144 szasanyi : Az Infinity Cache-nek? Az működik automatikusan, csak dolgozhatsz ellene. De ugye egy játéknál minek dolgoznál a sebességnövekedés ellen?
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#3150
Abu85
HÁZIGAZDA
AsakuraDave
#3148
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#3148
üzenetére
És a másik hardveren is ilyenek az árnyékok? Ennyire rondákat évek óta nem láttam, csak azért érdekel.
#3149 Zorel : Ezért a jegyzőkönyv kedvéért jegyezzük meg, hogy három oldalt is hoztam, amik ugyanazt mérték. Nem egyet, nem kettőt, hármat. Persze mondhatjuk rá, hogy mindegyik szar, de azért komoly kérdés az, hogy három hiteles, elismert oldal gyökeresen mást mér, mint a fórumtárs. Lehet, hogy tényleg csak beállításfüggő, de a kérdés ott van. Vagy téged nem izgat, hogy mi lehet mögötte?
[ 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
szasanyi
#3154
üzenetére
Az RDNA 2 az egy architektúra, annak vannak különböző részei, amiket ki lehet használni.
A SAM-hez és az Infinity Cache-hez nem kell direkt optimalizáció. Lehet írni hozzájuk, de nem kell. Az egyetlen játék, ami direkt optimalizálást használ ezekhez az az Assassin's Creed: Valhalla. De ezt az optimalizálást is két hét alatt rakták össze.
A SAM viszonylag egyszerűen kezelhető, mert egyszerűsít bizonyos problémákat, arra nem nehéz dolgozni, szóval direkt optimalizálások innentől minden játékban lesznek benne, mert gyorsan meg lehet ezeket írni, alig egy-két napnyi munka. De ennek a hatása igazából abban kimerül, hogy a tipikusan nyerhető extra, amit ad (PCI Express 3.0-s platformmal 3-6%, PCI Express 4.0-s platformmal 5-8%) tovább növelhető úgy +10-15% közé. Ennél több azért nincs benne, mert a PCI Express csatoló sávszélessége is limitál, és ha elviszik nagyon ilyen irányba a motorokat, akkor az a tradicionális, resizable BAR nélküli PCI Express 3.0-s rendszereken kivégzi a teljesítményt. Tehát a SAM +10-15%-nál többet nem fog hozni a jövőben, de ennyit könnyen össze lehet szedni pár napos optimalizálással.
Az Infinity Cache óriási talány még az AMD-nek is. Nagyon lehet rá optimalizálni, de nem tudni még, hogy mi az optimális. Annyira új dolog egy ilyen gyors és ekkora cache a GPU-kban, hogy nem látni hol vannak a határai. Arról van mérés, hogy az Infinity Cache a kikapcsolt állapothoz képest 1080p-ben 12-20% között növeli a teljesítményt, míg 4K-ban 8-13% között. Ez effektíve azt jelenti, hogy ha kikapcsolnák ezt a gyorsítótárat, akkor ennyivel esne az új Radeonok teljesítménye. Ez nagyon játékfüggő, illetve inkább motorfüggő, például a Frostbite új leképezője nagyon imádja, ott hozza a legjobb értékeket, de nem azért, mert direkten van erre optimalizálva, hanem mert a Frostbite-on belül a leképező működése amolyan cache-aware rendszer, vagyis a lokalitási elvre van kialakítva a feldolgozási koncepció, amivel igyekeznek azt elérni, hogy a szükséges adatok ott legyenek a GPU-n belül. Ez persze nem azt jelenti, hogy minden ott lesz, de mérhetően megnő a találati arány még a kicsi 3-6 MB közötti gyorsítótárakkal dolgozó GPU-kon is, és ennek a modellnek nyilván jótékony hatása van a nagyon nagy gyorsítótárakra, például erre a 128 MB-osra. A Frostbite esetében egyébként erről volt régen adat, már nem emlékszem hol, de ez a cache-aware irány a találati arányt majdnem 20%-kal növelte a modern GPU-kon. Ez nyilván nem hangzik soknak, ha figyelembe vesszük, hogy egy 5 MB-os L2 cache mellett a tipikus találati arány 17% körüli, de egyáltalán nem rossz, ha azt felhúzod átlag 20% környékére. Egy 128 MB-os cache esetében viszont eleve magas a tipikus találati arány is, és egy cache-aware optimalizálással bőven 50% fölé küldöd. Ezt a módszert terjesztette ki az Assassin's Creed: Valhalla leképezője, amit szintén cache-aware koncepcióban írtak, de kapott egy olyan optimalizálást a nagy cache-ekre, amivel gyakorlatilag elérték azt, hogy az Infinity Cache a kikapcsolt állapothoz képest bő 60%-ot gyorsítson a teljes sebességen 1080p-ben, ami 1440p-t tekintve plusz 45% körül van, 4K-ban pedig +30% körül. Na most ez egy két hetes optimalizálás volt, és nem igazán tudni, hogy hol a felső határ, de egy cache-aware leképező esetében ezeket az értékeket elég egyszerű hozni. Valószínűleg az Ubisoft ezt idővel úgyis kideríti, mert nagyon ráfekszenek erre a témára. Amúgy is fontos a cache-aware leképező, mert a modern GPU-k ezt Infinity Cache nélkül is nagyon meghálálják, nem véletlenül ment erre az EA és az Ubisoft a Frostbite és az Anvil fejlesztésével.
Az egyéb képességeik tekintetében már jóval direktebb támogatás kell. Ezek jó része azért szabvány. A VRS valószínűleg nagyon sok játékban lesz használva a jövőben, mert kvázi ingyen ad extra teljesítményt, meg a modern GPU-k támogatják is. A mesh shading is jó dolog, de a gyors terjedésében amiatt kételkedem, hogy nem kompatibilis a régi futószalaggal, tehát duplán kellene PC-re dolgozni. Ezért is hagyhatta meg az AMD az RDNA 2-ben az NGG-t, ami szimplán át tudja fordítani a vertex és geometry shadereket az új futószalagra, így a fejlesztőknek nem kell ezt direkt támogatni. Ugyanakkor az is igaz, hogy sokkal többre lehet menni a direkt támogatással, csak hát dupla munkát nem sokan vállalnak be.
A sugárkövetés tekintetében az RDNA 2 kihasználható képessége a programozható bejárás. Ezt például a Godfall már használja, de szerintem csak azok a címek fogják bevetni, ahol olyan RT effektet írtak, ami két pofára zabálja a VRAM-ot. Ilyenkor a programozható bejárás valóban hasznos, mert lehet játszani a LOD-dal, ami a VRAM-ra vonatkozó igényt visszaveti, de még így is 4-5 GB-ot lezabál a Godfall RT shadows effektje, bár az is igaz, hogy programozható bejárás nélkül 10 GB-ot is megeszik önmagában, és akkor még nincsenek betöltve a raszterizációhoz szükséges adatok. Nem véletlen, hogy szabványosan ez az effekt még nincs engedélyezve. Hosszabb távon egyébként jó esély van rá, hogy szabványosítva lesz a programozható bejárás, ennek kellene lennie a következő logikus lépésnek a DXR fejlődése szempontjából, és azzal kezelni lehet a komolyabb RT effektek eldurvuló VRAM igényét. Annyit tudni, hogy a Microsoft már erősen dolgozik ezen a specifikáción, így az AMD specifikus megoldásában sok jövőt nem látok, mert úgyis jön rá szabvány. De amíg az megérkezik, addig kezelhetők vele az extrém memóriaigénnyel rendelkező RT effektek, de utána inkább szabványosan kellene ezeket megoldani.[ 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
szasanyi
#3228
üzenetére
Resizable BAR implementációt tud hozni az NVIDIA. Erre lehet válaszolni. A tesztelés a problémás része, de valószínűleg az alaplapgyártók ugyanúgy meggyőzhetők a legújabb platformok erejéig. Nem hiszem, hogy ez nehéz lenne, csak ki kell adni pár új BIOS-t az alaplapgyártóknak.
Infinity Cache-hez hasonló rendszerekben nincs nagy tapasztalata az NVIDIA-nak, ilyen sűrű SRAM-ot nem szokás GPU-khoz használni, de nem olyan nehéz megtervezni. De az Intel és az AMD itt kétségtelenül előnyben van, mert a processzorokhoz hasonló gyorsítótárakat terveznek, tehát elég csak elkérni a dizájnimplementációt a CPU-s csapatoktól. Ezt lemásolni természetesen sokkal könnyebb, mint nulláról megcsinálni mindent, de az egész csak gyorsítótár, tehát nem egy megugorhatatlan feladat ez a következő GeForce generációkra.
VRS-ük és mesh shadingjük már van. NGG-hez hasonló rendszerük nincs, de nincs is értelme fejleszteni, mert mire készítenek rá egy tényleges implementációt, az azért jó 4-5 évnyi munka, addigra már el lesz felejtve a vertex shader.
A programozható bejárást is tudják támogatni. Ehhez tényleg egy szabványos API kell, a hardverben pedig ott vannak a shaderek, amik programozhatók, tehát marha jól tudják majd a feladatokat futtatni. Ez a része a dolognak a Microsofton múlik, mert a ma megvásárolható hardverek tökéletesen alkalmasak arra, hogy a bejárási lépcső teljesen programozható legyen. Igazából az a nagy kérdés, hogy miért nem az már most. Bár valószínűleg van némi véleménykülönbség a BVH gyorsítóstruktúra specifikálása szempontjából, de előbb-utóbb mindenkinek be kell adnia a derekát a szabványosításért. Nem valami nagy ötlet növelni a hardverek RT teljesítményét, de eközben nem gondoskodni a memóriahasználat optimalizálásáról.
#3234 AsakuraDave : Ez az eljárástól függ. Pontosabban attól, hogy maga a sugárkövetés milyen távolságra történik meg. Manapság azért egyáltalán nem szokás messzire lőni a sugarakat. Általában a LOD0 vagy LOD1 távolságán belül véget ér a pásztázás. Ez aránylag memóriakímélő, mert alig kell extra adatot betölteni. A Godfall sugárkövetés ott válik memóriazabálóvá, hogy nagyon messzire lövik ki a sugarakat, még a LOD4 is játszik. Na ez már memóriapazarló, mert a DXR 1.0 és 1.1 nem engedi meg, hogy a LOD szint megváltozzon a sugárkövetés során. Ezt a sugár kilövésekor be kell állítani, és az marad végig, ami elég gázos működés, mert ha minden sugarat LOD0-ra lőnek ki, de egy messzi objektumot talál el, akkor arra be kell tölteni rá a LOD0-t. Tehát effektíve amit látsz a kijelzőn, arra lesz egy raszterizálásra szabott LOD kezelés, illetve mellé még mindenre ott lesz a LOD0 a memóriában. Ez brutálisan memóriapazarló, de a DXR 1.0 és 1.1 alatt nem igazán lehet mit tenni az API nem engedi meg módosítani a LOD szintet a sugár kilövése után. A programozható bejárás ezen annyit segít, hogy gyakorlatilag a fejlesztők megírhatják a saját compute shaderjüket a bejárásra, ami nyilván lehetőséget ad arra is, hogy sugarat LOD0-val indítsd el, miközben bizonyos távolságokat meghaladva a LOD szint csökkenthető. Ez jóval memóriakímélőbb, az effekt nyers memóriaigényét gyakorlatilag meg lehet vele felezni.
A DiRT 5 hagyományosabb módon közelíti meg ezt a kérdést, a régi játékokhoz hasonlóan nem lövi messzire a sugarakat. Ebből a szempontból a Godfall egy kivétel, az nagyon távolra is számolja az effektet. Ezek érthető dizájnbeli döntések. A DiRT 5 egy autóverseny, alapvetően amit látni fogsz az RT árnyékokból azok autón megjelennek, többre nincs is szükség, meg értelme sincs, mert nagyon gyorsan hajtasz, tehát alig látnál különbséget, ha messzire lőnék a sugarakat. A Godfall viszont egy TPS, ráadásul egész nagy nyílt terekkel, ott azért lehet haszna a távolra számolt RT shadows effektnek. Bár ezt azért így sem ártana skálázni low-medium-high szintre, mert jelen formában vagy van sok VRAM-od bekapcsolni az effektet, vagy nem kapcsolod be, mert nincs elég memóriája a kártyának.
#3241 _Horka_ : Nem igényel a SAM optimalizálást, de lehet rá optimalizálni. A konzol teljesen más, ott a memória elérése szempontjából egészen nagy előnyök vannak a PC-hez képest. PC-n ez akkor valósítható meg, ha elfelejtjük a dedikált GPU-kat.
Nem csak egy cache, mert ezt azért implementálni kell. Egyáltalán nem könnyű ezt hardveres szinten megoldani, az AMD-nél sem a GPU-t tervező részlet csinálta, hanem a CPU-s, nekik van ilyen méretes cache-ekről nagy tapasztalatuk.
[ 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
_Horka_
#3258
üzenetére
Sokkal bonyolultabb a gyorsítótárak tervezése ennél. Ezek nagy kapacitás mellett komoly tranzisztorigénnyel rendelkeznek, vagyis el kell érni, hogy a megfelelő kapacitáson túl megfelelő energiaigény mellett működjön, de eközben ne foglaljon sok helyet a lapkán, és a teljesítménye is optimális legyen. Nem véletlen, hogy az Infinity Cache-t nem is a GPU-s részleg rakta össze, hanem a CPU-s, mert sokkal nagyobb tapasztalataik vannak ezen a szinten. A GPU-s részleg ezt a kapacitás sokkal nagyobb lapkaterületen hozta volna össze, mert a GPU-k tipikus tervezési jellegzetességei miatt korábban nem voltak lényegesek, hogy az a 4-6 MB-nyi L2 cache mennyire jól van megtervezve, úgyis csak a lapkaméret töredékét viszi el.
A SAM-et egy fejlesztő direkten nem látja. Ők erőforrásokat helyeznek a memóriába. Azt lehet optimalizálni, hogy a strukturált puffereket megfelelően alignálják az egyes architektúrákra, de az a helyzet, hogy sokszor le se szarják, egyszerűen áthozzák a konzolhoz alignált kódot és kész. Ez nyilván nem optimális egy csomó architektúrának.
A SAM pont azért tud előnyt hozni, mert több leíró helyezhető a VRAM-ba. Erre lehetne nagyon játszani, de nem érdemes, mert akkor szar lesz a nem SAM-es működés, az meg még mindig túl nagy része a piacnak. A növekedés nagy része a jövőben abból fog állni, hogy a fejlesztők úgy istenigazából szarni fognak a leíróhalmazok optimalizálására PC-n, mert már nincs 256 MB-os limit. Nem kell nagyon beleférni ebbe, nem kell megfelelően alignálni, mert a hardverben van nagyobb VRAM is, amit lát és koherensen kezel a host. Tehát a konzolról való copy-paste ugyan nagy pazarlás lesz a memóriahasználatban, de a SAM visszanyeri a sebesség egy jó részét, amit az optimalizálás hiánya okoz. Akkor lehetne ebből nagyobb dolgokat kihozni, ha a fejlesztők elfelejtik a nem SAM-es platformokat (nem fogják), és normálisan fognak alignálni minden architektúrára (nem fognak).[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azt hittük, hogy a Godfall RT shadows effektje memóriazabáló a maga 5-6 GB-os VRAM igényével. Erre a Far Cry 6: fogd meg a söröm... 9 GB csak az RT shadows effekt Full HD-ben.
Lassan nem is a kevesebb sugár miatt kellenek az AI upscale effektek, hanem azért, hogy a render targetek felbontása csökkenjen. Bár én visszafognám a Far Cry 6-nál a sugarak követésének hosszát. Tök felesleges ellőni őket a negyedik-ötödik LOD szintig, nem ad látható képminőségelőnyt, de a memóriát képpofára zabálja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Radeonok valamivel hatékonyabban bánnak a VRAM-mal, mert csak egy eszközlokális type-ba tartozik az egész. A GeForce-ok esetében van az, hogy egy heap-hoz két eszközlokális type kapcsolódik. Emiatt az alkalmazásnak is úgy kell kezelnie a GeForce-okon mondjuk 7,75 GB memóriát, hogy két 3,875 GB-os részre van bontva. Az AMD-nél egy 7,75 GB memória logikailag is 7,75 GB. Ez amúgy nem okoz jelentős eltérést, csak annyit, hogy az AMD picit jobban ki tudja használni a rendelkezésre álló kapacitást, mert a nagyobb logikai méreten jobban kezelhető a fragmentáció. Az Ampere GeForce-oknak egyébként már nem lenne szükségük erre, tudnának működni egy nagy eszközlokális type-pal is, de egy csomó korábbi optimalizálás nem futna rajtuk, szóval maradt a két type. Ez tényleg nem okoz valós problémát a gyakorlatban.
[ 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
szasanyi
#3562
üzenetére
Nem kell nyomniuk a gázt. Úgy néz ki, hogy maguktól mennek a cache-aware leképező felé a fejlesztők. Ez mondjuk az én véleményem szerint váratlan dolog, mert az Infinity Cache-ről biztos, hogy nem tudtak, de láthatóan a Frostbite leképezőjét kezdte el másolni mindenki. Olyan körülmények között pedig az Infinity Cache borzasztóan előnyösen működik. Valószínűleg a cache-aware feldolgozás már 4-6 MB-os L2 cache mellett is előnyös, ez azért látszott a Frostbite-on, míg 128 MB cache mellett nagyon kedvező. Az Ubisoft az AnvilNext leképezőjét az új játékukra átírták cache-aware-ra. Tuti nem tudták, hogy jön ilyen Infinity Cache, egyszerűen abból indultak ki, hogy ha a Frostbite-on működik a rendszer, akkor nekik is működni fog. Az más kérdés, hogy ha már eleve ilyenre szabták a leképezőt, akkor dobtak hozzá még egy kis Infinity Cache optimalizálást, és emiatt nem kell semmit sem csinálnia az AMD-nek, hátra kell dőlniük mozizni, és nézni, hogy az EA és az Ubisoft után még ki áll át cache-aware leképezőre. Szerintem többet dolgoznak azon, hogy győzködjék a fejlesztőket a magas részletességű textúrák alkalmazásán.
[ 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
Relatív gyári teljesítmények:
● RX 6400-hoz képest
● RX 6500 XT-hez képest
● RX 6650 XT-hez képest
● RX 6750 XT-hez képest
● RX 6950 XT-hez képest
Fogyasztási keret állításához:
● MorePowerTool
/link a weblap közepe fele/
● MorePowerTool leírás/guide, mit hogyan, miért !!!
Aktuális AMD driver:
● AMD.com
EXCEL-tábla topiklakók méréseivel:
● [LINK]
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest