Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Azt írja a teszt, hogy az FSR 3.1 min fut? Mert annak sem ugyanaz a képminősége az egyes VGA-kon, mivel négy különálló kódútja van. A legjobb képminőséget RDNA-n adja. Bár valószínűleg nincs akkora különbség, mint az XeSS-nél az XMX és a DP4a között, hiszen a kódutaknál csak konverziós eltérés van.
-
-
Abu85
HÁZIGAZDA
A gyártók és a stúdiók kiszámolják a képet teljes felbontáson. Ez nagyon fontos objektív adat, mert alapvetően az összes felskálázó torzít. Tehát a cél az, hogy a ground truth-hoz viszonyítva a torzítás minimális legyen. Jelenleg viszont nagyon érdekes, hogy egyre inkább a torzítás erősítése felé haladunk, tehát egyre messzebb kerülünk a ground truth-tól. A DLSS-nél például a DLSS 3 volt ehhez a legközelebb, az FSR-nél viszont az FSR 4 került közel hozzá. Az kérdés, hogy az AMD ezt merre viszi, mert ők is eltávolodhatnak a ground truth-tól, mint a DLSS, mert az van belenevelve a játékosokba jelenleg, hogy minél jobban torzít, annál szebb.
-
Abu85
HÁZIGAZDA
Egyébként ezt nem így szokták csinálni a gyártói felmérésekben, mert szubjektív tényezőnek ad teret. Az objektivitás miatt van még egy minta, ami a ground truth. Tehát az, hogy milyen, amikor tényleg kiszámolná a hardver a maximális felbontáson, amivel elméletben lehetne.
-
Abu85
HÁZIGAZDA
Mert a P-mag fogyasztása egészen magas szintre nőtt, és emiatt nem tudtak elég P-magot rakni a lapkába. Erre csináltak E-magot, ami jóval kisebb fogyasztású. Így keverik őket. Az AMD azért nem kezdte el, mert nekik a Zen magjuk fogyasztása relatíve alacsonyan van tartva. Kb. az Intel-féle P-mag felénél.
#51027 Busterftw : Az Intelnek a fogyasztása az kényszerű lépés. Nem azért szabják az új tokozást 700 wattos PL4-re, mert ez annyira jó ötlet, hanem azért, mert kiszámolták, hogy így lesznek ott teljesítményben, ahol a Zen 6 lesz 230 wattos PPT-vel, vagyis a PL4-gyel megegyező paraméterrel. Egyszerűen azzal, hogy elvették a magoktól a Hyper-Threadinget, az Intelnek minden szál mögé fizikai erőforrást kell raknia, és ez veszettül fogyaszt abban az esetben, ha mindkét cég 50 szál körülire tervezi a következő kört. Az AMD-nek a 48 szál mögé elég jóval kevesebb erőforrást építenie, mert van SMT-je.
Ezzel az Intel úgy 2030-ig nem fog tudni mit kezdeni, mert addig nem jön az új, Zen-szerűen tervezett mag.
#51026 proci985 : Az alaplapok esetében már most megoldják az alaplap gyártók azt, hogy az Intel lapokra más komponenseket szereznek be. Technikailag most is drágábbnak kellene lennie egy Intel alaplapnak a magasabb fogyasztási paraméterek miatt, de az Intel követelményei kevésbé szigorúak emiatt az AMD követelményeinél, így megengedik az olcsóbb komponenseket is. Ilyen szempontból tehát lesz mozgástere az alaplapgyártóknak.
#51032 Busterftw : 52-magos lesz a Nova Lake. Viszont itt a gyártók ezt nem magként értelmezik, hanem szálként, mert szálakon futtatod a folyamatokat. Ezért küld ellene az AMD 48-szálas Ryzent. Valószínűleg ha 48-magos Ryzen jönne 96 szállal, akkor a PPT fogyasztása úgy 450 watt lenne, ami még mindig kisebb a 700 wattnál, de láthatóan nőne. Viszont az AMD-nek nincs szükséges 48-magos Ryzenre ezen a szinten, mert nagy teljesítményű magokat terveznek ide.
#51034 paprobert : Nem fog az AMD ilyet csinálni, mert a Panther Lake előállítási költsége magasabb a Strix Halo dizájnnál is. Ez azért nagyon jelentős probléma lenne az AMD-nek, mert nekik az árrésük sokkal nagyobb az Intelnél, hogy reális nyereséget tudjanak termelni. Emiatt az AMD ide Strix Halo rendszert kínál inkább, amit drágábban adhat el.
-
Abu85
HÁZIGAZDA
válasz
proci985
#51020
üzenetére
A gyártási költség biztos, de valószínűleg azért tudnak rajta hagyni elég hasznot így is. Azért az AMD ma már jóval magasabb haszonkulccsal dolgozik, mint az Intel, így nyugodtan számíthatnak arra, hogy annyira magas áron fogja az AMD is adni a sajátját, hogy azt szimplán lekövethetik, és nem lesz veszteségük.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#51021
üzenetére
Ez nem ilyen egyszerű. Az Intel azért csinál most 52-magos CPU-t, mert nincs Hyper-Threading a P-magban. Tehát ahhoz, hogy nekik 48 darab szabadon felhasználható száluk legyen, fizikailag is kell ennyi P- és E-mag. Az LPE-magok ugye a rendszerfolyamatokra vannak, tehát azok ideális esetben nem kapnak a programoktól feladatot. Az AMD viszont tud csinálni 24 magból 48 szálat, mert nekik SMT-s a magdizájnjuk.
Tehát a programoknak rendelkezésre álló szálak számában ugyanott lesznek, csak az Intelnek ehhez fizikai magok kellenek, és nyilván ebben a formában a saját konstrukciójuk energiahatékonysága el fog maradni attól, amit el lehetne érni például Hyper-Threadinggel, ha volna. Valószínűleg ezért mondta Lip-Bu Tan, hogy ne foglalkozzanak a fogyasztással, mert most már kellene valami olyat mutatniuk, hogy teljesítményben nem az előző generációs AMD dizájnokat célozzák.
Tudtommal lesz az AMD-nek Threadripperje, nem a PRO, hanem a normál a következő körben, és abban 96 mag lesz, vagyis 192 szál, de annak a teljesítménye nagyságrendekkel jobb lesz. A TDP-jét 350 wattra tervezik, mert itt is limitál a platform, ami nem lesz új, csak a mostani alaplapokhoz jön egy új BIOS. Emiatt a 350 watt még mindig a Nova Lake TDP-je alatt lesz.
Ebből a szempontból egyébként az Intel kifejezetten realista. Tudják, hogy amíg kis-nagy magoznak, addig nekik el kell engedni a fogyasztást, mert a koncepció, amit alkalmaznak nem alkalmas arra, hogy hozzák a Zenek energiahatékonyságát. 2030-ra jön a váltás, amikor úgy fognak dolgozni, ahogy az AMD csinálja mag. Vagyis lesz egy alapmag, ami pont jó teljesítményű lesz, és annak lesz kétféle verziója, de ezek már fizikailag nem eltérő magok, csak eltérően lesznek implementálva, tehát az órajeltartományuk más lesz. Addig viszont marad az E-mag és P-mag, és az ezzel járó szívás. Azt is tudni, hogy az új, egységes magot azok tervezik, akik az E-magot, tehát az Intel a P-magot tervező csapatot feloszlatta. Ez szintén nagyon helyes döntés, mert a cég gondja alapvetően az, hogy a P-mag energiahatékonysága sokkal rosszabb az E-magénál.
Igazából az Intel gondja hasonló, mint az AMD-nek a Bulldozernél. Akkor az Intel fő előnye az volt, hogy egy maggal oldottak meg két szálat, míg az AMD fizikailag is dedikált feldolgozókat rakott a szálak mögé, aminek a hatékonysága rosszabb volt, hiába raktak a lapkába kétszer annyi magot. Az a helyzet, hogy a jelenlegi fizikai limiteket tekintve az az optimális, ha a szálak mögé nem mindig raksz fizikai erőforrást. Működni fog persze, ha megteszed, csak ahogy a Bulldozernél, illetve az Intel mostani hibrid dizájnjainál, a fogyasztása messze nem lesz arányban a leadott teljesítményével. És ahhoz, hogy tartsák a lépést azokkal a dizájnokkal, amik se nem lassú, se nem gyors, hanem pont jó teljesítményű magokat használnak, el kell engedni a fogyasztást.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#50981
üzenetére
A Socket AM5 tokozású AMD CPU-k PPT limitje 230 watt körüli. És itt nincs olyan, hogy ezt feloldhatnád, mert ez bele van tervezve a processzorba.
Mivel a Zen 6 is ugyanebbe a tokozásba jön, így ennek is ez lesz a felső határa. Az AMD-nek muszáj igazodniuk a mostani alaplapok specifikációihoz, nincs olyan mozgásterük, mint az Intelnek, hogy az új tokozással új határokat szabnak majd meg. Viszont ez az alaplapgyártók szerint nem jelent különösebb gondot, mert még 120 watton belül is képes tartósan 5 GHz-et hozni a Zen 6. Ez volt a projekt legfontosabb fejlesztése, hogy plusz 1-1,5 GHz-cel tudjanak gazdálkodni a fogyasztás növelése nélkül.
Az Intelnél a változást az teszi lehetővé, hogy egyrészt új tokozást hoznak, amire új specifikációkat lehet szabni, így el lehet vinni a követelményeket 700 wattig is, másrészt Lip-Bu Tan kiadta a parancsot, amikor még kinevezték, hogy nem érdekli mekkora fogyasztásból, de hozni kell a teljesítményt, mert az nem jó, hogy úgy néz ki az Intel a tesztekben, mintha egy-két generációval le lenne maradva. És ebben egyébként van ráció, mert a fórumokban jellemzően linkelt tesztekben nem mutatják azt, hogy mennyit fogyaszt az adott proci. Tehát az Intel simán megengedheti magának a 400 wattos TDP-t, amit terveznek az LGA-1954-re, szemben az AMD 170 wattjával, amit a Socket AM5 tartósan elbír. És elvileg az előzetes tesztekben ez elég jól mutat, mert a Nova Lake nagyon közel van a Ryzen 9850X3D-hez a játékokban, bár az alaplapgyártók szerint még nem veri meg, viszont ez tisztán abból eredhet, hogy a mostani Windows 11 ütemező nem kezeli jól a Nova Lake ötsebességes magcsoportosítását, amit az is mutat, hogy ha kényszerűen csak arra a négy egymás melletti P-mag klaszterre korlátozzák a futtatást, ami a leggyorsabb magcsoport akkor a hardver gyorsul, és így már pár százalékkal megveri a Ryzen 9850X3D-t is.
Ezt a részét majd nagyon sokat kell fejleszteni a Nova Lake-nek szoftveresen, mert teljesen más jellegű ütemezést igényel, ugyanis a Windows 11 arra van szabva, hogy két nagyon eltérő teljesítményű magcsoportot kezel nagyjából jól. Na most a teljes Nova Lake-ben lesz 4 LPE-mag, 16 alacsony prioritású E-mag, 16 magas magas prioritású E-mag, 8 alacsony prioritású P-mag és 8 magas prioritású P-mag. Ez annyira extrém kiépítés, hogy még a programok oldalán is módosítások kellenek, hogy jól működjön, tehát nem elég csak a Windows 11-et rászabni. Egyszerűen direkt támogatás kell, hogy a fejlesztő jelezze az OS-nek, hogy melyik feladatot melyik magcsoportra szánja, mert túl nagy a tévedés lehetősége.
-
Abu85
HÁZIGAZDA
Tudtommal - és ez eléggé jó helyről származó infó - az AMD kétféle CCD-t csinál a Zen 6-ra. Az egyik a normál Zen 6 CCD, amiben 12 mag és 48 MB-os L3 cache lesz. A másik elvileg a Zen 6c CCD, amiben 32 darab Zen 6 mag lesz, de nem tudni az L3 cache pontos kapacitását, viszont valószínűleg 64 vagy 96 MB lehet.
Ezek eltérő 3D V-Cache lapkát is kapnak, mert a mostanit mindenképpen át kell tervezni a Fan-out átalakítás miatt. Ezek pontos kapacitása sem ismert, de a kicsi verzióra 96 MB-ot, a nagyra pedig 256 MB-ot mondanak. Valószínű, hogy így jön ki a 2,5 GB-os L3 cache a HPC EPYC-re, amiről szintén van pletyi. -
#50735
Abu85
HÁZIGAZDA
szarnyasdino
#50734
Abu85
HÁZIGAZDA
válasz
szarnyasdino
#50734
üzenetére
Kérdeztem a PC-gyártókat erről, de azt mondta nekik az Intel, hogy nem lesz. Eredetileg gondolkodtak rajta, de a mobil piacra is nagyon kevés Panther Lake fog készülni, asztalra nem maradna semmi.
-
Abu85
HÁZIGAZDA
Ezen nem segít. A DLSS-nél az élesítő jó ideje nem a rendszer része. Erről a 2023-as év elején írtunk. [link]
Az eredetileg igaz volt, hogy az NV használt a futószalagon élesítőt, amit speciálisan erre terveztek, de kifejezetten rossz volt a működése, és nem volt értelme megtartani. A fejlesztők, amikor implementálták anno a DLSS-t, akkor ezt a részét helyből nullázták, és külön helyettesítették CAS algoritmussal, mert sokkal jobb minőséget kaptak tőle. Ezért döntött igazából úgy az NVIDIA, hogy akkor ez nem kell bele, mert csak a panasz volt rá. A NIS-t is azért ajánlják, mert az a saját különálló élesítőjük, de kb. minden nagyobb játékban az AMD-féle CAS van alkalmazva, mert jobban működik a NIS-nél. Nyilván ezt az NV nem mondhatja, hogy akkor használjátok az AMD kódját, de a szeparálás pont azt szolgálta, hogy akkor használja mindenki azt, nem kell ragaszkodni a NIS-hez. Emiatt van az, hogy a DLSS nem tartalmaz élesítőt, míg az FSR és az XeSS igen. Az AMD erre egy speciális RCAS implementációt használ, az Intel pedig alapjaiban az AMD-féle CAS, csak Arc GPU-ra optimalizálva.Viszont a DLSS 4-nél a homogén felületek jellegzetes kezelése nem az élesítő miatt van. Ha kikapcsolod, akkor is megmarad a művies hatás, mert maga a helyreállító algoritmus működik úgy, hogy a színben nem elütő képi tartalomba elkezdi belesúlyozni azokat a radikálisan eltérő színű pixeleket, amelyek szintén ott vannak a képen, akár a kép sarkán. Ez a globális konzisztencia okozza azt a fura jelenséget, amire PuMba rákérdezett, és hiába tologatod az élesítőt, nem függ a kettő egymástól. Ahhoz, hogy ez ne legyen a felskálázás része, a transformert kell kikapcsolni, amire például a Cyberpunk 2077 direkt lehetőséget is ad, mert tele van a játék homogén felületekkel, és más módon a fejlesztők nem tudták kezelni a gondot.
Hosszabb távon egyébként jó hír, hogy a Sony dolgozik egy megoldáson, ami direkt erre a problémára reflektál. Eredetileg a PSSR szintén transformer lett volna, de elvetették az ötletet, mert rosszul kezelte a homogén felületeket. Viszont az apró részletek helyreállítása kellene, tehát magáról a tervről nem mondott le a Sony. Amin most dolgoznak az egy frequency domain modell, és ennek pont az a lényege, hogy megmaradjon úgy a globális konzisztencia által biztosított jobb kontrol, hogy közben külön kezelje az alacsony és magas frekvenciájú tartalmat a képen. Ezáltal úgy állíthatók helyre a magas frekvenciájú apró részletek a képi tartalmon, hogy közben nem kell ennek a negatív hatását elszenvedni például az alacsony frekvenciájú bőrfelületeken. Valószínű, hogy rövidebb távon mindegyik felskálázó erre fog elmenni, mert csak nagyon kicsit kell módosítani a mostani hardvereken, hogy igazán hatékonyan fusson (a PS5 Prónak ez a multiprocesszorokat összekötő egyedi koncepciója például helyből alkalmas rá). Eközben megszabadulunk azoktól a képi torzításoktól, amik a mostani felskálázókat jellemzik.
Hosszabb távon egyébként van a Sony-nak egy másik kutatása is, de az szerintem bőven a PS6 érára van tervezve. Annak az a lényege, hogy maga a neuronháló tudja, hogy mi az anyag. Tehát effektíve fel tudja ismerni a képről, hogy az a terület rajta bőrfelület, amaz üveg, ez meg hó, stb. És eszerint konkrétan úgy tudja kezelni ezeket, hogy a helyreállított képen már azt is tudja, hogy a kép egyes részei hogyan viselkednek a fényben.
-
Abu85
HÁZIGAZDA
Én egy szóval sem mondtam, hogy a DLSS 4 rossz, csak azt írtam, hogy a jellegzetes hatásának megvan az oka, ami az elvi működéséből ered. És ez mint írtam nem élesség, hanem a transformer elvi működése által biztosított globális konzisztencia, ami a homogén felületeket túl műviessé teszi.
Az analitikai élesítők ilyet nem csinálnak, mert azok nem dolgoznak a teljes pixeltartományon, hanem van egy szűk tartományuk, implementációtól függően 6-8 pixel, és azon belül teszik a dolgukat. Ráadásul a modern élesítők még kontrasztadaptívak is, jó a NIS éppen nem ilyen, de a CAS például igen, tehát eleve nem torzít jelentősen.
#50660 Callisto : Kicsit vigyázzunk a RIS-szel, mert ha FSR 4-et használunk, akkor tuti RDNA 4-ünk van, és az hardverben implementálta a RIS-t, ami nem ugyanaz az algoritmus, amit a driverben szállít az AMD a többi GPU-ra. A hardveres RIS nagyrészt ugyanúgy működik, de nagyobb a feldolgozási tartománya, tehát az eredmény is jóval pontosabb. Ezért ez a driverben bekapcsolom a RIS-t nem általános érvényű, mert az RDNA 4-en ez számottevően jobb minőségű, mint bármelyik játékban szállított élesítő. A szoftveres megoldásokkal az a gond, hogy nagyon kell figyelni a kernel méretére, mert a sebesség szempontjából optimális, ha csak egy pass alatt lefut, tehát a feldolgozási tartomány méretét nagyban meghatározza az, hogy ne legyen túl regisztergyilkos. A hardverben implementált RIS konkrét célhardver, ott eleve úgy tervezheted magát a fizikai áramkört, hogy a feldolgozási tartomány legyen annyira nagy, amennyire kell. Itt nem számít a terhelés, mert úgysem a shadereket fut.
#50663 T.Peter : Abszolút, ha megpróbálod ugyanazt megcsinálni raszterben, amit RT-ben, akkor valószínű, hogy találsz rá valami trükkös megoldást, főleg a compute shaderek világában, de esélyes, hogy teljesítményben rosszabbul jössz ki vele. Viszont ez nem jelenti azt, hogy nem érdemes trükközni. Az Ubisoft külön csapatot tart arra, hogy kutassák az RT lehető leggyorsabb alkalmazási lehetőségeit. Például a Far Cry 6-ban példásan kombinálták a sugárkövetést a raszteres megoldással. Gyakorlatilag a visszaverődést úgy oldották meg, hogy amíg az minőségi hátrányt nem okoz, addig SSSR-rel működik, ahol pedig ez a technika nem működik jól ott RT-vel. Az eredmény rendkívül hasonló képminőség lett ahhoz, mintha csak RT-t használtak volna, miközben bő 50%-kal gyorsabb lett a hibrid megoldásuk. Ugyanezt eljátszották az árnyékokkal is, bár ott nem nyertek ennyit. Tehát az, hogy van RT nem jelenti azt, hogy nem érdemes optimalizálni és gondolkodni.
-
Abu85
HÁZIGAZDA
Ez nem egy élesítési probléma, hanem a transformer modell alapvető működéséből eredő jelenség, ami kivédhetetlen. Tudom, hogy látszólag élesnek tűnik, de nem az, a gond az, amit leírtam.
#50646 Ancsika99 : Nem lesz. Mint írtam ez pusztán abból eredő tényező, hogy a technológia elvi működése mellékhatásként előhozza a szóban forgó képi jelenséget. Ha az AMD vagy az Intel készít hibrid CNN+transformer modellt, akkor ott is bejátszik majd az az elvi működés, hogy minden elem figyel a többire a feldolgozás során, ami a kellemetlen mellékhatás konkrét okozója.
Ezt fontos megérteni, mert így látszik, hogy ez nem bug, hanem feature, még akkor is, ha nem kellemes a jelenség. Szóval ezt nem az NVIDIA rontja el, hanem az alkalmazott eljárás működési elve ilyen. Persze a transformert sosem képi feldolgozáshoz szánták, de elvi szinten lehetséges.
-
Abu85
HÁZIGAZDA
Igen. A Cyberpunk 2077 különösen érzékeny erre, mert nagyon sok homogén felületet használ a dizájnból eredő döntések miatt. Ezért ennél a játéknál a DLSS 4 többségében rosszabb, mint a DLSS 3, így nem akarták a fejlesztők a jobb minőségű variánst kiszedni.
És egyébként az NVIDIA ezt egyáltalán nem tiltja. Tehát nyugodtan lehet implementálni a DLSS 4 mellé a DLSS 3-at, ha a grafikai dizájnnak éppenséggel nem kedvez a transformer modell.
És fontos, hogy ez nem élesség. Annak tűnik, de nem az. Működésbeli koncepcióból eredő torzításról van szó. Ezért érzed azt, hogy a kép egyik részén ennek előnye van, máshol pedig kifejezetten hátrányos a hatás. És már az elvi háttérből tudni, hogy hol előnyös és hol hátrányos, amit a gyakorlat igazol. A Cyberpunk 2077 csak kifejezetten extrém eset a sok homogén felületével, az a DLSS 4-nek rendkívül káros, mert pont ott teljesít rosszul, amiben túráztatja a szóban forgó játék.
-
Abu85
HÁZIGAZDA
Ezt nem az NVIDIA csinálja, hanem maga az alkalmazott módszer. A hagyományos AI felskálázás CNN modell, ami a mintázatokat lokálisan értelmezi, és a felskálázáskor az előzményminták elemzésével végül meghatározza a magasabb felbontású képen a pixelek színét. Ha klasszikus AI felskálázásról beszélünk, akkor a teoretikus natív minőséghez ez lesz a legközelebb, mert a pixelek színének meghatározásánál csak a szomszédos adatok lesznek felhasználva.
A DLSS 4 már egy hibrid modell, ami alapjaiban CNN, de ki van egészítve transformerrel. A transformer egyik jellegzetessége, hogy nem csak lokálisan működik, hanem minden elem figyel a többire a feldolgozás során, ami például nagyon jól jön szövegfeldolgozásnál, vagyis chatbotokhoz, de nagyon kellemetlen dolog a képfeldolgozásnál, mert minden pixelt az összes többire vonatkoztat, aminek a kellemetlen és kivédhetetlen mellékhatása az lesz, hogy kiemeli a kontrasztos éleket és textúrákat.
Ez egyébként nem ismeretlen dolog, az NV is foglalkozott vele régebben. El is mondták, hogy értik ők is a hátrányait. Ergo pontosan tudták, hogy amikor ebbe az irányba elindultak, akkor a DLSS 3-hoz viszonyítva messzebb kerülnek attól az eredménytől, amit a teoretikus natív minőség jelenti, vagyis nem lepte meg őket, hogy a DLSS 4 jobban torzítja a végső képet.
Ami miatt ezt vállalhatták az az, hogy a CNN+transformer egy helyen jobb a hagyományos CNN-nél, mivel az elvi működése jobban kiemeli az apró részleteket. Viszont ezért cserébe számottevően torzítja a homogén felületeken, mint karakter bőre vagy ég, és végeredményben picit zajossá teszi a felskálázott képet.
Tehát az NV tud róla, hogy ez így nem jó, de nem tudják kiszedni belőle, mert a negatív hatások konkrétan az elvi működéséből erednek, és nem azért, és mert ezt így akarják.
#50633 FLATRONW : Nem, itt nem erről van szó. Az emberek csak nem tudják elég jól megfogalmazni, amit látnak. Valójában nem az élesítés a gond, mert nem élesít. Léteznek nagyon jó analitikai kontrasztadaptív élesítők, amelyek ezeket a jelenségeket elő sem hozzák. Amit kritikaként megfogalmaznak egyesek a DLSS 4 kapcsán, az abból ered, hogy a transformer elvi működése által biztosított globális konzisztencia a homogén felületeknek árt. Ez nem egy élességgel kapcsolatos probléma, hanem arról van szó, hogy a DLSS 4 egyszerűen az emberi bőrfelületet rosszabbul tudja felskálázáskor helyreállítani a DLSS 3-hoz viszonyítva, mert ezeknél a felületeknél az lenne a kulcs, hogy a pixel színét ne befolyásolja egy távoli, például a kép legszélén lévő fekete pixel, mert semmi köze hozzá. A DLSS 4 rendszerszintű koncepciója ezt a működésbeli hátrányt nem tudja eliminálni, mindenképpen lesz negatív hatása a homogén felületekre a nem lényeges pixeleknek.
-
Abu85
HÁZIGAZDA
válasz
Callisto
#50614
üzenetére
Gondolom euróra gondolt. Hiszen darabonként 22000 euróért árulják azt a három GeForce RTX 5090-et, ami raktáron van nekik. Valszeg az Alza is ezért tüntette el az eladó termékek közül ezt a modellt, ennyit nem adnak érte. Itt most marha nagy a buli, mert mindenki arra vár, hogy hol lesz az új ár, amit még éppen kifizetnek a kiskereskedők, miközben baromira kétlem, hogy ezekért a disztribútorok többet fizettek volna 2000 eurónál a gyártó felé.
-
Abu85
HÁZIGAZDA
válasz
S_x96x_S
#50587
üzenetére
Pont erre lenne jó bemutatni a módszertant, hogy láthassuk, hogy hol vannak a hibák a Steam felmérésében. De valószínűleg a Steam sem tudja, csak osztanak szoroznak tételeket. Ezért tud 50%-kal bővülni egy olyan VGA, amit nem is gyártanak. Most más szorzót használnak rá. Na de honnan az a szorzó? Miért annyi, miért változott?
#50583 DudeHUN : Ez nem akkora hiányosság. Az AMD pontosan 20:1 arányban gyártja a 9070 XT-t a 9070-hez viszonyítva. Tehát, ha tudod a sima számát, akkor megszorzod 20-szal, és megkapod az XT számát.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#50579
üzenetére
A tudomány maga a módszertan.
Én nem tagadom a tudományt.
A gaming valójában nem csak gaming. Lásd kínai AI farmok. Lehet, hogy a gamingbe van besorolva, de irtózatos mennyiségű GeForce-ot alakítanak át Kínában, ami megy AI-ba.
#50581 Busterftw : Persze, hogy felhozzuk, hiszen Kína konkrét gyárakat húzott fel arra, hogy gaming VGA-kat alakítson át AI-ra. Ez egy üzletág. Olyan mennyiségben csinálják, hogy simán kiteszi a gyártók gyártási mennyiségének a felét.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#50566
üzenetére
A pontos piaci arány nem megbízható a módszertan ismerete nélkül. Teljesen mindegy, hogy te erről mit gondolsz, mert ez egy tudomány, és a tudomány nem azt gondolja, amit te.
A példádnál pedig maga a trend, ami nem helyettesíti a módszertant. Ettől persze húzhatsz alufóliasisakot, de ettől még a tudományos tények melletted is létezni fognak, annak ellenére, hogy megtagadod ezeket.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#50562
üzenetére
Továbbra sem az a gond, hogy nem pontos, mert egyik statisztika sem az. Az a gond, hogy nem írja le a Steam a módszertant. Ha leírnák, hogy miképpen történik az adatok feldolgozása, hogyan illesztik rá a mintavételt a teljes felhasználóbázisra, milyen súlyozási eljárásokat alkalmaznak, mekkora a minta elemszáma és annak hibahatára, valamint milyen gyakorisággal és milyen szűrések után frissülnek az adatok, akkor az egy reális statisztika lenne.
Azt nem értik meg itt sokan, hogy itt a pontosság maga a módszertanból jön. Aki elmegy mondjuk az egyetemre statisztikát tanulni, az első dolog, amit megtanítanak vele, hogy egy mérés nem attól válik értelmezhetővé, hogy "nagy számok" vannak benne, hanem attól, hogy világosan le van írva a mintavétel módja, a torzítások forrása, illetve az alkalmazott becslés bizonytalansága. Ezek nélkül ugyanis nem dönthető el, hogy az adott statisztika reprezentatív becslés-e a teljes felhasználóbázisra, vagy csak egy önszelekcióval terhelt használhatatlan adathalmaz.
Amikor mi tanultuk ezt, akkor a tanár úgy fogalmazott, hogy ha a módszertan nem transzparens, akkor az adatok nem hibásak, csak nem verifikálhatók. Ezt arra a szabályra építette, hogy minden publikált mutatót csak a mögötte meghúzódó adatgeneráló munkafolyamat teljes ismeretében lehet értelmezni.
Jelen esetben nem az van, hogy elszart valamit megint a Steam Survey, hanem annyi történt, hogy azt se tudják egy ideje, hogy mit közölnek, ezért nem is látják, hogy hol vannak benne a torzítások. És ennek az oka, hogy nekik sincs erre semmilyen módszertanuk, ami a beáramló adatokat rendszerezné. És ez a gond, mert így a Steam annyit tud tenni, hogy széttárja a kezét, és azt mondják, hogy halvány fogalmunk sincs róla, hogy mennyi az annyi, de majd januárban rakunk arra az adatmezőre egy korlátot, hogy az összesítés ne lépje túl a 100%-ot. És ezért nem publikálnak módszertant. Nincs is nekik. Valószínűleg tele van konstansokkal szorozva az egész adathalmaz, mert már rég betorzította úgy önmagát, hogy 150-200%-okat közölhet minden kategóriában. -
Abu85
HÁZIGAZDA
Én nem akarok most lufizni, tehát arra nem reagálnék, de pusztán a TSMC szemszögéből az a fő gond, hogy ők ugyan biztosítják a gyártástechnológiát, de ezt ők is úgy teszik, hogy nekik is szükségesek a tömeggyártáshoz szükséges eszköz. Na most ezt ugyanúgy beszállítóktól szerzik, és a beszállítók által biztosított ellátás limitálja azt, hogy mennyire tud bővülni a gyártás. A legtöbb esetben azért, mert a TSMC és a modern chipgyárak által használt csúcstechnológiás berendezések összerakási ideje nagyon sok hónap. Tehát mindegy, hogy a TSMC lát-e az AI-ban fantáziát, az számít, hogy mennyi berendezést tudnak szerezni a partnereiktől a gyáraikba, és alapvetően úgy építik a gyárakat, hogy kb. minden elérhető eszközt megvesznek. Szóval itt egy beszállítói limit van, ami akadályozza a gyártókapacitás bővítését. És pont az a gond, hogy ezen a ponton nagyon nehéz növelni az ellátás sebességét, mert annyira bonyolultak ezek a berendezések, hogy iszonyatosan sok komponensből épülnek fel, és iszonyatosan fontos, hogy amikor leszállítják őket, akkor be legyenek állítva, szuperül működjenek stb. Tehát ez nem pusztán egy gyártási kérdés, itt azért nagyon komoly technikai személyzet van a háttérben, és az ultimate limit egy ponton az elérhető, kellően képzett humánerőforrás lesz. Ebből érthető szerintem, hogy ha a TSMC mondjuk azt mondja holnap, hogy kéne háromszoros kapacitás egy év múlva, akkor sem tudják megcsinálni, mert egyszerűen a legszűkebb keresztmetszetek már így is a limiten dolgoznak.
-
#50310
Abu85
HÁZIGAZDA
szarnyasdino
#50305
Abu85
HÁZIGAZDA
válasz
szarnyasdino
#50305
üzenetére
Doom: The Dark Ages
Indiana Jones and the Great Circle
Avatar: Frontiers of Pandora
Assassin's Creed ShadowsHirtelen ennyi most. Ezekben skálázni lehet, de kikapcsolni nem.
-
-
Abu85
HÁZIGAZDA
Ez azért eléggé bonyolult dolog az eltérő dizájnoknál. Az is számít, hogy az AMD a 2 nm-en csak a GPU chipletet gyártja, tehát van a dizájnnak pár egyéb komponense, amit más node-on készítenek. Tehát itt ez nem jelent automatikusan többet.
Általában az az ajánlása a TSMC-nek, hogy ha valaki CoWoS-t használ, akkor próbálja meg a dizájnját minél több lapkából felépíteni 3D-s tokozással. De csak azért, mert az egyes rétegek után ellenőrizhető, hogy az illesztés pontos volt-e, és ha nem, akkor az adott termékre nem is raknak új réteget, mert az úgyis kuka. Minél több rétegről és minél több lapkáról van szó, annál jobb a CoWoS kihozatala, ha a felhasznált chipeket tekintjük. Két lapkával és két réteggel például kifejezetten alacsony, 70% körüli. -
Abu85
HÁZIGAZDA
Ez specifikusan az OBS problémája. És látszik a képen, hogy nem is az encode hardvert terheli a feladat, hanem a 3D engine-t. Amiről viszont szó van azok a gyári szoftverek, amelyeket a gyártók fejlesztenek és csomagolnak a driverbe. Technikai megvalósításban messze ezek a leghatékonyabbak. Az, hogy az OBS ezekkel nem tartja a lépést azért van, mert az OBS egész éves büdzséje annyi, amennyit az AMD és az NV egy óra alatt elkölt driverre. Nyilván nem fognak tudni gyári színvonalat kínálni a technológiai megvalósítás terén. Nem is feltétlenül kapják meg ugyanazokat a lehetőségeket a gyártóktól. Ezért is jött a Vulkan video. Csak ez sosem lesz versenyképes a direkt hardvereléréssel, ami megvan az AMD-nek és az NV-nek. És igen, ennek lehet nagy ára a működésben, akár a VRAM kapacitását is jól lefoglalhatja. De ettől technikailag nem kell így lennie, csak nullához közelítő pénzből ennyire futja programszinten.
-
Abu85
HÁZIGAZDA
Ennek semmi köze a memória mennyiségéhez. Maga a streaming nagyjából 100 MB-nyi extra adat csak. Minden más már ott van eleve a VRAM-ban. A problémát nem a memória mennyisége adja, hanem a copy műveleteknél a rendszerek viselkedése, ugyanis máshogy terheli a PCI Express buszt az AMD és az NVIDIA dizájnja. Ahogy fentebb írtam a GeForce nagy copy műveleteket alkalmaz, és addig megszakítás nélkül csak azzal a művelettel foglalkozik, amíg be nem fejeződik, és ez egy nagyobb adatmásoláskor megakasztja a GPU-t. A Radeon burst rendszer, vagyis a teljes nagy műveleteket apró szeletekre bontja. Emiatt amint végez egy szelettel, rögtön be tud szúrni egy compute és/vagy egy graphics parancsot, így a GPU munkavégzése sosem áll le.
Tehát teljesen mindegy, hogy mennyi memóriával veszed a hardvert, az a 100 MB, ami kell némi extra adatnak nem oszt nem szoroz. A PCI Express busz van recording esetén aránytalanul terhelve, és ott a világ összes memóriája sem tud neked segíteni, mert maga a recording koncepciója az, hogy a tárolt adatot írd ki az adattárolára, tehát muszáj kimásolni.
Alapvetően az új generációban már nagyon jó minden szempontból a minőség, és a VRAM sem számít, hacsak nem rossz a program, amit használsz, mert ilyen is van. De ezért kínál gyári cuccot az AMD és az NVIDIA is, mert azok biztosan jók. Az egyetlen valós különbség, hogy másképp lassulnak a gyártók hardverjei, de ez is a PCI Express miatt van. És itt egyébként biztosan befigyel, hogy az 5.0 jobb a 4.0-nál.
-
Abu85
HÁZIGAZDA
A videós dologhoz hozzászólva: Arról van szó, hogy a felvétel maga a memória terhelésével jár. És ez ugyan nem túl nagy, de mindenképpen használja a copy motort a GPU-ban, tehát le fogja venni a teljesítményt ahhoz viszonyítva, mintha nem történne felvétel. Ezért történik meg akármilyen hardveren a sebességvesztés. Ennek a nagysága pedig attól függ, hogy a hardver copy motorja hogyan másol a PCI Express buszon, mert a rögzítés maga az adattárolón történik, tehát a képkockát ki kell menteni oda. Az pedig egy copy művelet. Átlagban nincs különbség a hardverek között, mert a copy-compute-graphics parancsok rendszerint jól ki-be tudnak jutni, de a copy parancsokat másképp kezeli az NVIDIA és másképp az AMD dizájnja. A Radeonok úgynevezett burstokban másolnak, vagyis a tartalmat szeletekben küldik át, állandó megszakítással, hogy ne foglalja le teljesen a PCI Express buszt a copy művelet. A GeForce-ok teljes másolási műveleteket hajtanak végre, vagyis addig nem tud semmi sem ki-be jutni a PCI Express buszon, amíg a copy művelet véget nem ért. Ez okozza azt, hogy a minimum teljesítmény beeshet GeForce-okon, nem magával a másolással van baj, hanem azzal, hogy amíg ez a másolás tart, addig nem kaphat parancsot a GPU, és ha nincs parancs, amit végrehajthatna, akkor a másolás végeztéig nem számol a hardver semmit. Ugyanez az oka annak, amiért a DirectStorage GPU kitömörítés átlag 10%-ot lassít a GeForce-okon, míg Radeonon lényegében semmit. Ott is a másolás lefoglalja a PCI Express buszt, és nincs megszakításra lehetőség. Csak DirectStorage-nél maga a másolás jóval nagyobb adattal megy, így ott már az átlagra is jelentős hatása van, nem csak a minimumra, mint a recording.
A videominőségnek ehhez semmi köze amúgy, a lassulásért kizárólag a copy művelet felel. A videominőség leginkább a beépített hardverelemtől függ, ami manapság egész jó mindkét oldalon. És ez alapvetően semmit sem lassít, mert egy külön célhardverről van szó. Minden lassulás a memóriamásolás miatt van, mert extra adat keletkezik, és azt mozgatni kell kifelé az adattárolóra. Emiatt a lassulás mértéke csökken, ha gyorsabb a PCI Express kapcsolat.
-
Abu85
HÁZIGAZDA
válasz
S_x96x_S
#50172
üzenetére
Itt azért annyi van, hogy az NVIDIA és a Google okkal nem ugrott GAAFET node-ra. Egyszerűen abban a méretben, amiben ők készítik ezeket a lapkákat muszáj 3 nm-en maradni. Az AMD sokkal több chipletből dolgozik, és számukra a fő lapka mérete fizikailag sokkal kisebb, tehát nekik nem nagy gond 2 nm-re ugrani, aztán abból raknak a tokozásra többet.
Hosszabb távon viszont mindenki GAAFET-re vált, csak ehhez előbb új chiplet struktúra kell a Google-nek és az NVIDIA-nak. Emiatt jön az MI500 egy évvel az MI400 után, mert az AMD-nek már kész van az MI300 óta ez a chiplet struktúrája. Nekik elég egy picike lapkát tervezni 2 nm-re, hogy teljesen új termékkel álljanak elő.
Ezért kár egyébként, hogy az Intel nem hozta a Falcon sorozatot, mert nekik is ilyen jellegű chiplet struktúrájuk lett volna, és ugyanúgy gyorsan tudtak volna fejleszteni, mint az AMD, mert a dizájn 70%-ához hozzá sem kellett volna nyúlni. Eközben az NV és a Google nagyon lassan tud mozogni, mert nekik a dizájnjuk 0%-a hasznosítható újra. És egyébként a Falcon az Inteltől jó lett volna, mert tudvalevő, hogy az AMD-nek az EPYC stratégiáját vették hozzá mintaként, hogy ezen a piacon megtréfáljanak az éves fejlesztésekkel mindenkit, kár érte.
-
Abu85
HÁZIGAZDA
válasz
#85757078
#49952
üzenetére
A figyelmeztetés az nem tiltás. És az AMD szerint még ma is vannak eladásaik az MI 308-ból Kínában. Majd ha hivatalosan megtiltják a cégeknek, hogy ezt rendeljék, akkor nem lesznek, de egyelőre nem tiltották még meg. A H20-at viszont teljesen megtiltották, ott már nem csak figyelmeztetés van.
Ha az AMD túl nagyra nő, akkor valószínűleg ellene is tiltást fognak kiadni, de még nem tették meg. Emiatt csak a H20 van kitiltva.
Valószínű egyébként, hogy a Hygon bonyolítja a helyzetet, mert az 49%-ban kínai tulajdon, és abba az IP-t az AMD rakja bele. Tehát van egyfajta fegyver az AMD kezében, hogy ha valami kellemetlent dönt a CCP, akkor ők meg majd nem folytatják a Hygon együttműködést. Ez azért fontos, mert a kínai, házon belüli adatközpontok 100%-a Hygon fejlesztésű. A Zhaoxin versenyez még ezen a területen az x86-tal, de a KH-50000 is Hygon licenc. Az AMD-t nehezebb lesz innen kirakni, mert van a kezükben valami, amitől a kínaiak még nem búcsúznának, mert nincs mivel pótolni.
-
Abu85
HÁZIGAZDA
A kínai dolog nem ennyire egyszerű. Itt a helyzet ott kezdődött, hogy az USA engedélyt adott az NV-nek és az AMD-nek a H20 és az MI308 szállítására, ha leadják az ezek eladásából származó bevétel 15%-át. Kína viszont erre rögtön azzal reagált, hogy megtiltották a kínai cégeknek, hogy vegyenek H20-at. Ezért csökkent az NV részesedése gyakorlatilag 0%-ra. Viszont azóta kiderült, hogy a kínai döntés csak a H20-at tiltja, az MI308-ra nincs még hivatalosan ilyen tiltás. Ezt az AMD szállítja is, bár valószínűleg fel vannak rá készülve, hogy ha nagyra nőnek, akkor őket is tiltani fogják, tehát nagy fókuszt azért nem helyeznek ide. De emiatt jelenleg csak az NVIDIA szorult ki, az AMD még nem.
#49945 Busterftw : Inkább nem tud vele mit tenni, mert egy dolog az USA exportkorlátozása, és akkor eladják Szingapúrnak, ahonnan majd becsempészik, és egy másik dolog, hogy Kína tiltja, amikor már a csempészés sem opció. Szóval nem esik nekik jól, és nyilván aggódnak is miatta, de kezdeni nem tudnak vele semmit.
-
Abu85
HÁZIGAZDA
Az OOO memóriaelérés raszterben főleg az ilyen mindenre jól optimalizált játéknál jelent előnyt, mert itt működik eléggé agresszíven a streaming és a LOD-kezelés, hogy számítson, hogy az adatok megérkezhetnek a hardver számára optimális sorrendben, és nem csak a kérések sorrendjében.
Valamekkora előnyt mindenhol ad az AMD szerint az OOO memóriaelérés, de itt a mérhető előny a kérdés, és ahhoz sok memóriaelérés kell, mert akkor lesz elég sok kérés ahhoz, hogy valós problémát jelentsen a kérések nem optimális sorrendje.
-
Abu85
HÁZIGAZDA
Kifejtem jobban akkor, amit a COD-ban látunk nem igazán hardveres eltérés. Részben az, mert számít a hardver, de a motor működését nézzétek. Három dolog jellemző az újabb IW motorokra.
- nagyon shader-gyilkosok, tehát iszonyat mennyiségű compute shader van bennük, főleg a post-process oldalon
- majdnem minden objektum vagy effekt más futószalagállapotot használ, amivel együtt jár a bitangsok különálló rajzolási parancs, és a sok százezer dinamikus shader
- kolosszális mértékű a dinamikus textúra streaming és a LOD váltások számaEzek egyébként főleg abból erednek, hogy maga a motor szinte teljesen dinamikus rendergráfot használ, ami még most sem jellemző a legtöbb másik motor esetében, a többség inkább amolyan féldinamikusabb rendszer, kellő számú statikus rendergráffal, hogy valamilyen mértékben korlátozzák a PSO-váltások számát. Tehát effektíve minden motor alkalmaz már dinamikus módszert, mert sok helyre ez kell, a kérdés inkább az, hogy mely renderszakaszok futnak még statikusan, például általában a G-buffer még ilyen, stb.
Viszont a DirectX 12 API-t alapvetően a dinamikus módszerhez tervezték, tehát bátran át lehet térni erre a leképezés egyes szakaszain, és a COD újabb motorverziói ezt nagyon ki is használják. A többi motornál még nem ennyire, de az irány az egyértelműen ez. A másik "nagyon dinamikus" motor egyébként még az Ubisoft-féle Anvil, ami az új verzióiban eléggé hasonlít a COD újabb motorverzióira.
Ha ilyen irányba megy egy motor, akkor az helyből magával hozzá azt, hogy majdnem minden objektum vagy effekt más futószalagállapotot használ, tehát megnő a PSO-váltások száma, a rajzolási parancsokat érdemesebb különállóan kezelni, stb. Ez a hardver tekintetében nem akkora gond, de a szoftver tekintetében már az lehet. Ugyanis minél inkább erre megy egy motor, annál inkább meghatározza a teljesítményt az, hogy a shadereket hogyan fordítja a driver fordítója, hogy a kódvalidálás mennyire gyors, hogy a rajzolási parancsok összességében mennyi DWORD-öt emésztenek fel, hogy az egyes parancsok betöltése mennyire blokkolja a GPU és a CPU feldolgozását, stb. Na most ebből a szempontból az AMD meghajtója eléggé egy versenyautó, egy csomó dolgot nagyon furán csinál a DX12 és a Vulkan alapimplementációját biztosító PAL réteg, ami nagymértékben javítja a teljesítményt, miközben elvben kevésbé biztonságos, de látszólag senkit sem érdekel, mert a programok így is futnak, miközben baromira gyors a driver, és átmegy a hitelesítési teszteken, tehát a Microsoft és a Khronos szerint valid eredményt biztosít. Az NV meghajtója valamiért túlbiztosított, ami azt eredményezi, hogy bizonyos helyzetekben egy banyatankos nagymama sebességével működik, de a programokat futtatja. És a legtöbb esetben ez jó, mert a tesztek úgyis 9800X3D-vel mennek, tehát a banyatankos nagyi tempó is eléggé el lesz fedve, mert kegyetlenül gyors a tesztproci. Csak ez nem minden játékban lesz igaz, mert a COD-ok és az AC-k már 9800X3D-vel is limitesek lehetnek. De ha az AMD kiadna mondjuk egy 9800X3D-nél kétszer gyorsabb procit, akkor ugyanaz lenne a COD-ok és az AC-k alatt is az erősorrend, mint a többi játékban, mert a kétszer gyorsabb szálszintű teljesítmény jobban fekszik a banyatankos nagyinak.
Egyébként ez az oka annak is, amiért a Microsoft-féle Advanced Shader Delivery kapcsán az AMD-nek és az Intelnek már tesztdriverük is van, míg az NV még csak azt jelentette be, hogy támogatni szeretnék majd valamikor. Az Advanced Shader Delivery pont arrafelé terelné a fejlesztőket, hogy nyugodtan menjenek a PSO-váltások növelése felé, az Advanced Shader Delivery megoldja az akadások gondját. Az NV tehát előbb-utóbb rákényszerül a banyatankos nagyijuk versenyautóra cserélésére, és valószínűleg már dolgoznak is rajta. Vagy ha még nem, akkor az Advanced Shader Delivery mindenképpen jelzés, hogy ezt nem tudják elkerülni, szóval el kell kezdeniük visszarakni a programozóikat az AI-ról a játékosoknak szánt driver fejlesztésére.Az RDNA 4 némi előnye pedig pusztán az OOO memóriaelérésből származik. Ez inkább COD-specifikus, mint általános dolog, ugyanis a COD-ok nagyon agresszíven streamelnek. Nagyon sok LOD szintet használnak, sok váltással, hogy gyors legyen a sebesség, ez különösen igaz a BO7-re. Persze ezt le kell tervezni, szóval nyilván a fejlesztés oldalon szopcsi, de megcsinálják, így senkit nem izgat, hogy erre mennyi erőforrást költöttek. Részben innen származik a sok PSO-váltásuk is. Na most a dinamikus textúra streaming és a LOD váltások ilyen mértékű száma mellett már masszív előnye lehet annak, hogy az RDNA 4-nek a memóriaeléréseket nem szükséges sorrendben végrehajtania. Erre a többi GPU nem képes, ezeknél a hardver alapvető működése múlik azon, hogy az adatok a kérés sorrendjében fussanak be, és az egyes wave-ek feldolgozása is csak ebben a sorrendben lehetséges.
-
Abu85
HÁZIGAZDA
És ezeknek nagyon egyszerű oka van, amikor a root signature-be kötik be az erőforrásokat, akkor azok nem megbonthatók, tehát az AMD kénytelen nagyobb csomagokat készíteni, ami így erősebben terheli a saját koncepciójukat. De a játékok 99%-a nem ilyen, már csak azért sem, mert a root signature-be való bekötést, maga a Microsoft nem ajánlja. Például az Atomfallt külön emiatt módosították, mert instabil működést okozott, hogy nem úgy használta a DirectX 12-t, ahogy azt előírta az API tervezője.
De valóban igaz, hogy ha nem úgy használod a DirectX 12-t, ahogy a Microsoft előírja, az a pár játék, az valóban jobb az NV és az Intel driverével, mert az AMD drivere a DirectX 12 játékok 99%-ára van tervezve.
-
Abu85
HÁZIGAZDA
Annyit hozzátennék, hogy az egyes gyártók között az egységes API-k mellett is nagyon eltérő a Vulkan és a DirectX 12 implementációja. Sőt, az AMD-nél nincs is külön implementáció, egy közös PAL rétegen keresztül kezelik mindkét API-t, és csak a különbségeket menedzselik az ICD réteggel.
A lényeg az, hogy részben hardveres sajátosságok miatt más az egyes erőforrások kezelésének és menedzselésének menete, ami nagyon röviden így néz ki:
Az NVIDIA még az explicit API-knál is erőteljesen épít egy úgynevezett push bufferre, ami azt a célt szolgálja, hogy a lehető legtöbb metaadattal lássák el a hardvert, miközben ritkítják a futószalagok kiürítésének számát. Ennek az ára a nagy memóriaigénye, illetve a CPU oldalán több munkára van szükség, hogy a driver push bufferét megfelelően menedzseljék. A bekötés tekintetében pedig az NVIDIA előre gyorsítótárazza a leírótáblát, és utána ezt csak szükség esetén módosítja. Ez megint több memóriát és CPU-időt eszik, viszont az állapotváltások minimalizálhatók, amire eleve haknis az a fajta működés, ahogy az NV drivere feldolgozza az adatokat.
Az Intel sok tekintetben épít a CPU-ra. Amit csak tud a CPU állít össze, és a GPU-nak elég csak beolvasnia. Nagyon sok munkát megspórol így maga a GPU, mert kész futtatandó assemblyket kap a CPU-tól. De mivel ez így működik, nehéz batch-elni, és egy rakás dekódolási munkával jár már a CPU oldalán, hogy a GPU dekódolási munkája megelőzhető legyen, ami nagyobb többletterhelést ad.
Az AMD épít a legkevésbé a CPU-ra, mert maga a PAL úgynevezett leírócsomagokat dolgoz fel. Ez nincs külön kezelve az API-kban, de maga a Mantle eleve olyan jellegű feldolgozással készült, amilyen jellegű nagyvonalakban a DirectX 12 és a Vulkan, és emiatt a két szabványos API-ba is beletervezték az egyes erőforrások feloszthatóságát. Mondhatni ez egy Mantle örökség, amit a Microsoft nem vett ki a prototípus kódból, és a Khronos is továbbvitt, hogy a hardver számára optimalizálható legyen a valós feldolgozás, miközben az API maga a finom részleteket elmaszkolja. Az AMD drivere tehát majdnem mindent ilyen leírócsomagokban kezel, és ezek a csomagok elképesztően picik, miközben teljesen függetlenek egymástól, tehát nem számít, hogy esetleg két csomag nagyobb műveletet bont meg, azokat a hardver össze tudja rakni belül, ha a két csomag megérkezik számára. A drivernek csak azt kell menedzselnie, hogy a két csomag egymás után fusson be. Mivel így minden munkamenet nagyon picire van szabva, a processzoridő is elég kevés lesz velük. Ráaádsul a sok eltérő csomag miatt nagyon párhuzamosítható az egész, szépen lehet osztani a munkát 4-5-20-30 magra. Utóbbi a kulcs az AMD-nél, mert nem azért olyan hatékony a drivere, mert valami elképesztően szűkre van szabva a munka. Ők is használják a CPU-t rendesen, csak nagyon párhuzamosítva, hogy a kis csomagok feldolgozása jól menedzselhető legyen, jól be lehessen illeszteni ezeket a meglévő magok szabad kapacitására.
A fenti különbség felel azért, amit láthatunk a tesztekben, ha gyengébb CPU mellé kerülnek a hardverek. Például egy tipikus hatmagos CPU egyik nagy hátránya az, hogy mindenképpen lesz egy-két mag, ami jobban lesz terhelve. Ez nagyon tipikus a többszálú feldolgozáskor. És a program terehelése mellett még az NV és az Intel drivere is főleg egy-két magot terhel, mert nagyobb munkákat csinálnak meg. Az AMD előnye itt onnan ered, hogy a driverük nem terhel be nagyon egy-két magot, hanem szépen szétosztja a munkát az összes mag között. És ezért lehet látni azt például a HUB overhead tesztjeiben is, hogy mennyivel jobban bánik a CPU-idővel, mert gyengébb CPU-val sem jön erőteljesebb CPU-limit.
-
#49861
Abu85
HÁZIGAZDA
huskydog17
#49856
Abu85
HÁZIGAZDA
válasz
huskydog17
#49856
üzenetére
Te tényleg nem tudsz olvasni? Nézd már meg, hogy mit írtam.
Az Intel csinált egy alternatív stratégiát a különböző, GPU-nak küldött csomagok kezelésére. Ez ugyanis sokszor nagyon rossz volt az egyes API-kon. És ennek az oka részben hardveres, egészen pontosan azért mert sosem PCI Expressen való bekötésre tervezték a GPU-t, de részben szoftveres, mert amikor ezt a részét írták a drivernek, akkor sem gondoltak még arra, hogy valaha is PCI Expressen keresztül kötik be a GPU-ikat. Ez a szoftveres rész átírható, még a hardveres tervezés ellenére is, mert csak amiatt olyan amilyen, hogy eleve nem volt korlátként kezelve a PCI Express busz, mert nem is volt az IGP-knél. Most viszont van, és lehet hozzá igazodni. Ezt csinálja a driver, másképp küldi be a csomagokat, így azok szép ciklusosan lesznek feldolgozva a parancslistából. Nem nagyon fordulhat elő az a szituáció, hogy felhalmozódás történik, ami például a kapcsolódó gondok gyökere.
És azért csinálja ezt az Intel, mert a Battlefield 6 például nagyon másképp működik, mint a korábbi Battlefieldek. Erről nyilván tudtak már hónapok óta, és látható is, hogy például ez a játék még 9800X3D mellett is CPU-limites tud lenni. Ezért van az, hogy amikor előhozol egy erőteljes parancsgenerálós szituációt benne, akkor a Radeon 9070 XT bárminél több fps-t tol ki. Nem a GPU a gyorsabb minden más GPU-nál, hanem az AMD drivere dolgozza fel a rajzolási parancsokat sokkal gyorsabban. Emiatt van az, hogy ha mondjuk egy átlagosabb CPU mellé teszed a Radeon RX 9070 XT-t, teszem azt egy tipikus hatmagos Core vagy hatmagos Ryzen mellé, akkor ennél a GPU-nál nem tudsz gyorsabbat venni a piacon, ha az adott játék CPU-limitessé válik. Mert ilyenkor nem a hardver ereje a kulcs, hanem a driver hatékonysága.
A Battlefield 6 kifejezetten haknis erre, és emiatt az Intel GPU-i nem is nagyon kedvelték a bétát, de az új funkciókkal már jobban viselkednek. És lehet, hogy ezek az új funkciók most még fehérlistás, de mivel jóval gyorsabb a régi működési módnál, kellő tesztelés után ez lesz az általános mód, mert mindenhol gyorsít. Ezért mondta az Intel, hogy még csak per játék szinten működik, de nem mondták, hogy sosem fogják ezt engedélyezni általánosan.
-
Abu85
HÁZIGAZDA
És ezzel semmi gond nincs. Általában a befektetők kíváncsiak, hogy a változásért mi felelt inkább. És mivel pont egy négy éves cikluson volt a két konzol, így akkor került ezek ára új, alacsonyabb kategóriába, de nyilván az adott negyedévben jobban számított az, hogy sok Radeon RX 7000-et vettek az emberek.
Ezt félreérted. Az ember attól nem lesz hülye, hogy nem tud felbontást váltani. Egyszerűen csak nem olyan képzett felhasználó. Nagyon sokan nem képesek rá, és nyilván a piacnak a nagy része ilyen. Úgy kb. a 70-80%-a biztos. És aki erre nem képes, nyilván azt se nézi meg, hogy mit vásárol pontosan.
Nem tudom, hogy a driver hogyan lett idekeverve. Igazából az NV-nek volt vele problémája, de leginkább azért, mert egy nagyon-nagy váltás előtt voltak, és túlságosan sok hardvert szolgáltak ki egy csomagból. Egy ponton túl ez nyilván hátrányos, főleg úgy, hogy az NV még az egyes API-k implementációját sem költséghatékony módon oldja meg. Ez sok tesztidőt, sok erőforrást és sok pénzt igényel. Ha nem rakod mögé ezeket, akkor belefuthatsz olyanba, amibe az NV belefutott. De pár hónap alatt korrigálták a hibák nagy részét.
-
Abu85
HÁZIGAZDA
Nem az számít, hogy mióta vannak piacon a konzolok, hanem az, hogy mióta szállítják a partnereknek a lapkákat. Egy ideje tudható, hogy az AMD két éves ciklusokban korrigálja az árat. Tehát van a kezdeti ár, majd két év múlva csökken, majd megint két év múlva, és így tovább. És az első lapka leszállításától számítva mérik a két évet.
-
Abu85
HÁZIGAZDA
A konzolok esetében nem igazán az eladási mennyiség a fontos, hanem az eladási ár a lapkákra. Mivel az életciklus végén járunk, az AMD már a lapkákat is nagyon kevés haszonnal árulja, mivel már visszahozták azt a profitot, amire terveztek. Emiatt ugyanazt a lapkát jóval kevesebbért adják már el a Sony-nak és a Microsoftnak.
#49826 b. : Ez pedig régóta megfigyelhető, és semmi rosszindulat nincs benne. Még a gyártóknak is van erről statisztikájuk. Például nagyon érdekes adat, hogy az AMD nem csinál olyan programot a driveréhez, ami az ügyfél helyett beállítja a program grafikai paraméterezését. És az oka ennek az, hogy a saját felmérésük szerint az ügyfeleik 72%-a erre önállóan képes. Az NVIDIA azért csinál ilyen programot, mert a saját felmérésük szerint 10 ügyfelükből 8 azt se tudja, hogy felbontást hogyan kell váltani. Az Intelnek van erre a legjobb arányuk, nekik a legtudatosabbak a felhasználóik, és ilyen szempontból a legképzettebbek.
-
Abu85
HÁZIGAZDA
Azt azért nem hiszem, hogy globálisan is kétszer annyi 9070 XT fogyna, mint 5070 Ti. Ugye itt figyelembe kell venni, hogy bolt válogatja. Nagyon fontos adat, hogy ki mennyire tudatos vásárló. Azok a boltok, amelyek megosztják ezeket az adatokat, főleg tudatos vásárlókra építenek, tehát olyan emberekre, akik nagyjából tisztában vannak a teljesítménnyel, olvasnak újságot, stb. És ezért nagyobb a Radeonok eladása itt. De például a diszkont-szerű boltokban már inkább a GeForce-ok eladása nagyobb, mert ott főleg nem hozzáértő emberek vásárolnak gépeket. Tehát a globális arány azért nagyon más lehet, mint ezekben a boltokban.
-
Abu85
HÁZIGAZDA
válasz
#85757078
#49810
üzenetére
Senki sem mondta, hogy nem jó, hiszen azt nézi, hogy mennyi VGA hagyta el a gyárakat. Tehát tökéletesen alkalmas arra, hogy felmérje, hogy piacot, de ha arra vagy kíváncsi, hogy mik vannak a gémerek gépeiben, arra nincs megoldása a JPR-nek, mert addig tudja nézni, amíg a dobozban vannak, és ha egy gyártó 70%-ban kínai AI adatközpontoknak adja a VGA-kat, akkor oda adja. Ugyanez történt a kriptovalutáknál. Ott is megvoltak az eladások, csak VGA-t nem látott senki a boltokban.
Ezért van az, hogy mást mutat a JPR, és mást mutatnak a boltok saját eladásai, akik elárulják, hogy miből mennyi fogy. De egyik sem rossz, csak más piacról szól. A boltokból nem igazán megy semmi a kínai AI-piacra, tehát egy elég nagy tétele a piacnak kiesik.
Azt kell megérteni, hogy a JPR és a boltok is igazat mondanak, tehát nincs a kettő között összeférhetetlenség, csak a boltokba az egyes gyártók VGA-inak 60-70%-a el se jut.
#49811 S_x96x_S : De a JPR nagyon is hitelesen kezeli ezt. Amit leírnak a teljes jelentésekben, az teljesen behatárolja, hogy mit és hogyan mérnek. Ebből a szempontból az eredmények, amiket közölnek hitelesek. Azért érzitek úgy, hogy nem valós, mert azt hiszitek, hogy csak a gaminget mérik, de valójában a VGA-piacnak csak egy része gaming, mert sok VGA megy kínai AI-ra. Ugyanez volt a kriptonál, ott láttuk az eladásokat, hogy megtörténtek, de nem láttuk a hardvereket a boltban. Tehát a JPR szépen lemérte, hogy a gyárból mi kerül ki, és azok 90%-a el is ment valamelyik bányászfarmra. De ettől a JPR statisztikája teljesen hiteles, csak akik azt várják, hogy a gamingről szól, csalódnak benne, viszont sose mondta a JPR, hogy ez csak gaming, nem tudják meghatározni, hogy a gyárból kikerülve mire használnak egy VGA-t. Ezt egyébként még egy bolt sem tudja meghatározni, ha eladnak egy terméket.
-
#49806
Abu85
HÁZIGAZDA
huskydog17
#49805
Abu85
HÁZIGAZDA
válasz
huskydog17
#49805
üzenetére
Ó anyám, ezt de félre tudjátok érteni, de jól van, a Youtube-on nem szakemberek csinálják a tartalmat, hanem hobbisták.
Akkor röviden, hogy mi a gond. Az egyes API-kon a parancsok kezelése nem elég egységes az Intel dizájnokon. Ez részben hardveres probléma, mert eredetileg úgy tervezték a dizájnt, hogy sosem lesz PCI Expressen keresztül bekötve, így nem foglalkoztak az efféle bekötés tipikus problémájával. Mivel azonban egy VGA így van bekötve, szembesülnek vele, így a jóval közvetlenebb integrációra tervezett architektúra egy rakás limitációba ütközik. Ezeknek a limitációknak egy része azonban tisztán szoftveres. Főleg abból származik, hogy a driver nem batch-csel elég agresszíven, így nem vonják össze elég hatékonyan a GPU felé küldött csomagokat. Ez felel nagyrészt a magasabb többletterhelésért, mert ez a fajta működés IGP szintjén lehet, hogy kb. jó, de PCI Expressen már nem az.
Amit az új driverek csinálnak, hogy szoftveresen jobban kezelik ezeket a parancsátadásokat. De ez nem alkalmazásspecifikus, maximum ez a működés nincsen minden alkalmazásra engedélyezve, mert tesztelni kell, hogy nem okoz-e problémát. De idővel a régi működés úgyis ki lesz véve, mert az teljesen felesleges, ha van mellett egy jóval gyorsabb működési mód. Csak előtte tesztelni kell ezt úgy százezer alkalmazással. Szóval nem, ez nem alkalmazásspecifikusnak készült, hanem alapvetően erre áll majd át a driver, viszont ehhez még bő fél év tesztelés kell, mire előszedik az összes alkalmazást, és megnézik, hogy jó-e az új csomagkezelés.A cégek a változásokat mindig így vezetik be. Előbb 10-20 alkalmazásban próbálják ki, majd a lista bővül 100-200-ra, aztán mind mehet, kivéve azok, amikkel van valami gubanc. Vagyis a kezdeti fehérlistás működést felváltja a feketelista.
-
#49804
Abu85
HÁZIGAZDA
huskydog17
#49803
Abu85
HÁZIGAZDA
válasz
huskydog17
#49803
üzenetére
De ez általános javulás. Nem is titkolja az Intel, hogy miért volt, még ha nem is jelentették be ezt hivatalosan. Majd írok róla nemsokára.
A Celestial szerintem az alapproblémával helyből nem fog küzdeni, mert az már a működés szintjén is dedikált GPU-nak készült. A jelenlegi és korábbi dizájnokban az alapproblémát az okozza, hogy alapvetően nem úgy készült az architektúra, hogy egy szűk buszon lesz bekötve.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#49801
üzenetére
Nem csak ennyi. A saját partnereikkel oké, de akik nem partnerek, azoknak nincs kötelességük beszámolni. Ezért ezt eléggé hosszadalmas felépíteni. Egyszerűbb lenne, ha az AMD, az Intel és az NVIDIA összefogna ebből a szempontból, mert akkor egymás partnereinek adatait elkérhetnék, de ezt jelenleg csak az Intel támogatná.
-
Abu85
HÁZIGAZDA
De a JPR az a gyárból kikerülő VGA-kat nézi. Nem tudják a gyártók, hogy azok egyáltalán eljutnak-e a boltokba. Persze valószínűsíthetik, hogy melyek azok a tételek, amelyek majd kínai AI-ban kötnek ki, de biztosan nem tudják, mert nem kérdezik meg a vásárlót, hogy hova viszi a négy-öt kamionnyi árút.
Egyébként a JPR is megjegyzi, hogy a bolti eladások ettől nagyon különbözhetnek, de a piackutatásuk helyes, mert leírják, hogy mit mérnek. Most attól, hogy a vizsgált tételek 60-70%-át sosem látják boltban? Hát... ettől még eladások a gyártók oldalán.
Egyébként az AMD már jelezte, hogy dolgoznak azon, hogy bolti statisztikát hozzanak erről, csak be kell kérniük ezt, hogy összesítsék, és globálisan azért elég sok bolt van.
-
Abu85
HÁZIGAZDA
válasz
#85757078
#49749
üzenetére
Sokat gyártanak, csak még mindig nagyobb a kereslet rá, mint amennyi készül. Erről pont az elmúlt héten kérdeztem őket. És igazából nem az a gond, hogy nem akarnak többet gyártani, hanem az, hogy egy VGA-nál az átfutási idő kb. négy hónap. Tehát ha most nézik a keresletet, és ahhoz igazítják a rendelést, akkor abból a kereskedők majd jövő februárban fognak érezni valamit. A mostani gyártási mennyiség pedig nyár elején lett meghatározva.
A másik gond, ami igazából véleményes, hogy gond-e, hogy az AMD-nél a gyártást az OEM igények és a kereskedői igények határozzák meg. Az NV-nél van egy extra tényező, a kínai feketepiac. És utóbbi kiszámíthatatlan, mert nem biztos, hogy a Kínába szállítók mindig elviszik a gyártósorról lekerülő GeForce-ok zömét. És ha valamikor nem viszik el, akkor azok ugye kereskedelmi forgalomba kerülnek, tehát a keresleten túli mennyiség kerül piacra, ami gyorsan az MSRP-hez löki az árakat. Ezt is kompenzálja az NV úgy, hogy a következő körre kevesebb GPU-t gyártanak.
Az induló készleteknek ehhez nincs már köze, mert az csak az első pár pár hetet határozzák meg. Azok már rég elkeltek.
#49750 Yutani : Ez egy érdekes tényező, de a valóság más. Valójában az a tapasztalat, hogy nem lenne sokkal nagyobb kereslet, ha olcsóbb lenne. Ezért határozzák meg a gyártási mennyiséget úgy, hogy mi az optimális mennyiség. Itt az jelzi a bajt, ha mondjuk egy termék az MSRP ár alá csúszik. Ez akkor történik meg, amikor a raktáridő túlmegy az elfogadható szinten, tehát már inkább szabadulni akarnak a porosodó VGA-któl, amiket nem tudtak eladni, mert egyre nagyobb költség ezeket tárolni. Mert ennek is van költsége, és ha mondjuk valami beragad, akkor pár hétre van attól, hogy ne legyen az eladásán nyereség. Ezért az se jó, ha kevés ideig van raktárban egy termék, mert akkor nagyobb az igény rá, és az sem, ha sok ideig van raktárban, mert akkor nagy a tárolás költsége.
-
Abu85
HÁZIGAZDA
Az MSRP ár megközelítését az határozza meg, hogy egy hardverre mekkora a kereslet. Ha az kielégíthető a legyártott mennyiséggel, akkor bizony az MSRP közelébe fog kerülni az adott VGA igen gyorsan. De ha nagyobb a kereslet, akkor erre nincs esély, mert nagyobb az igény a termékre, mint amennyit meg lehet venni belőle.
-
Abu85
HÁZIGAZDA
válasz
gejala
#49709
üzenetére
Semmi köze a drivernek az architektúra dizájnjához. Azért voltak és vannak driverproblémák, mert ugyanazt a munkát sokkal kevesebb ember végzi az NV-nél manapság, mert a rendszerprogramozók az adatközpontok támogatásával vannak elfoglalva. Ha ma is ott lenne a GeForce driverek mögött a korábbi évek humánerőforrása, akkor ugyanaz lenne a minőségi szint, mint a korábbi években. Ez teljese független az architektúrától, ezt az befolyásolja, hogy mennyi ember dolgozik rajta.
#49707 BerserkGuts : Ez meg egy teljesen független probléma. A GeForce RTX 50-nek nem optimális az az optimalizálás, ami 400-500 millió, játékosoknál lévő hardvernek pont jó. Nyilván nem az 1-2 milliós bázisra fognak dolgozni. Ezzel szemben az NVIDIA tehetetlen.
-
Abu85
HÁZIGAZDA
Ez az RTX 40 és 50 viszony pedig egy másik tényezőből ered. A legtöbb shadert olyan optimalizálással írnak, hogy jól fusson a konzolokon. Na most ezek a konzolok ugyan nem RDNA 2-k, de a wave feldolgozást tekintve az RDNA 2-höz állnak a legközelebb. És ez azért nagyon kellemes, mert van egy olyan működési módjuk, amire optimalizálva, az erre írt shaderek jól fognak futni PS5 és Xbox Series gépeken, Switch 2-n, RDNA1-4-en, GeForce RTX 20-30-40-en, tehát egyetlen egy optimalizálási stratégiával egyszerre lefedsz nagyon-nagyon sok hardvert. Viszont ez a módszer pont nem fog jól futni GeForce RTX 50-en. Ha viszont a Blackwellt célozzák, akkor meg az előbbi rengeteg hardveren nem fut majd jól a shader. Tehát a működést tekintve inkább azt a rengeteg hardvert célozzák, amely több százmilliós felhasználóbázist jelent. Ez sem magának a Blackwellnek a problémája hardveresen, csak annyira sok gépen fut jól az a shader optimalizálási stratégia, ami a Blackwellen nem annyira kedvező, hogy nem túl észszerű lépés 1-2 millió user érdekét 400-500 millió user elé helyezni. Az meg ki van zárva, hogy 300 ezer sornyi shadert kétszer írjanak meg, egyszerűen anyagilag nem kifizetődő.
-
Abu85
HÁZIGAZDA
Annyit még hozzátennék, hogy az nem igazán egy GPU-ból eredő dolog, hogy a 9070 a Borderlands 4, vagy az újabb UE5 motorú játékokban nem "csak" 7%-kal jobb az 5070-nél, hanem ~20%-kal. Itt inkább arról van szó, hogy maga az UE5 küzd egy erős limitációval, ugyanis a Nanite és a Lumen a jelenlegi compute shader paradigmát használva problémás, mivel CPU által kiadott, egymáshoz láncolt különálló dispatch-ekre épül. Ezek papíron ugyanazok gyártónként, de az AMD D3D12 drivere kevesebb többletterheléssel dolgozik, tehát igazából itt csak arról van szó, hogy amikor egy játékot ez a compute shader paradigma limitál a CPU oldalán, akkor a Radeonokat ez kevésbé limitálja. Tehát innen ered a különbség. Nem a hardver a jobb az AMD-nél, hanem a driver működik hatékonyabban. És minél inkább limites ebből a szempontból egy játék, annál nagyobb az AMD driveréből származó előnye.
De pont azért akar az Epic áttérni a Work Graphsra, mert még az AMD hatékonyabb driverével is létezik ez a limitáció, tehát maga a feldolgozási modell jellege a limites. A Work Graphs azért hasznos itt az Epicnek, mert ezzel a GPU önállóan tudja kezelni a függőségekkel rendelkező, egymásra épülő munkafolyamatokat, így nagyon lecsökken a CPU<->GPU szinkronizációk száma, tehát a többletterhelés ugyan létezni fog továbbra is, de a GPU kevesebb megszakítással dolgozik, amivel kevesebb driver- és API-hívás szükséges. Ergo megszűnik az a limit, ami most a nagyon sok CPU<->GPU szinkronizációkból ered.
-
Abu85
HÁZIGAZDA
Ez inkább egy döntés eredménye. Az Epic a múlt évben a Work Graphs felé indult, így arra készítik fel a motort, hogy idővel a Work Graphs egy alapértelmezett funkció legyen. Ehhez pedig a kutatásra használt gépekben Radeont használnak, vagyis egy ideje a döntéseket aszerint hozzák meg, hogy mit tapasztalnak RDNA 3-mal, és ez az RDNA 4-nek is előnyös. Aztán a többi hardverre utólag szoktak optimalizálni, ami még mindig nagyon jó, de nem ugyanaz, mintha már eleve dizájnban is erre terveznének.
-
#49663
Abu85
HÁZIGAZDA
huskydog17
#49661
Abu85
HÁZIGAZDA
válasz
huskydog17
#49661
üzenetére
Ne beszélj csacskaságokat, sehol sem volt megemlítve, hogy Borderlands 4 az NVIDIA hibája.
-
Abu85
HÁZIGAZDA
Ez így is van, de ugye itt alapvetően az a gond, hogy a DirectX 12-re és a Vulkan API-ra a fejlesztők nem tudnak önállóan optimális memóriamenedzsmentet írni. Ez most így persze nem akkora tragédia, mert az AMD-nek van mindkettőre általános menedzsmentre D3D12MA és VMA néven. Több száz játékban hibátlanul működik már. Viszont ez általános menedzsment, vagyis van némi követelmény az egyes erőforrások elérését tekintve, és az AMD a szabványos formát követi mindegyik API-n. Például követelmény, hogy erőforrás a root signature-be ne legyen bekötve. Ez egy hivatalos Microsoft ajánlás. Eközben az NV a saját modernebb eljárásaiban az erőforrásokat mindig a root signature-be köti. Na most a D3D12MA-nak ez nem jó, tehát le kell cseréni egy másik memóriamenedzsmentre. Viszont a Microsoft jó okkal mondja, hogy közvetlenül ne legyen erőforrás kötve a root signature-be, mert nem úgy tervezték az API-t, hogy ezt kezelni tudja, és problémákat okozhat, például akadozást. És ez egy nagyon régi vita az NV-vel, de az NVIDIA hajthatatlan évek óta, és akkor is úgy akarják használni az API-t, ahogy nem ajánlott a különböző problémák miatt. Volt már egyébként a háttérben arról szó, hogy egy új Agility verzió megszünteti a root signature-be kötés lehetőségét, de az meg kompatibilitási problémákat okozna, mert rengeteg szoftver dolgozik így. Emiatt a Microsoft még mindig csak szépen kéri az NVIDIA-t és a többi céget, akik ezt csinálják, hogy ha egy mód van rá, akkor ne legyenek hülyék, és kövessék azt az előírást, amire az API-t tervezték, úgy szép vajsimán, akadásmentesen fog működni a programkód.
-
Abu85
HÁZIGAZDA
Egyrészt rajta vannak, másrészt mindenen akadozik, harmadrészt rohadtul nem egyszerű javítani, mert kikerült a játékból a D3D12MA. És az okozza az akadozást, hogy áttértek egy saját memóriamenedzsmentre, ami több nagyságrenddel rosszabb, mint amit korábban használtak. Viszont a D3D12MA nem volt kompatibilis bizonyos NVIDIA technikákkal, amiket megkapott a játék, és utóbbiért az NV fizetett, hogy benne legyen, úgy is, hogy közben ez a GeForce-okon is akadozást okoz. Nem tud igazából mit tenni a cég, mert rengeteg pénzt kaptak azért, hogy az újítások benne legyenek, csak a D3D12MA ezekkel nem működik. És ennek a javítása hónapokig tarthat, de lehet, hogy évekig. Hacsak nem utalják vissza a pénzt az NV-nek, és nem térnek vissza a D3D12MA-ra.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#49620
üzenetére
Igazából a Mindfactory és a JPR is igaz. A Mindfactory a PC Gaminget mutatja a saját vásárlói szempontjából. A JPR pedig mindent, ami kijött a gyárból, még azokat is, amelyek Kínába kerültek egy AI adatközpontba.
Nyilván fontos figyelembe venni, hogy ki mit mér. Ki milyen adatra kíváncsi. Ha arra, hogy miből mennyi került ki a gyárakból, függetlenül attól, hogy hova kerültek, akkor a JPR adatja a jobb. Ha arra, hogy a játékosok miket vesznek helyi szinten, akkor ahhoz a Mindfactory adatja van közelebb.
Ugyanez volt a kriptoőrületnél is. Ott is rengeteg eladott VGA-t mért a JPR, csak a játékosok nem láttak belőle egyet sem. -
Abu85
HÁZIGAZDA
válasz
Busterftw
#49611
üzenetére
Az nem számít. A gond az architektúrával van, ami még mindig dedikált regisztereket rak az ALU-khoz. Akármikor is hozod ki a lapkát, akkor is megvan az a hátrány, hogy a konkurens feleakkora GPU-ját célozza csak az adott dizájn teljesítményben. Egyszerűen a tranzisztorbüdzsé nagy részét elviszik a regiszterek. Emiatt a bruttó árrés nem tud egészséges szintet megütni, mert nem rakhatod rá például a B580-ra az 500+ dolláros árat, miközben a gyártás szintjén elhanyagolható mértékben drágább Radeon RX 9070-re az AMD rárakhatja.
Ezt kell megoldania az Intelnek, nem a startok ütemezését.
-
#49610
Abu85
HÁZIGAZDA
huskydog17
#49608
Abu85
HÁZIGAZDA
válasz
huskydog17
#49608
üzenetére
Az Intellel nem tudni, hogy mi lesz. Az új egyezmény az USA-val rákényszeríti őket, hogy tömjék a pénzt a foundry-ba, miközben nehezebb lesz majd eladni a Xeonokat az EU-s kormányzati projekteken. Szóval Lip-Bu Tannak új részlegeket kell bezárnia. Elvileg minden olyan terület veszélyben van, amelynek a bruttó árrése 10% alatti, és az Arc VGA-k alatta vannak. Valószínűleg nem akarják, de újabb áldozatok nélkül nem fogják kihúzni 2029-ig, amikor jön az első termék, ami versenyképes lesz a fő piacon.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#49603
üzenetére
Pedig számítani lehetett rá, hiszen Kína csak GeForce-okat szed szét. Az mindegy, hogy az AMD vezeti a heti Mindfactory eladásokat, meg a hasonló kereskedői listákat, mert az csak a játékosoknak eladott VGA-kat nézi. Kína viszont ezzel szemben jóval több GeForce-ot vesz szétszedésre. Akkor lenne ez máshogy, ha Kína Radeont is szétszedne, és akkor az AMD sem csak a gamingre gyártaná a Radeonokat. Érdemes megnézni a GN videót erről. Három órás ugyan, de nagyon nagy mennyiségű GeForce el sem jut a kereskedőkhöz. A játékosok meg se tudják venni, mert Kína hamarabb elviszi, szétszedi, átdolgozza, majd bedobja valamelyik szerverbe. A VGA-gyártók oldalán ez is eladás. Mindegy, hogy nem játszanak majd vele.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#49539
üzenetére
Próbáltuk eléggé egyszerűen leírni. Nem az volt a gond, hogy nem volt backup, hanem az, hogy hibás lett az adatbázis struktúrája. És ez bármilyen hardverrel előfordulhatott volna, ilyenre előre nehéz készülni. És ilyenkor hiába van meg az adat, a struktúra maga a hibás. A nyers adatok amúgy jól vannak most is, azt kell megoldani, hogy ezeket be lehessen illeszteni más struktúrájú adatbázisba.
-
Abu85
HÁZIGAZDA
válasz
KAMELOT
#49531
üzenetére
Mert a szerver működik, és ami működik az fogyaszt, és a fogyasztásnak ára van. Itt ki lehet számolni, hogy a tipikus munkafolyamaton mekkora lesz ez a fogyasztás, így egységnyi szinten mekkora költség lesz üzemeltetni a szervert. Na most ez Xeonnal több pénz, nem is kicsit.
#49536 : Busterftw : Nem lehet összeomlásra számolni, mert nem várod, hogy megtörténik. Ez nem egy logikus költség. Arra lehet számolni, hogy üzemeltetés mellett mennyibe kerül a fenntartás.
Én PC-n bő fél évig GeForce-ot használtam. Szóval nem ezzel volt a gond. Bár ebben az időszakban többször láttam fekete képernyőt, mint pixelest.
#49532 b. : Én 300-at költöttem PS5-re eddig. És még nem is vettem játékot, mert a PS Pluson jönnek a címek. És még van fél évem a mostani éves előfizetésből. Te azzal a géppel még csak a gépet vetted meg, szoftvert még nem, és a vas maga drágább volt, mint nekem két évnyi szórakozás, miközben még nem szórakoztál semmit.
-
Abu85
HÁZIGAZDA
Ezt én máshogy tapasztalom. Én ugyanannyit játszok, mint régen, de a másfél éves mérlegemet tekintve kb. feleannyit költöttem eddig konzolra, mint anno PC-re. És ez nem csak az én tapasztalatom. Másnak is a konzolt ajánlom, aki csalódott a PC-ben, és ugyanazt mondják, hogy sokkal olcsóbban kijönnek most. Sőt, több játékon is játszanak, mert előfizetnek a PS Plus-ra, ahogy én is.
-
Abu85
HÁZIGAZDA
válasz
arabus
#49524
üzenetére
Az az Epyc nagyon drága volt. Elsődlegesen azért, mert abban a kategóriában egyszerűen nem volt ellenfele. Emiatt választási lehetőségünk sem volt igazán, mert szükségünk volt egy bizonyos teljesítményre, méghozzá amiatt, hogy csúcsidőben sok a látogató. Vagyis vettük azt a procit, ami el tudta viselni a terhelést. Hidd el, hogy mi örültünk volna a legjobban, ha van hasonló paraméterű Xeon, de nem volt, és ami volt az lassabb volt, és üzemeltetni is drágább lett volna. Ez a baj, amikor egy piacon nincs verseny. Csak egy lehetőséged van, az is elég drágán.
A nép játszani akar, és ott rengeteg lehetőség van. Én például rég váltottam már konzolra, mert egyszerűen sokkal-sokkal olcsóbb, miközben az élményt is jobbnak érzem, mert nem kapom meg a sok PC-s szívást a shader fordítással, stb.
-
Abu85
HÁZIGAZDA
Mondjuk a dolog abból a szempontból mindegy az NV-nek, hogy az eladás az eladás. Nekik aztán teljesen lényegtelen, hogy az eladott GeForce-ok 90, 50, vagy csak 10 százaléka jut a játékosokhoz. Sőt, alapvetően minél kevesebb jut a játékosokhoz, annál több jut AI-ra, amiért az emberek manapság többet fizetnek, tehát az NV anyagilag alapvetően azzal jár jól, ha a GeForce-ot nem játékra veszik.
-
Abu85
HÁZIGAZDA
Azt nem fogja tudni megmondani az NVIDIA. Valószínűleg ők sem tudják pontosan, hiszen nagyot nőttek a szingapúri eladások, ahonnan ugye történik a VGA-k csempészése Kínába. De arról az NVIDIA sem tud pontosan, hogy a szingapúri eladásoknak mekkora része került a játékosokhoz, és mekkora része lesz csempészárú Kínába.
Ugyanaz a probléma, mint a cryptomining esetében, ott sem tudták a cégek, hogy az eladások mekkora része gaming és mekkora cryptomining. De utólag kiderült, hogy volt olyan, amikor utóbbi a 90%-ot kitette.
#49488 bertapet11 : Éppenséggel a kettő nem feltétlenül zárja most ki egymást, mert valószínű, hogy a HUB, a MLID, a GN, meg a többiek az asztali sorozatról beszélnek, miközben több gyártó is mondta a nyáron, hogy az 5060-ból még gyártási szinten is 70%-ban Laptop modellek készültek, és az NV az asztali, illetve a Laptop verziókat egybeveszi. A notebookgyártók pedig rengeteg 5060-at vettek az iskolakezdési notidömpingre, hiszen másképp nem tudják összeszerelni a notikat. De valóban, pontosabban kellene fogalmazni, mert hajlamosak vagyunk mindannyian csak az asztalira koncentrálni, holott a mobil már nagyobb piac.
-
Abu85
HÁZIGAZDA
Ez játéktól függ, de az újabb driverekkel az AMD már nem csak az RT shaderekre alkalmazza például a dinamikus regiszterallokációt, hanem az egyes címekben bizonyos compute shaderekre is. Tehát amíg a többi hardvert limitálja a kihasználtságlimit a statikus regiszterallokáció által, addig az RDNA 4 képes úgy betölteni az adatokat a regiszterbe, hogy tényleg csak a használt adatok legyenek ott, így a nagyon gyilkos compute shaderek az RDNA 4-en sok konkurens wave mellett futnak. Ez egy shaderre lebontva akár +700-900%-ot is jelenthet, ami a teljes képkocka szintjén simán hozhat +10-20%-ot, ha a shader tényleg megterhelő volt. Erről az AMD nem sokat árul el, de elvileg tipikusan azokat a shadereket célozzák az egyes játékokban, amelyek a mai GPU-knál a minimális konkurens wave-re kényszerítik a multiprocesszort. Ez lehet akár azért, mert az adott shader nagyon terhel, vagy azért mert rosszul van megírva. Igazából mindegy miért van, a dinamikus regiszterallokáció mindkettőt hardveresen korrigálja. Ha pont ott van a teszthelyzet, ahol ez a shader lefut, ott sokat gyorsul az RDNA 4, mert a többi GPU-n ugyanaz a shader a memóriaelérésre vár, míg RDNA 4-en van konkurens wave, amit futtatni lehet. Viszont ezt nem minden címre engedélyezi az AMD a deadlock kockázat miatt, de nem kizárt, hogy egy-egy játékban egy-egy shadert kiválasztanak, hogy dynamic VGPR módban fusson.
A másik dolog, amit az AMD csinál az általánosabb, és nem kell specifikusan flaggelni rá a drivert, hogy bizonyos kiválasztott shaderek máshogyan fussanak. Az RDNA 4 GPU-k memóriaalrendszere lehetővé teszi, hogy a multiprocesszorok ne sorosan, hanem dinamikusan, az elérhetőség sorrendjében kapják meg a memóriából igényelt adatokat. Ezt az AMD RT-vel prezentálta, mert erre fejlesztették a képességet, de bizonyos szituációkban, RT nélkül is nagyok hasznos fícsőr az Unreal Engine 5-ben, különösen az extrém magas poligonszámú, nanite-os jelenetekben, illetve Lumen és Virtual Shadow Maps alkalmazásakor. Az ok pedig az, hogy szoftveres comute shader raszterizáló alapesetben nagyon sok cache miss-be futhat, de az OOO memóriaeléréssel ezek gyorsabban lesznek kezelve. A Lumen esetében a sok rengeteg ray tracing query-n segít, míg Virtual Shadow Maps során nagyon sok a memory fetch, ami általánosan stallt eredményez a shaderekben, de ezt is sokkal gyorsabban lekezeli az OOO memóriaelérés.
Nagyjából ezek azok a dolgok, amelyekbe egy UE5-ös játék esetlegesen belefuthat, és ilyenkor az RDNA 4 képességei sokkal hatékonyabban kezelik a helyzetet, mint bármelyik más GPU, mert más dizájn még nem rendelkezik hatékony dinamikus regiszterallokációval vagy OOO memóriaeléréssel.
Az valószínűleg puszta véletlen, hogy az UE5 pont olyan irányba fejlődik, ami az RDNA 4 képességeinek éppen optimális. Az AMD ezeket a funkciókat RT-re fejlesztette, de mázlijuk van azzal, hogy az Epic arra viszi a motort, hogy RT nélkül is hasznot hozzanak.
-
#49443
Abu85
HÁZIGAZDA
huskydog17
#49430
Abu85
HÁZIGAZDA
válasz
huskydog17
#49430
üzenetére
Nem minden játékra lehet ráengedni a path tracinget. Valaminek a részletessége annyira magas, hogy messze túlmutat annál, amit egy path tracinges játéktól kapsz. Erre sokkal gyorsabb a Lumen.
-
#49415
Abu85
HÁZIGAZDA
huskydog17
#49413
Abu85
HÁZIGAZDA
válasz
huskydog17
#49413
üzenetére
Nem, ez szimplán a driver miatt van így. A játék fejlesztői szerint nem tudnak vele mit kezdeni, mert abban a környezetben, ahogy használják az UE5-öt kisebb többletterheléssel működik az AMD drivere, tehát több a szabad CPU-idő, amin csinálhatnak valamit. Ezért gyorsabbak a tipikus UE5 erőviszonyhoz viszonyítva a Radeonok, és a kisebb felbontás felé haladva gyorsulnak, mert erősebb kezd lenni a CPU-limit. A Work Graphs segítene valamennyit, viszont annak az az ára, hogy nem indulna el a játék csak az elmúlt két generáció VGA-in. Ez most még nem éri meg. És a Work Graphs is inkább az AMD-nek kedvez, mert jobban gyorsulnak tőle, mint a többiek.
-
#49375
Abu85
HÁZIGAZDA
huskydog17
#49372
Abu85
HÁZIGAZDA
válasz
huskydog17
#49372
üzenetére
Nem kell átírni a motort, egy sornyi kódot nem szükséges beleírni, mert az UE5 gyárilag szállított megoldásokat kínál bizonyos problémákra. Csak az Epic nem tudja, hogy az egyes stúdiók milyen játékot csinálnak, tehát a stúdióknak kell megválasztani azt a paraméterezést, amivel jól fog működni az UE5.
Például a PSO cache egy véleményes dolog. A funkciót az UE5 támogatja, de automatikusan nem aktív, mert nem mindig jó, ha az. Viszont, ha azt akarod, hogy aktív legyen, akkor az r.ShaderPipelineCache.Enabled=1 és r.ShaderPipelineCache.StartupMode=3 parancsokkal bekapcsolhatod, majd a PSO Collectorral szabályozni kell a begyűjtés módját, végül pedig a PipelineCacheToollal gyorsan betölthető formátumra lehet konvertálni a kódot.
Ezt a procedúrát az Epic sosem fogja default engedélyezni, mert nem tudja, hogy mit fogsz csinálni az UE5-ben. Ha mindenre gyárilag engedélyeznék, akkor az iszonyatosan sok PSO kombinációt jelentene, ami akár több gigabájt is lehet. Nagyon extrém esetben több 10 GB is. Gondolj bele, hogy ezt milyen sok idő lenne legenerálni. Nemhogy kávézni mehetnél ki a játék indításakor, vagy minden driverfrissítéskor, hanem megfőzhetnéd a teljes heti menüt, és jó eséllyel még várnod kellene.
Bónusz gond, hogy fejlesztés közben egy ilyen működésű motor nagyon sokat rontana a helyzeten, mert folyamatosan változik a tartalom. Gyakorlatilag mindig újra kellene generálni az egészet, ami jól kibaszna a kisebb fejlesztőkkel, mert fel kellene szerelkezniük 192 magos EPYC procikkal, hogy a fejlesztési idő 80%-a ne abból álljon, hogy várják a generálást.
A legjobb módszer a fentiek miatt az, ha egyénileg meg tudja határozni a fejlesztő, hogy mit gyűjtsön be a rendszer, mert így minden szempontból optimális lehet az eredmény. És erre szánniuk kell némi időt az életükből, mert az Epic sosem fogja megcsinálni helyettük. Az Epic csak eszközt tud adni nekik arra, amivel optimalizálhatják a készülő játékot minden aspektusból.
Az Epic nem tud mit kezdeni a köztudattal, ami összekapcsolja az UE5-öt a stutterrel. Nyilván elkezdhetik elmagyarázni az embereknek, hogy miért van default így beállítva az UE5, de az emberek döntő többségének halvány fingja sincs arról, hogy mi az a shader, így nem értenék meg a döntéseiket. Egyszerűen az egyes akadásokat a játékot fejlesztő stúdiónak kell kezelnie. Erre az Epic nem és sosem lesz képes, amíg a grafikus API-k működése olyan jellegű, amilyen.
És elárulom neked, hogy az Epic foglalkozik nagyon is a problémával. Az ARM-tól tudom, hogy olyan intenzíven benne vannak egy univerzális megoldás keresésében, hogy nagyon kardoskodnak azért, hogy legyen egy egységes vISA a gyártók számára, ami lehetővé teheti a mostani bonyolult shader fordítási rendszer mellőzését, és konzolszerűvé válna az egész működési modell. És ebben egyébként a Qualcomm és a Samsung eléggé támogatja őket, méghozzá úgy, hogy hajlandók lennének a HSAIL-t default vISA-jukká tenni. Csak az a gond, hogy az AMD, az Intel és az NVIDIA meg nem. Ebben nyilván az AMD állásfoglalása a szép, mert ők ezt úgy utasítják vissza, hogy közben HSA tagok.
Jó persze megértem, hogy miért ez most a hozzáállásuk, ők a Sony-val dolgoznak egy saját megoldáson, amit a többiek nem kapnak meg. -
#49370
Abu85
HÁZIGAZDA
huskydog17
#49368
Abu85
HÁZIGAZDA
válasz
huskydog17
#49368
üzenetére
Az engine nem egy varázsdoboz, ami mindent megold. Az UE5 sem fogja default beállítással lefedni az összes helyzetet, amivel egy fejlesztő előállhat. És ha a default paraméterezés nem elég jó, akkor például lehet alkalmazni különféle optimalizációkat, például PSO cache, async loading, level streaming volumes megfelelő paraméterezése, stb.
Az Epic biztosítani tud egy default működést, ami nagy átlagban nem tökéletes semmire, de kvázi elmegy majdnem minden vele. Adnak neked egy terepjárót, mert fogalmuk sincs, hogy mit fogsz csinálni, de ha már tudod, hogy egyenes aszfalton mész, akkor neked kell kicserélni a gumikat, hogy jobb sebességet kapj. De most képzeld el, ha F1-es autót adnának neked. Terepre azzal nem nagyon mennél, szóval jó oka van az Epicnek arra, hogy default ilyen a motor. Ez az UE5 lényege. Jó mindenre, de semmire sem tökéletes. Neked kell azzá tenned, mert az Epic-kel ellentétben te már tudod, hogy mit fogsz vele csinálni.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#49361
üzenetére
Ne vedd számításba azt, hogy máskor mi volt. Ezek a számok nem indikátorai a jövőnek. Az egyes branchek eléggé tág időtartamot fednek le. Van amelyik branch hónapikig jelen volt, és van amelyik csak hetekig. Nem lehet előre tudni, hogy mi lesz. Az az egyetlen reális indikátor, hogy a Microsoft mikor hozza a frissítéseket, mert akkor az biztosan új branchet jelent, hiszen kellenek az implementációk a Windows Update-hez. Ez az egyetlen tényező, amihez az NV, az AMD és az Intel is igyekszik igazodni, mert nyilván lényeges, hogy egy új Windows 11 dolgot még abban a hónapban használhass, és ne több hónappal később.
-
#49360
Abu85
HÁZIGAZDA
Alogonomus
#49359
Abu85
HÁZIGAZDA
válasz
Alogonomus
#49359
üzenetére
Ezt azért lehetett tudni a bejelentés időtartamából is. Általában az NV 4-6 hónappal a kivezetés előtt jelent be dolgokat.
-
Abu85
HÁZIGAZDA
válasz
gejala
#49357
üzenetére
Nézd, ezek a számok nem határozzák meg, hogy meddig lesz velünk egy branch. Volt már olyan, hogy másfél hónapon belül új branch jött. Inkább az határozza meg a fejlesztéseket, hogy mik készülnek. És az SM6.9 eléggé fontos fícsőr, amit a Microsoft kérhet októberre, és ha kérnek, akkor hozni kell rá a drivert. Nincs mese.
A Maxwell és a Pascal támogatása pedig átkerül Legacy-be. Ezzel jobban is járnak a régi VGA-k tulajai, mert nem túl hatékony kódokat fordít már ezeknek a dizájnoknak a mostani shader fordító. Ha viszont nincsenek az új dizájnok támogatva, akkor vissza lehet térni a régebbi paraméterezésekhez.
-
Abu85
HÁZIGAZDA
válasz
gejala
#49353
üzenetére
Idén októberre kell elérniük, mert akkor jön az SM 6.9. A Windows 11 éves frissítése ilyenkor eléggé meghatározza a fejlesztések ütemét.
#49355 FLATRONW : Igazából ez tök normális. Valójában ezek a branchek nem mindig maradnak ugyanaddig. Vannak nagyon rövid életű branchek is. És általában a tervezést nagyon meghatározza, hogy a Windows 11 mikor frissül, vagyis mikor érkeznek az új fícsőrök. Ilyenkor akár hónapokat ugranak, mert van egy fontosabb képesség, amire átrakják az erőforrást. Ezért van már 590-es preview driver, mert már azt fejlesztik, és nem az 580-as branchet. Valószínűleg az 580-as nem is fog újításokat hozni, csak kitöllti majd az űrt, amíg október nem lesz. De amúgy a driver jelzése nem olyan nagy kunszt. Nem értem, hogy miért vált hirtelen fontossá.
-
Abu85
HÁZIGAZDA
Ezzel arra akartam rávilágítani, hogy nem olyan extrém dolog ez, mert minden kormány csinálja.
Szerintem a Foundry-t nem hagyja az USA kinyúlni. Ha mást nem, akkor végső soron kérik a függetlenítést, majd vásárolnak benne 49,9%-os részesedést. Az Intel tervezői része nem fogja érdekelni az USA-t. Úgy lesznek vele, hogy adjanak el mindent, amit lehet a Foudnry-ért.
#48379 b. : Ez a Kína támadja Tajvant dolog még mindig képlékeny. Elszállhat az agya Miximackónak, de logikusan átgondolva, ha belemennek ebbe, akkor azon Kína is veszít, és annyira ingatag lábakon állnak, hogy be is tudnának csődölni egy ilyen támadástól.
Az USA szempontjából fontosak ezek az elvárások az Intel felé. Őket a Foundry érdekli, és az elvárás világos, az Intel adjon el mindent, hogy megmaradjon a Foundry. Még egyébként az sincs kizárva, hogy valakire rákényszeríti az USA az Intel tervezői részlegének felvásárlását. Van pár amcsi cég, amelyeknek van keresztlicencük az Intellel, például AMD, Microsoft, Marvell. Ha minden kötél szakad, akkor kormányzatilag kényszerítik az egyesülést, és cserébe kiírnak egy sok tízmilliárdos tendert, hogy legyen értelme a cégnek megvenni az Intelt. A Microsoft persze necces, mert túl nagy hatalma lenne, az AMD-nek nincs szüksége az Intelre, de a Marvell esélyes, mert nekik még hasznuk is lenne belőle. És itt fontos, hogy például a Marvellnek nem kellene tárgyalnia az AMD-vel a licencről, tehát az AMD sem tudná torpedózni az üzletet. A kisebb licencekről úgyis meg fognak egyezni, mert azok fontosak az AMD-nek is.
-
Abu85
HÁZIGAZDA
A Foudry-nak adnak adófizetői pénzt. Nagy különbség. Az Intel ezt a pénzt nem használhatja fel szabadon, meghatározott dolgokra kell költeni. Ilyet pedig egyébként minden kormány csinál. A TSMC-t is támogatják például Japánban a gyárépítést tekintve. Ebben az USA nem egyedi. És ez sokkal inkább reakció arra, hogy ha Kína is adófizetői pénzzel tömi ki a cégeit, akkor az USA is így játszik, csak átláthatóan és szabályozottan teszik.
-
Abu85
HÁZIGAZDA
Konkrétan követelményei vannak az USA-nak ebből az Intel felé. Tehát elvárják, hogy az építés során mennyi munkaerőt foglalkoztassanak, stb. Tehát ez nem csak szabadon felhasználható pénz, hanem van elvárás is.
A TSMC-nek is adnak így pénzt. Hasonló elvárásokkal. Ilyet csinál Japán is, az EU is, stb. Ez nem egyedi. Nyilván vannak elvárások, amiket a pénzért hozni kell.
-
#48321
Abu85
HÁZIGAZDA
huskydog17
#48319
Abu85
HÁZIGAZDA
válasz
huskydog17
#48319
üzenetére
Tudom, visszaportoltak képességeket, de nem portolták hozzá vissza az arra szabott RHI-t. És ez így tök jól hangzik, csak nem véletlen, hogy az Epic az egyes képességeket újabb verziókhoz köti.
Jó persze megértem, hogy miért ez most a hozzáállásuk, ők a Sony-val dolgoznak egy saját megoldáson, amit a többiek nem kapnak meg.
Ú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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Dell Precision 5520 15,6" FHD, Xeon E3-1505M v6, 16GB RAM, Quadro 4GB VGA, SSD, jó akku, számla, gar
- Asus ROG Strix B650-A Gaming Wifi alaplap
- BESZÁMÍTÁS! Részletfizetés 0% THM ÚJ Sony PlayStation 5 Slim digital / lemezes / Pro konzol 27% áfa
- Azonnali készpénzes nVidia RTX 4000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest