-
GAMEPOD.hu
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Értettem, és ezért írtam le neked, hogy az FSR2 egy open source eljárás. Nem kell hozzá semmi szerződés, mindenki használhatja, ahogy akarja. Ergo az AMD nem tudja előírni, hogy miképpen használják, mert nem zárt a kód. Bárki letöltheti, és alkalmazhatja úgy, ahogy akarja.
Mi az, amivel követelni tudnak? Nem adják oda az FSR2 kódját? Le lehet tölteni a GitHubról. Az AMD így nem tud követelni semmit. Mindenki leszedheti szabadon a kódot, és használhatja, ahogy akarja. Az AMD pusztán a nyílt forráskód miatt nem tud beleszólni ebbe.
Ha zárt lenne a forráskód, akkor más lenne, mert muszáj lenne szerződni, hogy alkalmazzák, és akkor lehetne követelésekkel előállni, de úgy, hogy nyílt a forráskód, tök hasztalan bármilyen szerződés. Letöltöd és használod.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Létezik egy csomó játék, amiben nincs benne mindhárom felskálázás. Olyan is van, amiben csak FSR van, és olyan is, amiben csak DLSS.
Az FSR2 mellett is lehet használni bármit, de ugye számít az, hogy anyagilag ennek karbantartási költsége van, mert ugyanarra a problémára nem egy, hanem rögtön kettő, vagy három eljárást is használnak a fejlesztők. Lehet, ahol erre van erőforrás, anyagi fedezet, de leginkább akarat.
A VRAM terhelés leginkább a memóriamenedzsmenttől függ. A Capcom menedzsmentrutínja eléggé egyedi módon van megírva, így nem nagy gond, ha elkezdik méretes textúrákkal telepakolni a játékot, mert a menedzsment tudja, hogy meddig mehet el. Ezt szándékosan írták meg így, hogy a motor automatikusan tudja, hogy mit kell tenni, ha kifogy a VRAM-ból, és hogy ne akadozzon, hanem szépen kezdje el csökkenteni a textúrák minőségét. Ez egy döntés, és alapvetően nagyon jó módszerről van szó.
A fejlesztésekbe ma minden cég besegít pár emberrel. Ez nem egyedi dolog. A Starfield esetében talán azért felülreprelzentált az AMD, mert tulajdonképpen az egész memóriamenedzsmentet ők írták meg PC-re. Ez azért nem szokványos, mert igencsak teljesítménycentrikus kódról van szó, így nem bízzák annyira a gyártókra az egészet, de gondolom fontosabb volt a moddolhatóság, amihez viszont bitang memóriamenedzsment kell egy explicit API-hoz. Ezt valószínűleg a Bethesda, vagy a Microsoft nem tudta volna magától megcsinálni. A felskálázást megoldották volna maguktól, de ugye ott az Xbox GDK, és abban van FSR2, az a kód meg direkten menthető PC-re. Az AMD ehhez nem kell, mert a Microsoft FSR2 verzióját alkalmazzák. Az pedig teljesen érthető, hogy ugyanarra a problémára nem akarnak extra költségeket, így egy olyan megoldást választanak, ami a legtöbb hardveren fut. De mint írtam van olyan játék is, ami pont csak DLSS-t kínál. Ugyanazért van ez is, mint amiért némelyik játék csak FSR-t kínál. Egyszerűen egy megoldás belefér, de kettő már növeli a karbantartási költségeket.
#62547 b. : Ezt a WCCFtech fejtette ki, és mindeni más átvette, de az AMD nem ismerte be. Viszont okkal adtak olyan választ rá, mert jelenleg egy csomó üzletlánc írt már feljegyzést arról, hogy a Starfield miatt megugrottak a Radeon és Ryzen kombó rendelések teljes gépekben. Ez is egy marketing az AMD részéről. Nem akadályozzák meg, hogy az FSR2 működjön a konkurens hardvereken, de úgy tesznek, mintha valami exkluzív dolog lenne, és ezzel hardvereladásokat generálnak, mert a média a tervnek megfelelően erre rá is játszik. Ergo egy csomó ember most azt hiszi, hogy ha nem vesz Ryzen+Radeon párost, akkor nem tud majd mindent bekapcsolni a Starfieldben. Kihasználják ők is az emberek tudatlanságát.
És továbbra is fontos látni, hogy egy csomó játék csak DLSS-t használ, tehát nem egyedi dolog az, hogy a másik felskálázását nem építi be a fejlesztő. Ezekről is ugyanúgy lehetne írni, hogy jaj csúnya NV lefizeti őket, de igazából a valóság az, hogy ezek fejlesztői döntések. Főleg nyílt forráskódú rendszernél, mert ugye a nyílt forráskód miatt nem szükséges a kód tulajdonosa, hogy implementáld.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A felskálázóknak saját denoiserük volt eddig is. Annak eltéréseit nem nagyon látod persze, mert nincsenek annyira extrém skálán használva a felskálázók, hogy látványosan kijöjjön az alkalmazott denoiser minőségkülönbsége, de a Tellusim egyszer lemérte, hogy a beépített denoiserek mennyire hatékonyak: [link] - persze amúgy ez az összehasonlítás sem tökéletes, mert itt a különbség leginkább abból ered, hogy az FSR2-nél a denoiser több ideig fut, tehát komplexebb, míg az XeSS és a DLSS esetében máshova megy el a budget, így nem lehet annyira komplex denoisert alkalmazni. Ez ilyen pro-kontra dolog. Ha x-re költesz a sebességből, akkor kevesebb jut y-ra.
#62567 b. : Overwatch 2-ben miért nincs DLSS? Az NV szponzorált. Talán a fejlesztők nem akarnak erőforrást fektetni egy olyan eljárás karbantartásába, amit az FSR-rel megoldanak minden hardveren? Hmmm... elképesztő gondolat, hogy ilyen előfordulhat.
#62559 paprobert : A fejlesztők tetszőlegesen használhatják az FSR-t. Ahogy akarják. Azt használnak mellette, amit még akarnak. Ebbe az AMD nem tud beleszólni, mert open source a kód. De nem is akarnak beleszólni, mert akkor elveszne a fejlesztők szabad döntése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Overwatch 2-t is leblokkolták?
Milyen versenyelőnyt ad? Ugyanúgy felskálázó. Ilyen erővel ne rakjanak grafikai beállítást a játékba, mert különbözik majd a kép.
De egyébként nyilván a fejlesztők döntése. Ezek mind azok, hiszen a fejlesztők írják a programot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Amiért nem hiszen a mesékben? Hát ez van. Valaki megvezethető, valaki nem az.
De ezért sikeres a marketing. Amúgy tényleg... miért nem tiltják be a különböző grafikai beállításokat? Az nem versenyelőny? Kilóg a lóláb.
[ 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
paprobert
#62576
üzenetére
Egy eljárás részben azért szokott open source lenni, hogy a fejlesztő védve legyen. Vagyis az eljárás tulajdonosa nem tudja semmilyen módon rákényszeríteni az akaratát a fejlesztőkre, mert akkor is tudja használni az eljárást, ha a tulajdonosa valami olyat kér, ami összeegyeztethetetlen a piaci realítással. Ilyen formában nehéz erre szerződést kötni, mert azt fogja mondani a fejlesztő, hogy nem, és letöltik a kódot a GitHubról.
#62577 b. : Abból egy csomó cím FSR1-es, és ugye ez fontos szempont, mert azok azért alkalmaznak FSR1-et, mert hiányzik a mozgásvektor, így nem is tudnak alkalmazni temporális felskálázást. De az ilyen tényekkel ne törődj, mert még a véletlenül kompatibilitási problémák lépnek fel a nézeteddel.
A Blizzard pedig inkább azt akarta, hogy ne legyen ennek magas karbantartási költsége. Mert amúgy a játékosok már a low és high grafikában minőség és sebességkülönbséget kapnak, ugyan mit számítana egy alternatív felskálázás itt? Persze sokan beveszik, mert nem néznek utána annak, hogy két eljárás ugyanarra a problémára dupla költség, és hát akarja a fene ezt megfizetni, ha az egyik eljárás fut minden hardveren. A Blizzard persze eladhatja ezt úgy, hogy jót akarnak, de ugye tényleg kilóg a lóláb ott, hogy ha azonos feltételeket akarnak, akkor miért is lehet más effekteket paraméterezni? Ja, hogy más grafikai különbség nem számít? De érdekes...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Atlas Fallen
És hol van a bizonyíték arra, hogy az AMD ezt kikötötte? Mert én csak annyit látok, hogy a Blizzard esetében elfogadjuk, hogy ez így jó, mert online játék, annak ellenére, hogy a grafikát másban nem korlátozzák, ami érthetetlen, de elfogadjuk, hogy ez így szabad döntés volt. De máshol meg nem fogadjuk el, mert miért is? Mert nekik kötelező volt, valami miatt nem szabad döntést hozni?
Persze, de ugye tudod, hogy három eljárásnak háromszoros a karbantartási költsége? Értem én, hogy szerinted belefér 80 dollárba per vásárlás, de sok vezetőség szerint meg nem. A bűvös szó itt a profitmaximalizálás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
És ebben hol van benne, hogy blokkolják? Mutass rá arra az angol szóra, ami lefordítható így magyarra.
#62592 Petykemano : Nem érintett az FSR3-ban a Starfield. FSR2-vel érkezik. A Bethesda az Xbox GDK-t használja, nem a GPUOpen kezdeményezést, így nem tudja az AMD befolyásolni a Bethesda döntéseit, mert csak azokat az effekteket tudják használni a stúdiónál, amelyek az Xbox GDK-nak a részei. Ami nincs benne az Xbox GDK-ban, az nem is lesz benne a Starfieldben a startkor. A stratégiailag fontos címeknél nagyon koncentrál arra, a Microsoft, hogy minden ellenőrzött kód legyen. Ezért is írják a tesztelők előzetesen, hogy kevés buggal találkoztak eddig.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62613
Abu85
HÁZIGAZDA
Komplikato
#62611
Abu85
HÁZIGAZDA
válasz
Komplikato
#62611
üzenetére
A Starfield az más. A Bethesda és a Microsoft nem FSR partner. Ők a Microsoft GDK-ját használják, tehát a Microsoft eljárásait tudják hozni PC-re. Ezért kap FSR2-t. Az FSR3-at a technológiai partnerek kapják meg, tehát azok a stúdiók, amelyek a GPUOpen még fejlesztés alatt álló effektjeire szerződtek. A Bethesda ezekre nem szerződött, csak használnak dolgokat, amiket elérnek a GitHubon, vagy a GDK-n belül. Később szerződhetnek még FSR3-ra, de azt külön kell majd implementálniuk, mert nincs benne a GDK-ban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62673
Abu85
HÁZIGAZDA
Alogonomus
#62659
Abu85
HÁZIGAZDA
válasz
Alogonomus
#62659
üzenetére
Az Immortals of Aveum esetében azért van sok ghosting, mert egész új DLSS3-at használ. A fejlesztők szerint a régebbi verzió csökkenti a jelenséget. Igazából a hiba komplex, de ismeri az Epic és az NV is, tehát javítható. Az kérdés, hogy mikorra. Nyilván az UE5-ös játékok esetében vissza lehet nyúlni az 1.x-es frame-gen verziókhoz, az eléggé csökkenti a jelenséget. Az újabb frame-gen verzióknál ezzel nem lehet mit kezdeni, amíg az NV nem hozza rendbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez azért nem jó dia, mert az RDNA 3 más cache-t használ, mint az RDNA 2. Utóbbiba konkrétan a Zen 3 L3 cache-je van átrakva. Az RDNA 3-ban már GPU-ra áttervezett victim dizájn van. Tehát az RDNA 3-nál a cache-hit nagyobb még kisebb kapacitással is. Egyébként a 7900 XTX-nek 2,7 TB/s körüli a sávszélje.
Ez nem ilyen egyszerű, hogy cache=cache.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62835
Abu85
HÁZIGAZDA
Petykemano
#62833
Abu85
HÁZIGAZDA
válasz
Petykemano
#62833
üzenetére
Igen. Az AMD kényszerítette az NV-t, hogy 192 kB helyett 64 kB-nyi regisztert építsenek a vektorok mellé.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62837
Abu85
HÁZIGAZDA
Petykemano
#62836
Abu85
HÁZIGAZDA
válasz
Petykemano
#62836
üzenetére
Nem hasal el a konkurens hardveren, de kb. a Maxwell óta az összes architektúratesztünkbe beleírjuk, hogy a GeForce-ok regiszterszegények. Ez pedig kedvezőtlen lehet olyan környezetben, ahol a kód annyira komplex, hogy magas regiszternyomás mellett működik, ezt megmondtuk előre. Nyilván előbb-utóbb számítani lehetett rá, hogy jön egy olyan játék, ahol hátrányt szenved az NVIDIA amiatt, hogy grafikai számítások szempontjából fontos helyről spórol ki tranzisztorokat azért, hogy tensor magokra költse el azokat. És mivel ennyire különböznek a dizájnok, így lesznek olyan játékok, amelyek az NVIDIA dizájnját jobban fogják szeretni, lásd Portal RTX, és ugye lesznek olyan játékok is, amelyek az AMD dizájnjához illeszkednek inkább, lásd Starfield. Ha ennyire mások az architektúrális limitek, akkor ezek bizonyos helyeken ki fognak ütközni, és lesznek majd extrém végletek.
Egyébként meg a Bethesdának nincs oka rá, hogy rosszul fusson a kód GeForce-on. Annyira optimalizálták azt, amennyire az architektúra a limitjei mellett ez megoldható, de azzal nem tud senki sem mit kezdeni, ha hiányzik az erőforrás a hardverből. Ezzel az NVIDIA tud majd mit tenni a következő generációban, hogy 64 kB helyett 128 vagy 192 kB-nyi regisztert használnak per SM. Az a baj, hogy ezt kód szintjén is nagyon nehéz optimalizálni, mert itt adatról van szó. Nem tudod tömöríteni, ha pedig kevesebb adattal dolgozol, akkor butítod a grafikát, de erre egyébként ott vannak a játékban a sliderek, lehet kérni low-medium presetet is, azokban egyébként sokkal kellemesebb a GeForce-ok működése, mert ott a regiszternyomás nem olyan magas, így nő a hatékonyság. Tehát a Bethesda gondolt arra, hogy ha a hardver nem elég potens, akkor keressél olyan beállítást, ahol jobban működik.
A legnagyobb baj igazából az, hogy a két hardveres véglet között jelenleg túl nagy a különbség, nincs az az optimalizálás, ahol ellensúlyozod a 64 kB limitjét, ha a másik dizájnban meg 192 kB-od van ugyanarra a problémára. Tehát vagy számolsz vele, hogy beleférjen a shader maximum kihasználtság mellett a 64 kB-ba, és akkor grafikailag nem használsz sok adatot, így butítod a képi világot, vagy túlléped az említett kapacitást, és akkor meg nem férsz bele a 64 kB-ba, így jön a limit a wave-ekre. Ez egy eldöntendő kérdés, a Starfield azt választotta, hogy túlmegy, és akinek nincs elég jó hardvere, majd maga csökkenti a grafikai minőséget a beállítások menüben. És a kevésbé jó hírem, hogy valószínűleg egyre többen fogják azt választani, hogy túlmennek ezen a limiten, mert a konzolokban is van 128 kB erre. Miért is ne használnák legalább azt ki? Mi oka van egy fejlesztőnek arra, hogy ha megvan a konzolokban az erőforrás, akkor annak a felét kihasználatlanul hagyják? Az előző konzolgeneráció? Már nem fejlesztenek rá, nem kell foglalkozni annak a limitjeivel. A PC? Ott ha nem elég jó a hardver, vissza lehet venni a grafikát. Tehát akkor miért is kellene limitálni magát egy stúdiónak? Mert az NVIDIA nem rakott elég tárkapacitást ide? Miért nem raktak bele annyit? Több milliárd szabad tranzisztort kapnak ehhez, ha a Tensor magokat kihagyják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az ML Based Super Resolution az nagyon messze van attól, amit a DLSS csinál. A DLSS valójában nem használ AI-t a rekonstrukciuóhoz. A Microsoftnak volt régebben egy saját technológiája, amit fejlesztettek, és az már a rekonstrukcióhoz is AI-t használ.
A mostani felskálázások iszonyatosan messze vannak attól, ami az új gépekkel elérhető, de ugye az új gépekben van is erre szabott NPU.
Az AMD függés nem módosulna az ARM-tól, hiszen az AMD is tervez ARM magokat. De ugye látod is, hogy a Microsoft nem is gondolkodik abban, hogy szakítsanak az AMD-vel, mert mindenképpen velük akarják terveztetni. Valószínűleg nagyon kritikus számukra a kompatibilitás.
[ 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
S_x96x_S
#62856
üzenetére
A Windows on ARM enélkül is megoldható...
Az AMD-vel való tárgyalások már ott elúsznak, hogy az IGP-nél vagy AMD-t kérnek, vagy AMD-vel közösen terveznek. Ez már kizárja az alternatív gyártókat.
Az nagyon drága lenne... A Nintendo túl sok pénzen ül, így nagyon sokat kellene fizetni a cégért, miközben az IP szintjén nem is érnek annyit. Ez maximum elgondolás volt, de nem realitás.
Gyártatni gyártathatnak az Intellel, de annyira egymáshoz kell tervezni manapság a CPU-t és az IGP-t, hogy ugyanaz a cég fogja megkapni a feladatot.
#62857 Petykemano : Mert le kell tervezni az egyedi hardvert azért. Attól, hogy papíron elgondolod mi lesz benne, még nem fog mágikusan megjelenni előtted a termék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62860
Abu85
HÁZIGAZDA
szmörlock007
#62859
Abu85
HÁZIGAZDA
válasz
szmörlock007
#62859
üzenetére
Tévedés. A konzolokban nem RDNA 2 van. Hanem egy custom RDNA.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62863
Abu85
HÁZIGAZDA
szmörlock007
#62861
Abu85
HÁZIGAZDA
válasz
szmörlock007
#62861
üzenetére
Így igaz, de ehhez az kellett, hogy a közös alapokból két eltérő dizájn készüljön. Tehát lehet, hogy mindkettőben van RT mintavételező, de nem ugyanazok az egységek vannak benne, mert két külön csapat tervezte ezeket. Sőt, még a Sony és a Microsoft lapkáiban is más az RT mintavételező, tehát még a két gyártó között is van eltérés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62865
Abu85
HÁZIGAZDA
Petykemano
#62864
Abu85
HÁZIGAZDA
válasz
Petykemano
#62864
üzenetére
Eleve nem biztos, hogy 2026-ban lesz Zen 6 és RDNA 5. A Zen 5 reálisan 2025. Az RDNA 4 is. A Zen 6 és az RDNA 5 inkább 2027. Nagyon rohangok előre ezekkel a generációváltásokkal és nem veszitek számításba, hogy egyre drágább a tape-out. Tehát egyre több idő kell, amíg egy generáció a költségeket kitermeli.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62867
Abu85
HÁZIGAZDA
szmörlock007
#62866
Abu85
HÁZIGAZDA
válasz
szmörlock007
#62866
üzenetére
Az AMD számára az Arrow Lake nem különösebben probléma, mivel ugyanúgy kompromisszumos hibrid dizájn. Az Intel akkor lesz újra probléma, ha hozzák a saját 3D stacking technológiájukat.
A VGA-knál lesz még egy-egy refresh kör.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#62897
Abu85
HÁZIGAZDA
Petykemano
#62896
Abu85
HÁZIGAZDA
válasz
Petykemano
#62896
üzenetére
Jack Huynh veszi át a helyét.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62927
Abu85
HÁZIGAZDA
Petykemano
#62923
Abu85
HÁZIGAZDA
válasz
Petykemano
#62923
üzenetére
Az FSR 3 az AMD szerint három modulra osztható. Egy felskálázó, egy késleltetéscsökkentő, és egy képgeneráló modulra.
A felskálázó az hasonlóan működik, mint az FSR2, csak etethető még pár extra adattal. Ennek két kódútja van, egy alap és egy gyorsított. A gyorsított kódút a packed mathot támogató hardvereken fut.
A késleltetéscsökkentő maga az Anti-Lag, és nem maga az FSR3 szállítja, hanem a meghajtóban van benne. Két külön kódút van, a sima Anti-Lag a régi Radeonoknak, és az Anti-Lag+ az RDNA3-as Radeonoknak. A többi gyártó hardverén ez aktiválhatatlan.
A képgenerálás az FSR3-ban van szállítva, és hasonlóan működik, mint az NV-nél, az előző két valós képkockából dolgozik és generál egy újat. Ennek négy különböző kódútja van. Egy a hivatalosan nem támogatott hardverekhez, ami a szabványos kódút. Egy az NV hardvereinek, ami szintén szabványos, de valamivel jobban működik, mint az általános. És két kódút van a Radeonokra, ebből a legjobb megoldást az RDNA 3 használja, a másikat pedig az RDNA 1-2. Az előállított minőség szempontjából ez a sorrend: szabványos kódút->NV kódút->RDNA 1-2 kódút->RDNA 3 kódút.
[ 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
Devid_81
#62904
üzenetére
Ennek egyébként oka van. A Luminous az FSR pilot partnere jelenleg, vagyis ők kapják meg legelőször a rendszert, mert együtt fejlesztik az AMD-vel. Ezért van a Forspokenben először FSR3. Az Immortals of Aveum pedig csak úgy hozzácsapódott a projekthez, mert az Ascendant problémákba futott a DLSS3 implementálásával. Nem igazán működik nekik a képgenerálás, és nem teljesen világos, hogy miért. Ezért meg akarták nézni az FSR3-mal, hogy náluk van-e a hiba, vagy az NVIDIA-nál. És ha már implementálták, ki is adják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez a végleges megoldás. Az fontos, hogy az FSR3 nem tartalmaz gyárilag késleltetést csökkentő modult. Ez teljesen külön van, és az AMD meghajtója szállítja. Ez sosem lesz az FSR3 része, mert koncepcióból nincs benne, ugyanis nagyon sok fejlesztő azért nem implementálja a DLSS3-at, mert a Reflexet nagyon nehézkes bizonyos motorokkal megoldani, és nagyon költségessé teszi az egész implementációt. Az FSR3 ilyenkor sokkal kisebb költség, mert nem kell foglalkozni olyan dologgal, mint a Reflex. Tehát ez szándékosan van így megoldva, míg az NV ezt megköveteli, felvállalva azt, hogy inkább nem implementálják a DLSS3-at. Valószínűleg ez ahhoz fog vezetni, hogy sokkal gyorsabb lesz az FSR3 terjedése, mert nincs benne egy nagyon körülményes követelmény a késleltetésre.
Amik fel vannak sorolva azok a képgenerálás problémái, nem specifikusak, hanem a manapság alkalmazott módszer mellékhatásai, amelyek megjelennek a DLSS3-on és az FSR3-on. Nem lehet mit tenni ellene, mert az a működési koncepció szüli a problémákat mindkét rendszernél, hogy visszatart egy kész frame-et, hogy generáljon egy kevésbé frisset. Ez nem bug, hanem fícsőr az NV és az AMD megoldásánál is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kínában mindenki le fogja építeni az R&D-t, mert nem tudnak úgy kutatni és fejleszteni, hogy az USA nem engedi bevinni oda a mintákat. Tök felesleges tökvakargatásra R&D részlegeket fenntartani, túl erőteljes az exportszabályozás, hogy bármit is lehessen egy ottani részleggel kezdeni.
Ez kb. hasonló helyzet, mint volt a múlt évben, amikor elkezdték kivégezni a cégek a hongkongi logisztikai központokat. Egyszerűen nem tudnak mit kezdeni velük, ha nem tudják odavinni a termékeket az USA exportkorlátozásai miatt. Az AMD és az NV is lelőtte ezeket a múlt évben. Hasztalanná váltak. Tekintve, hogy az USA-Kína kereskedelmi háború durvul, nem igazán lehet arra szépíteni, hogy a Kína elleni szankciók enyhülnek, így amit lehet le kell ott építeni, mert nem tudnak működni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az izraeli helyzet annyiban más, hogy oda nincs exportkorlátozás az USA részéről. Értem én, hogy háború van, de addig működhet az R&D, amíg a termékminták bevihetők, és nincs nagy pusztítás. Kína gyakorlatilag elveszett R&D szempontból azzal, hogy az USA ennyire nézi mi mehet oda és mi nem. Ezzel nem tudnak mit kezdeni a nyugati cégek, aminek a következménye az R&D leépítése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63061
Abu85
HÁZIGAZDA
Petykemano
#63057
Abu85
HÁZIGAZDA
válasz
Petykemano
#63057
üzenetére
Olyan jellegű frame generáló nincs, mint az AMD-nek és az NV-nek. Viszont van nekik felskálázójuk. kb. úgy működik, ahogy az FSR 1.0, az elvét tekintve, de gyorsabb.
Egyébként az FSR-ek papíron kompatibilisek a Qualcomm IGP-vel is. Bár a cég azt megjegyzi, hogy az FSR 2.0-tól kezdődő temporális módszer nem optimális a hardverdizájnjaikhoz. Az FSR 1.0 viszont jó hozzá, de inkább a saját megoldásukat javasolják, ami egy passból dolgozik, az jobban illeszkedik a hardverükhöz, miközben alig ad más eredményt az FSR 1.0-nál.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63097
Abu85
HÁZIGAZDA
Petykemano
#63096
Abu85
HÁZIGAZDA
válasz
Petykemano
#63096
üzenetére
A drivereknél ez bonyolultabb...
A gondot az jelenti, hogy a GCN különbözik az RDNA-tól. Tehát a shader fordítót érdemes volt szétválasztani. Új képesség úgy se jön a régi hardverekhez egyik oldalon sem, de az nem túl kedvező, ha a shader fordító mindig a legújabb dizájnhoz van szabva. Az negatív irányba viszi a régi hardverek teljesítményét. Ezért van most külön GCN és külön RDNA driver. Így ugye külön jellegzetességek szerint is lehet profilozni az új játékokat, amelyeket egyébként mindig a legújabb architektúrára szabnak, tehát a régebbi hardvereknél nem fontos, hogy a profil jó legyen, pont azért, mert meg se vásárolható a hardver a boltban.
Az NV-nek is gyorsabb lenne a shader fordítója, ha külön lenne választva a Maxwell, Pascal mert nem co-issue dizájnok, tehát a co-issue-ra optimalizált shader fordító nem jó rájuk. Működik, csak elég sok teljesítmény beragad. Viszont ott van a költség része is a dolognak, hogy két drivert külön fejleszteni drágább. Tehát az NV döntése is érthető az egységes meghajtóval.
Új profilok egyébként jönnek. Mi még szeptemberben leírtuk, hogy mi változik, csak a külföldi média most vette észre. [link]
[ 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
Devid_81
#63098
üzenetére
Nem kell. Láthatod, hogy minden driverből készül Vega verzió. A lényege a szétválasztásnak az, hogy ne RDNA-ra kigyúrt shader fordító fordítson Vegára, mert úgy teljesítmény marad a hardverben. Új funkciót így se úgy se kapsz. Nem fogod a GCN-RDNA különbséget egyszerűen áthidalni, miközben az RDNA-ra kell optimalizálni. Ez egy felfogásbeli különbség, ha van kellő pénz fenntartani két külön brach-et, akkor utóbbi hasznosabb, mert specifikusan hardverre szabható.
Ez nem Legacy support, ezt az AMD is hangsúlyozza. Így a cégnek egyszerűbb, bár valószínűleg jóval költségesebb, mert innentől kezdve minden driver tesztelése is hitelesítése dupla pénz. A maintenance valószínűleg kedvezőbb, mert szeparált a csapat, ami dolgozik a drivereken, így a hibák is specifikáltabbak.
[ 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
Busterftw
#63100
üzenetére
Nem. Ezt külön kihangsúlyozta nekik is az AMD, hogy ez nem Legacy státusz, és ezt látod te is. Ezt a változást szeptemberben vezették be, amikor megkérdeztük, hogy miért. És mondták, hogy szétválasztják a csomagot a shader fordító miatt. Egyszerűen nem tudnak elég nagy teljesítményt kihozni az RDNA dizájnra használt shader fordítóból a Vegákon és a Polarisokon. Ezzel nem tudnak mit tenni közös csomagként, mert maga a fordító szuboptimális a GCN-re. Máshogy működik az architektúra, mint az RDNA, van egy rakás variációs lehetőség benne, amire jól lehet optimalizálni, de ezek az optimalizációk semmit sem érnek a GCN-en. Ezért ezek nem is részei a régi batch-nek, helyette olyan optimalizálások vannak abban, amik a GCN-re jók, és az RDNA-ra nem. Nyilván ennek is megvan a maga problémája, mert két külön csapat kell, a fejlesztés, tesztelés, hitelesítés maga drágább, de tényleg hardverspecifikusabb, tehát több teljesítményt lehet kiszedni a régi dizájnokból azáltal, ha nem egy szuboptimális kódot kapnak végül.
És meg is nézheted, hogy ez így van, mert eddig minden egyes drivernek lett Vega és Polaris verziója, pont azért, mert ez nem Legacy support, ezt konkrétan visszakeresheted a driveres oldalon. A Legacy majd később lesz, amikor ezt megszüntetik, de most még nem teszik meg. Egyébként az AMD-nek olcsóbb lenne, ha egy driverben menne az egész, de benne maradna pár százaléknyi teljesítmény a régi hardverekben. Nem tudják kihozni, ha 5 generációval újabb dizájnra optimalizálják a fordítót. Ilyet senki sem tudna megoldani. A különbség annyi, hogy az AMD szerint felvállalható a szétválasztás extra anyagi terhe, míg más ilyenen még nem gondolkodott el. Ez már tényleg csak egy döntés, hogy ki mennyi pénzt akar terméktámogatásra áldozni. Nyilván az is számít, hogy az AMD-nek még vannak a boltban Vega dizájnjai az APU-kban, tehát számukra azoknál fontos, hogy jobb legyen a teljesítmény, míg mondjuk az NV-nek nincs egy Maxwell/Pascal dizájnja sem a boltokban, tehát annyira nem fontos, ha a co-issue lehetőségekre szabott shader fordítójuk nem dolgozik már rá. Buknak kb. 4-5%-nyi teljesítményt, na bumm, senkit sem érdekel, mert nem tudod már megvenni a boltban a hardvert.
[ 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
Lacccca87
#63102
üzenetére
Ez a fajta szétválasztott support pont drágább. Mert minden költséget megdupláz, hiszen két külön csapatod lesz, két külön kódbázis, két külön tesztelési procedúra, két külön hitelesítés és aláírás, tehát mindent duplán fizetnek ezentúl. Cserében kapsz pár százaléknyi extra teljesítményt a régi hardvereken.
Nyilván nem a Vega és Polaris VGA-kért csinálja az AMD, mert azok már nem megvásárolhatók. Azokra jó lenne egy szimpla egységes meghajtó is a maga szuboptimális fordítójával. A gondot a Vega APU-k jelentik, mert azokat még kapni. Azokra kell a support, és nehéz egységes kódbázisban megoldani, ha az új driver branch-ben minden RDNA-ra van szabva, ami nem jó a Vegának.
A CS2 egyszerű, mert van benne két API. Ha az egyik API-val van valami gondod, akkor válts a másikra. Kicsi az esélye, hogy ugyanaz a programhiba benne van mindkettőben elvégre ezek külön leképezők, és külön rutinok a driverben is.
[ 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
Busterftw
#63104
üzenetére
A terméktámogatás leállítása a Legacy státusz az AMD-nél. De az AMD külön kihangsúlyozta, hogy ez még nem Legacy. Vannak hozzá meghajtók. A 23.11.1-hez itt tölthetők le: RDNA, GCN és RDNA+GCN. Ez egyébként az átlag usernek talán elég bonyolult, a legegyszerűbb ezt a programot futtatni, ez a hardverhez való legfrissebbet ajánlja fel: [link]
A Legacy státuszú rendszerek az AMD-nél itt vannak: [link]
#63105 Lacccca87 : Sajnos ez nem ilyen egyszerű, mert a meghajtóknál a nagy pénzt nem igazán a fícsőrök fejlesztése viszi, hanem úgy 80%-ban a tesztelés és a hibakeresés. Ilyen formában ha különválasztod a branch-eket, akkor az mindig drágább, mert ha nem is írsz bele sokat, akkor is fizeted a külön humánerőforrást, ami karbantartja, plusz az aláírásokat, ami szintén nem olcsó. Ezért nem szokás különválasztani, mert drágább, és ritkán ad előnyt, és ha előnyt is ad, az sem sok. Ez tényleg egy felfogásbeli tényező, +5%-nyi teljesítményért, amit nyersz a jobb shader fordítóból nem szokás dupla pénzt fizetni a karbantartásért. Egyszerűen az esetek többségében nem éri meg a befektetett erőforrás. Az AMD-nek sem fogja szerintem sokáig megérni. Amint kikerülnek a piacról a Vega APU-k, dobják át a supportot Legacy-ba, mert a mostani megvalósítás költségesnek számít. És onnantól már tényleg olcsóbb, mert nem kell sűrűn meghajtót kiadni. Maximum évente-kétévente egyet.
A kettő API közül kell választanod. A Vulkan API-nak is megvannak a gondjai, de ha téged konkrétan a shader újrafordítások zavarnak, ami a DirectX 11 jellemzője, akkor arra egy olyan API a megoldás, ami ilyet nem csinál. Például a Vulkan. De ha abban zavar valami, akkor ott a DirectX 11, ami meg shader újrafordításokat csinál. Pick your poison... esetleg konzol, ott a gép binárist kap, vagyis nincs fordítás. De alapvetően a Valve azért támogat kétféle API-t, mert az egyes rendszerekhez más az optimális. A régiekhez inkább a Vulkan API az. Ha nem lenne az mindkettőnek itt-ott előnye a másikkal szemben, akkor nem lennének egyszerre szállítva és karbantartva a program oldaláról. A Valve alapvetően nem tudja eldönteni, hogy melyik gépnek melyik a jobb, de te eldöntheted.
[ 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
Lacccca87
#63108
üzenetére
Nem kell a Linuxhoz a Vulkan, ott van a DXVK. A Valve azért támogatja a Vulkan API-t, mert a DirectX 11-nek van egy olyan problémája, hogy szükségesen a shader újrafordítások az állapotváltásoknál. Ez egy API-limitáció, így van koncepcióból felépítve. A Vulkan API nem ilyen, és ott az ebből eredő akadásos problémák nem léteznek. Cserébe a programindításkor kell fordítani a shadereket, vagy pályabetöltéskor, stb.
Bármilyen hardveren ugyanúgy működik a DirectX 11. Ha megoldható lenne az állapotváltásoknál az újrafordítás nélküli működés, akkor nem kellett volna új API-t tervezni.
#63109 Busterftw : Nem jelentettek be semmit. Ez a változás szeptemberben született meg, akkor írtunk róla. Most csak leesett a média nagy részének, hogy valami történt. De az AMD ezt nem jelentette be.
A linkek jók, csak az AMD-nek úgy néz ki, hogy újabban védelme van a külső direkt linkelés ellen, így nem engedi letölteni ilyen formában. De ezt írja is az oldal, ami feljön.
[ 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
Busterftw
#63111
üzenetére
Ez szeptember óta nem változott. Az történik, ami szeptemberben történt.
Viszont az hazugság, hogy nem változott a driver. A szeptemberi verziószáma 23.19.02 volt, a novemberié 23.19.05.01.
A javítások pedig novemberben ezek voltak:
Megszűntek a Counter Strike 2 képi hibái Vulkan API-val
Az ACCA Software Edificius Architectural Design szoftverben kiválasztható a summary tableSzóval ez a szöveg: "Since then, despite two updates to the official branch, drivers for Polaris and Vega remain unchanged." - konkrétan és bizonyíthatóan hazugság!
Amiről te beszélsz azok a hardverek pedig itt vannak felsorolva: [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mit kellene orvosolni? A Sapphire Rapidsnak van egy rendkívül nagy előnye: az Intel sokkal olcsóbban adja nagy mennyiségben. Ezért termel nyereségben negyedannyit az Intel Data Center üzletága az AMD-hez viszonyítva. És ezen az AMD nem fog változtatni, mert így is eladják az EPYC-eket, és amíg eladják nagy profittal, addig nem térnek át az Intel-féle közel nullszaldós árazásra. Akkor sem, ha a Microsoft vagy az NV nem EPYC-eket rendel, majd rendel más cég.
[ 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
Albus_D
#63160
üzenetére
A jelentésekben az R&D költségek is benne vannak, azokkal nem tudsz marketingelni, mert nagyjából kiszámolható, hogy az összes R&D költség melyik üzletágakra hogyan csapódott le.
Az AMD a Data Centerhez számolja az MI300-at, ami elég sok R&D-t lekötött. Nem csak az EPYC van ott. És az MI300-nak van egy MI300A jelzésű verziója, ami nem tipikus gyorsító. Szintén a Data Centerben vannak elszámolva a ROCm költségek, amelyek eléggé emelkedhetnek a Xilinx felvásárlásával, hiszen be lesz olvasztva a ROCm-be a Versal támogatása.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az UE5 az nem a mostani API-khoz van kitalálva. Annak kell majd a Work Graphs, és ez egy csomó olyan funkciót ad, amitől az UE5 jobban működhet. Csak most ugye ezt nehéz értékelni, mert a Work Graphs shader modell 6.8-at követel, és ez még eléggé fejlesztői szintű dolog.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem rosszabbak, csak a Geekbench...
De egyébként gyorsabb lesz az AMD és az Intel új mobil platformja is az előző genes opcióknál. Erre már vannak gyártói tesztek. Viszont ezt Geekbenchben sosem fogod kimérni, mert maga a tesztprogram nem működik tesztprogramként. Egy csomó dolgot rá tudsz optimalizálni szoftverből, hogy nagyobb pontot kapj, és ezt a Geekbench fejlesztői leszarják.
Erről egyébként idén tavasszal volt szó az Intel egyik channel előadásán, hogy alapvetően a Geekbench semmire sem alkalmas, mert pusztán egy kis BIOS+driver reszeléssel +10-20%-nyi teljesítményt lehet csalással kiszedni belőle. És ezt a gyártók meg is csinálják, mert a Geekbench fejlesztői nem olyanok, hogy utánamennének a csalásoknak. Elfogadják azt, hogy ezek vannak, és csaljon mindenki. A probléma valószínűleg az, hogy az UL Benchmarks csalásellenes hadjárata egészen durván emészti a pénzt, és nincs akkora anyagi háttere a Geekbenchnek, hogy masszívan monitorozzák a gyártói csalásokat, mert nincs akkora bevételük, mint az UL Benchmarksnak.
Ha mindenképpen ilyen szintetikus méréseket akartok, akkor használjatok AIDA64-et.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert arra még nem tesztelték. Eleve a HAGS-nak a WDDM 3 után lesz értelme. Addig az csak egy használhatatlan fícsőr. Azért van ott, hogy a Microsoft telemetriaadatokat gyűjtsön a gépekről. Más haszna ma nincs. Akkor lesz haszna, amikor a WDDM átalakul úgy, hogy bevezetésre kerül a QoS. De ez leghamarabb a Windows 12-ben jön, sőt, az újabb hírek szerint megjelenéskor nem, hanem valamikor később, mert nem elégségesek még a gyűjtött adatok a gépekről. Ezért is rágja a Microsoft a gyártók fülét, hogy engedélyezzék, mert ha a telemetria nem tud adatokat gyűjteni, akkor csúsztatni kell a QoS bevezetését.
Ez a funkció egyébként arról szól, hogy két, GPU-t terhelő programot futtathatsz úgy, ahogy a CPU-kat terhelő programokat, de a QoS nélkül ez hasztalan, mert nincs mit ütemeznie a funkciónak, elvégre zömében egy játékot futtattok és kész. A HAGS azt teszi lehetővé, hogy 3-4, vagy 10 játékot futtassatok ugyanazon a GPU-n, miközben a teljesítményvesztés nem lesz aránytalanul nagy. Ez a funkció ezért teljesen félre van értve. Sokan azt várják tőle, hogy majd egy programban javul a teljesítmény, de valójában nem. A változás 1-3% között lesz egy program erejéig, vagy gyorsulásban vagy lassulásban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
De ezért sikeres a marketing. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- sziku69: Fűzzük össze a szavakat :)
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Nothing Phone (2) - több, mint elsőre látszik
- Milyen routert?
- Kínai, és egyéb olcsó órák topikja
- Milyen processzort vegyek?
- Star Trek Online -=MMORPG=-
- Apple notebookok
- Fotók, videók mobillal
- További aktív témák...
