-
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
válasz
Jack@l
#55728
üzenetére
A 6600 XT 128 bites GPU-val dolgozik.
Nem életszerű, de az NV limitbe fut, ha nem high-end procit raksz alá. Ezzel nem tudunk mit kezdeni, mi is kicseréltük a tesztgépben a korábbi procit, és látványos a gyorsulás, még középkategóriás GeForce-on is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
#55767
Abu85
HÁZIGAZDA
Petykemano
#55740
Abu85
HÁZIGAZDA
válasz
Petykemano
#55740
üzenetére
Az a lényeg itt, hogy ha egy AMD VGA-t tesztelsz mondjuk Ryzen 3900-zal és mondjuk Ryzen 5600X-szel, akkor a két eredmény között alig 5-8 százalék lesz az utóbbi javára. Az erősen CPU-terhelés játékokban is, 1080p. Ugyanez a GeForce esetében 20-30% is lehet a Zen 3-as proci javára. Különösen az olyan CPU-igényes játékban, mint mondjuk az AC Valhalla. Utóbbit régóta tervezzük berakni a tesztekben, de a Zen 2-es tesztprocival gyakorlatilag az 5600XT-t nem tudta megverni 1080p-ben a 3090. Ott sorakoztak 1-3 fps különbséggel a GeForce-ok középkategóriától a csúcsig. Viszont a Zen 3-ra való váltással elkezdtek a GeForce-ok is skálázódni, még mindig nem úgy, mint a Radeonok, de már csak az 3080-3090 tűnik procilimitesnek. 1440p-ben már csak a 3090 nem tudja kifutni magát, de nem extrém mértékű a limit, mint Zen 2-vel. A Zen 2-Zen 3 váltással a 3090 60%-ot bőven gyorsul 1080p-ben ebben a játékban. Érezhető, hogy mekkora a limitben volt, és még most is abban van, csak nem annyira már.
A TPU is Zen 3-mal mér már, ráadásul ők 4,8 GHz-ig tuningolják a CPU-t. Mi alapon működtetjük. És még így is limites náluk a Valhalla 1080p-ben, de persze nem mérik azt az egymás mögötti sorakozást a GeForce-oknál, amit mi Zen 2-vel.
És ez a limit 4K-ban kezd megszűnni. Nem tűnik el teljesen, de láthatóan jobban érzik magukat a GeForce-ok.
Az erőteljes limit egyébként megfigyelhetően azokban a játékokban fordul elő, amelyek erőteljesen építenek a DirectX 12 bindless bekötési modelljére, amelyek mondjuk Future_Level_11_0 GPU-n is elindulnak, azokkal sokkal kevesebb baja van a GeForce-oknak. Némi limit lesz így is, de közel sem akkora, mint egy olyan játéknál, ami Future_Level_12_0 szintet kér minimum.
A másik tényező, amit megfigyeltem, hogy ha egy játék nagyon sok barriert alkalmaz (akár azért, mert szarul van megírva, vagy mert ez szükséges), akkor a GeForce driver valamiért megbolondul, és elkezdi szórni a driver barriereket, mintha nem lenne holnap. Szinte mindenhova, olyan helyekre is, ahova az AMD drivere nem is tesz, ergo egy csomó olyan helyen, ahol ez eleve indokolatlan, teljesen megakasztja a GeForce driver a feldolgozást. Ilyen játék például a Cyberpunk 2077. És ennek az eredménye ugyanaz, mint fentebb: CPU-limit az erősebb GPU-kon.
Ami 4K-n, elkezd javulni:
[ 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
#55770
üzenetére
Csak egy apró tényező, amit nem veszel figyelembe, hogy a Radeon nem limites, az skálázódik Zen 3-asnál jóval lassabb procikon is. Ergo nem a lassabb proci a gond.
#55768 Yutani : A barriereket az explicit API-k tették láthatóvá. Ezek mindig megvoltak, csak a régi API-kkal kizárólag a driver gondoskodott arról, hogy memórián belül az operációk jó sorrendben történjenek. Ezt úgy tették meg, hogy ha egy operáció írt valamit a memóriába, és fontos volt, hogy egy másik operáció csak az után írhasson, akkor az elsőre alkalmaztak egy barriert. Az explicit API-kkal annyi változott, hogy erről a fejlesztőnek kell gondoskodnia, de a driver barrierek ettől még nem tűntek el teljesen. Léteznek redundáns operációk, amelyeket felismer a meghajtó, és vagy eltünteti őket, ha erre lehetőség van, vagy korlátozást alkalmaz, hogy helyesen működjenek. Nagyrészt az egész a fejlesztők felelőssége, hiszen ha jól optimalizálnak, akkor a meghajtó képes helyesen dönteni, de ha ez nem történik meg, akkor a meghajtó megítélésén múlik, hogy mihez kezd a redundáns operációkkal. A kérdés itt az, hogy ezek mikor kellenek, és mikor nem. Általában az szokott erről dönteni, hogy az alkalmazást melyik hardverre írták. Ha Radeonra, akkor az AMD meghajtója tud hatékonyabban dönteni arról, hogy mikor dobja ki a redundáns operációkat, és mikor alkalmazzon rájuk driver barriert. Ha GeForce-ra írták a programot, akkor az NV drivere van jobb helyzetben, és valószínűleg az AMD drivere fog rosszabb döntéseket hozni.
Valószínűleg az is számít, hogy egy programban jól batch-elik-e a barriereket. Az NV azért elég sokszor ordítja a fejlesztők képébe, hogy batch-batch-batch. Ami amúgy tényleg hasznos, de lehet, hogy ők tudják a driverükről, hogy a nem jól batch-elt barreireknél a driverük kevésbé jól kezeli a redundanciát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55805
Abu85
HÁZIGAZDA
Petykemano
#55804
Abu85
HÁZIGAZDA
válasz
Petykemano
#55804
üzenetére
Sajnos elég sokat fogsz még úgy is belőle észrevenni. A medium részletesség csak segít a kimutatásban, de ez már max részlegességen is érződik. Láthatod a TPU tesztben, hogy ott a 3080 még 4,8 GHz-re húzott Zen 3-mal is CPU-limites pár játékban 1080p-ben, néhol 1440p-ben is.
Max részletességre értettem. Egyszerűen a Valhallában a Zen 2-Zen 3-ra váltás ennyit ért egy top GeForce-on, 1080p-ben. Ez már nem csak a medium részletességet érinti, ha csak azt érintené, akkor lehetett volna használni a Valhallát Zen 2-vel is, de egymás mögött sorakoztak a GeForce-ok 1080p maxon, miközben a Radeonok szépen skálázódtak.
Ott van a TPU mérésekben 1080p-ben a CPU-limit a GeForce 3080-on, és bivaly tuningolt procival, elég ha megnézed.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55808
Abu85
HÁZIGAZDA
Hellwhatever
#55807
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#55807
üzenetére
Mint ugye többször írtam, és nem győzöm hangsúlyozni, hogy a Radeon esetében ez a javulás nem figyelhető meg. Egyszerűen azok skálázódnak Zen 2-vel és Zen 3-mal is. A Radeon 6800 XT esetében a Zen 3-ra váltás előnye csak 3-4%. A GeForce driver mellett eredményez a játék akkora többletterhelést, hogy valamiért nem tud jól működni a játék a régebbi, kevésbé tempós procikkal.
És a probléma még mindig jelen van 1080p-ben a GeForce-on, hiába a Zen 3, a Radeon most is jobban skálázódik, de már nem extrém a különbség.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55822
Abu85
HÁZIGAZDA
Hellwhatever
#55811
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#55811
üzenetére
Ha nem skálázódna, akkor sorakoznának egymás mögött azok a kártyák, amelyek teljesítménykülönbsége amúgy kétszeres. Ez az AMD-nél nem következik be, csak az NV-nél lassabb procival.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#55832
üzenetére
Mert jóval több is. A Lanczos évtizedek óta a legjobb megoldás skálázásra, nem véletlen, hogy a MadVR is arra épít, de rengeteg olyan operációt alkalmaz, amelyben a GPU-k veszettül lassúak. Az AMD implementációja pont ezen módosít jelentősen, illetve az egész algoritmus problémáit kicseréli olyan eljárásokra, amelyek nem okoznak képi hibákat.
És figyeld meg, hogy mennyien be fogják építeni. Pont az a lényege, hogy semmiféle overengineering nincs benne. Egyszerű megoldás egy egyszerű problémára, ami akármilyen futószalagon belül működik, ráadásul 14 évre visszamenőleg fut a hardvereken.
[ 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
Jack@l
#55834
üzenetére
A probléma az eredeti algoritmussal az volt, hogy nem mindig végez elég jó munkát, illetve nem is gyors.
A "nem is gyorsra" az volt a válasz, hogy megkeresték azokat a részeit az számításoknak, amelyek marhára lassan futnának egy GPU-n. Ilyenek a különböző szögfüggvénye, a négyzetgyök, stb. Ezek azért futnak lassan, mert a fő ALU-kban, nincs rá utasítás egyik GPU-ban sem. Helyettük a multiprocesszorok tartalmaznak pár SFU-t, amelyek el tudják végezni a feladatokat, de úgy 32-, 256- rosszabb esetben 512-szer lassabban. Ez ugye elég nagy szopás ahhoz, hogy valós időben az alapalgoritmus ne legyen alkalmazható. Egyrészt az SFU-k száma nem sok egy teljes GPU-n belül, másrészt az egyes speciális operációk is 8-16 órajel alatt valósulnak meg.
Ezt a problémát kezeli a kódban egy 0x5F3759DF WTF-szerű ötlet, amely a lassan futó operációkat kicseréli alapműveletekre, amelyek több nagyságrenddel gyorsabban futnak, és ezért csak kevés pontosságot áldozol. Emiatt az alapalgoritmus teljesítménye az egyes GPU-kon akár a százezerszeresére is tud nőni, vagyis eljutottál ahhoz a tartományhoz, hogy valós időben alkalmazható legyen.A másik probléma a "nem elég jó munka". Ehhez az alapalgoritmusnak külön kezelték a képi hibákat adó részeit. Ezeket kompletten átírták, illetve a képi hibák lehetőségét mellőzni lehessen. Ugye ennek is az volt a kulcsa, hogy az alapalgoritmust átlagosan a sok tízezerszeresére gyorsították egy GPU-n, tehát most már van miből költeni a jobb minőségre. Ebből jön az élek rekonstrukciója, ami az eljárás alapja.
A további modulnak számító RCAS már csak egy adalék, ami extra helyreállítási munkát végez.
#55835 Petykemano : A Xilinxet nem ezért veszi meg az AMD.
A FidelityFX Super Resolution eleve egy rohadt gyors eljárás. Amellett, hogy ez adja az ismert eljárások közül a legjobb rekonstrukciós minőséget, még ez is fut a leggyorsabban a GPU-kon. Tehető ennél gyorsabbá is, de egy középkategóriás VGA-n sem számol 1 ms-nél tovább, ha azt leviszed 0,9-re, ami egyébként még talán realitás is, akkor sem nyersz vele sok sebességet, mert a képszámítási teljes idejének a töredékrészén optimalizáltál 10%-ot, vagyis a teljes képszámítás időigényén ez jó ha 1%-ot dob.
Jobb minőség sem várható, mert eleve képes arra az algoritmus, hogy a natívval nagyon megegyező minőséget csináljon. Elméletben a natív minőség a referencia. Papíron ennél jobbat nem lehet csinálni. Az más kérdés, hogy a FidelityFX Super Resolution esetében is van olyan, hogy az UQ beállítás szebbnek tűnik, de ugye papíron ez nem lehet szebb, csak szubjektív benyomás szintjén.
Az alacsonyabb felbontásról való rekonstrukción lehet javítani. De ez egy balansz kérdés. Minél alacsonyabb felbontásról skálázol fel valamit, annál nagyobb számítási teljesítmény kell magához a skálázáshoz, hogy jó eredményt érj el. Az AMD nem véletlenül ajánl előre skálázási paramétereket. Azok ugyanis a sweet spotok.
A másik dolog, hogy az AMD régóta tart FidelityFX-es preziket, és sokszor elmondták már, hogy az elmúlt évtizedben arra jöttek rá, hogy sokszor a legegyszerűbb megoldások a legjobb válaszok egy problémára. Semmiféle overengineeringet nem szabad felvállalni. A FidelityFX fejlesztése úgy működik, hogy feltárnak egy problémát, arra átbeszélnek pár megoldást, és abból mindig a legegyszerűbbet választják, mert az esetek 99,99%-ában az a legcélszerűbb. Amikor egy algoritmust bonyolítasz, akkor előjönnek vele a problémák, nehezebben kezelhető lesz, több limitációt kell figyelembe venni, arra nem is biztos, hogy mindegyik fejlesztő hajlandó. Magát a FidelityFX CAS-t is az egyszerűsége adta el. Ugyanezt az elvet követi az FSR is.
#55836 FLATRONW : Mire gondolsz NGU alatt? Hirtelen nem tudom dekódolni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55844
Abu85
HÁZIGAZDA
Petykemano
#55840
Abu85
HÁZIGAZDA
válasz
Petykemano
#55840
üzenetére
Ez a kód eléggé ALU-intenzívre van szabva, szóban akkor fog gyorsabban futni, ha több ALU kerül a hardverbe. De dedikált maggal nem.
A dedikált magnak mindig az a gondja, hogy sok követelmény van a kód felé, és ez behatárolja a fejleszthetőséget. Ez látható a DLSS-nél. Az kezdetben a tensor magokon működött, majd az 1.9-cel lekerült róla, ekkor jött egy nagy minőségbeli ugrás. Majd a 2.0-2.1-gyel részben visszakerült, de a 2.2-vel megint lekerültek feladatok a tensorról. Egyszerűen maga a tensor mag egyáltalán nem hatékony abban a feladatban, amit a DLSS mostani verziója csinál, így jobb lesz az eljárás, ha a munka jó részét nem is a tensor csinálja meg.
És innen trükkös a helyzet, mert építesz a hardverbe egy rakás olyan feldolgozót, amire próbálsz valamilyen munkát rakni, de közben rossz lesz a hatékonyság. A DLSS-nél ez úgy működne jól, ha a tensor magoknak lenne dedikált regiszterterületük, de akkor meg a lapka fele a tensor lenne, amit használhatsz 100-akárhány játékkal, a többi cím alatt pedig minden drámaian lelassul, mert az ALU-nak szánt tranyókat elvitte a tensor regiszterterülete.
Értem, hogy sokan hisznek ebben a gyorsítás dologban, de ez a valóságban elég nagy kockázat. A DLSS-en borzasztóan látszik, hogy mennyire nem jól működik, a kezdeti kód óta folyamatosan kerül át a normál ALU-kra a feldolgozás, mert hiába jó papíron a tensor valamire, ha nem olyan dologra használod, amire le van tervezve a hardver. Ha pedig úgy használod, akkor meg szar lesz a minőség, lásd DLSS 1.0. Pont ugyanez lenne a baja egy FSR-nek is, ha elkezdenél dedikált hardvert építeni rá, és még a fejleszthetőséget is behatárolja.
Olyan lehet, hogy a feladat egy kis részét gyorsítod egy külön hardverrel, de eleve egy olyan eljárás az FSR, ami egy elég gyönge GPU-n is 1 ms alatt megvan. Most ha annak egy részfeladatát felgyorsítod, akkor meglesz egy hasonló képességű modern GPU-n az eljárás 0,8 ms-ból, és akkor megveregetheted a vállad, mert az kb. 1-2 fps plusz a végleges képkockára. Cserébe ellőttél egy csomó pénzt a hardverre, a hozzáigazított szoftverre, és a tranyók egy része az FSR-t nem támogató játékokban nem is aktív. Badarság ilyet csinálni jelenleg.
#55841 Busterftw : A tensor már a DLSS új verzióival is nagyon rossza hatékonyságú, felesleges az NV-nek az FSR átalakításába pénzt ölnie, mert a dedikált hardverek használatától csak lassulnának.
#55842 Alogonomus : Annyira nem memóriaintenzív ez az eljárás, hogy az IF nagymértékben számítson. Valamennyit mindenképpen számít, de ez még +1 fps-t sem ad ki.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55852
Abu85
HÁZIGAZDA
Petykemano
#55845
Abu85
HÁZIGAZDA
válasz
Petykemano
#55845
üzenetére
Mármint, hogy az Apple pár beépített szolgáltatása használja, és semmi más. Kb. ugyanez Androidon. Ennek nem sok haszna van.
Ki lehet tömni a hardvert ALU-kkal, de ha nem rendelsz hozzá kellő regisztert, esetleg dedikáltat, akkor a gyakorlatban az elméleti számítási teljesítmény csak a papírra jó. Nem hiszed? A GeForce RTX 3090 számítási teljesítménye 35,6 TFLOPS, a Radeon RX 6900 XT-é 23 TFLOPS. Eközben a két hardver gyakorlati teljesítménye nagyon hasonló, hol az egyik, hol a másik gyorsabb. Nyilván az AMD is megtehetné, hogy megduplázza az ALU-kat, és akkor co-issue megy majd két vektor, de amit nyersz, az a papíron a több TFLOPS, a gyakorlatban sok kihasználatlan feldolgozód lesz.
Ha a DLSS-re tervezték, akkor nagyon rossz hardverelemet terveztek hozzá, mert a tensor abszolút nem arra való, amit a DLSS csinál. De egyébként ezt a HPC-piacra tervezték, ott nincs meg az a probléma, hogy egyszerre mennek a tensorok és a fő ALU-k, így csak az egyik regiszternyomásával kell számolni. Szemben egy játékkal, ahol azért marha nagy probléma, hogy a tensor ugyanazokat a regisztereket használja, amelyekeből a statikus erőforrás-menedzsment miatt eleve kevés van a fő ALU-knak.
#55850 hokuszpk : Ehhez képest számos cégnél jelen van az overengineering. Ágyúval akarnak verébre lőni.
#55851 b. : Természetesen az NVIDIA bármikor csinálhat egy FSR másolatot, viszont nem valószínű, hogy megéri nekik, mert akkor ugyanarra a problémára lesz két megoldásuk, és a fejlesztő nyilván az egyszerűbbet fogja választani, ami nem a DLSS lesz, mert annak számos követelménye van a leképezőre, míg egy FSR-szerű eljárásnak lényegében semmi, azon kívül, hogy élsimított képet kér. Ennyi erővel kidobhatják a kukába a DLSS-t, mert nincs értelme egy fejlesztőnek azt választania egy NVIDIA-féle FSR elérhetősége mellett.
Arról nem is beszélve, hogy mi értelme volna az NV-nek egy saját FSR, amikor maga az eredeti FSR nyílt forráskódú. A CAS-ra sem reagáltak, pedig az is egyszerűen másolható, csak nem túl nagy ötlet olyanra költeni az erőforrást, amire már van megoldás.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55854
Abu85
HÁZIGAZDA
Petykemano
#55853
Abu85
HÁZIGAZDA
válasz
Petykemano
#55853
üzenetére
A GCN sosem épített co-issue-ra. Ráadásul regiszterrel is veszettül ki volt tömve. Ezt az utat az NV kezdte el járni a Turinggal, az Ampere-be pedig beletervezték a co-issue-t. Ha a kódot ennek megfelelően írod, akkor van haszna, de ha nem, akkor az ALU-k fele csak dísz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55859
Abu85
HÁZIGAZDA
Petykemano
#55855
Abu85
HÁZIGAZDA
válasz
Petykemano
#55855
üzenetére
A GCN-ben nem volt klasszikus értelemben dísz-ALU, ez akkor van, ha nem tudsz rá feladatot rakni. Kétféle limitbe ütközhet egy GPU, kihasználtság és függőség. Az architektúra dönti el, hogy melyik limit él.
Kihasználtságlimit az, amikor nem tudsz elég wave-et futtatni egy multiprocesszoron ahhoz, hogy átlapold a memóriaelérést. Ez a SIMT dizájnok sajátossága, és mindegyik GPU lehet kihasználtságlimites, viszont ezt nagyrészt az határozza meg, hogy van-e elég regiszter az ALU-k mellett. A probléma a mai GPU-kkal az, hogy az erőforrás-allokációjuk rém egyszerű. Egyszerűen statikus az egész, vagyis ha betöltesz egy shader programot, akkor előre lefoglal minden erőforrást, amire elméletben szüksége lehet. Ha nem nyúl hozzájuk, akkor is elveszi a helyet a regiszterekben és compute shader esetén az LDS-ben. Ennél sokkal jobb módszer lenne az, amit a CPU-k alkalmaznak, azok ugyanis dinamikus erőforrás-allokációval dolgoznak, vagyis csak olyan dolog kerül a regiszterbe, amivel dolgozni is fognak. De ez komoly ütemezőt is igényel, így egyelőre a GPU-knál ezzel nem foglalkoznak.
A fentiek mellett függőséglimit egy speciális korlát, ami a SIMD architektúrák sajátja. Klasszikus értelemben az AMD Terascale volt ilyen dizájn, azóta az alapfeldolgozást tekintve már mindenki SIMT-re váltott, tehát a mai GPU-architektúrák egységesen kihasználtságlimitesek. Technikailag az Intel dizájnja is, de annak egy sajátossága, hogy a regiszterek oldaláról ez a limit nem állhat be, viszont az LDS tekintetében ugyanúgy korlátozva lehet a feldolgozás. Ezért van az, hogy az Intel dizájnok az egzotikus, például geometry shader kódokban rohadt gyorsak, de a gyakorlatban ez egyáltalán nem mutatkozik meg, mert a fejlesztők compute shaderrel váltják ki a geometry shadert, amiben viszont eléggé vérzik az Intel hardvere.
A SIMT architektúrák esetében van egy speciális irány, amikor maga a dizájn SIMT, de egy ütemezőre több SIMD van felfűzve. Ilyenkor az architektúra egyszerre kihasználtság- és függőséglimites. Ide tartoznak az Intel dizájnjai, illetve az Ampere. Ezeknél látható, hogy papíron kurva nagy TFLOPS-ot tudnak, de ennek a gyakorlati felhasználás 95%-ában úgy kb. a 60%-a kihasználható.
Ezt azért csinálják a gyártók, mert maga az ALU olcsó a dedikált ütemezés és a dedikált regiszter nélkül. Illetve minden architektúrának vannak belső limitjei a működés tekintetében. Tehát dupla ALU-t nem olyan egyszerű ám beépíteni, mert lehet, hogy annyi multiprocesszort már nem tud kiszolgálni a tervezett memóriamodell. Azért ne felejtsük el, hogy a mai GPU-k memóriamodellje eléggé koros. Az AMD-é 2012-es, az NV-é 2010-es, az Intelé pedig 2009-es. Azóta a cégek ehhez nem nyúltak, csak viszik tovább az új dizájnokba. És egy ideje már a limiten vannak, azért próbálják ilyen-olyan egzotikus trükkökkel blokkokba rendezni a multiprocesszort, stb. És ha ez is kifújt, akkor jön elő az extra ALU tömb, de saját ütemező nélkül, mert ez a memóriamodell limitjeinek nem jelent extra terhelést, egyedül az a probléma vele, hogy a fejlesztőnek muszáj úgy programoznia, hogy a futtatott wave-ek között ne legyen függőség, mert ha az van, akkor az ütemező nélküli ALU tömb csak dísz. Nem tudja rárakni a hardver a következő wave-et, mert az éppen futtatott wave még számolja hozzá az szükséges adatokat. De mire ezt kiszámolja, addigra az elsődleges feldolgozótömb is felszabadul, tehát mehet arra a wave, ami a következő wave-hez számolja az adatokat, így azt sem lehet a másodlagos ALU-kra rárakni, és így tovább. Ezen úgy lehet segíteni, ha egy multiprocesszor két shadert is futtat, viszont ahhoz le kell particionálni a regiszterterületet, és abból nincs sok már egy shadernek sem, vagyis végeredményben, ha abból elveszünk, akkor kihasználtságlimitbe toljuk a multiprocesszort a túl nagy regiszternyomással. Ennek az eredménye ugyanúgy az, hogy az ALU nem dolgozik, csak nem a függőség miatt, hanem azért, mert nincs elég konkurens wave, így várni kell a memóriaelérésre.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55864
Abu85
HÁZIGAZDA
Petykemano
#55861
Abu85
HÁZIGAZDA
válasz
Petykemano
#55861
üzenetére
A chiplet. De ez nem csak úgy lesz, hanem meg is kell oldani hardveresen, és az nem egyszerű.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#55921
Abu85
HÁZIGAZDA
Petykemano
#55918
Abu85
HÁZIGAZDA
válasz
Petykemano
#55918
üzenetére
A Samsungnak jelenleg a legkisebb, ténylegesen tömeggyártásra alkalmas node-ja a 8 nm. Ha arra jön az NV, akkor máris veszített. Egyelőre a 7 nm-es EUV is elég sok hibaaránnyal dolgozik, az 5 nm-es pedig katasztrófa. A 4 nm-től várják a megváltást, ami nem egy half-node, hanem egy teljesen új, és ez elvileg versenyképes lehet a TSMC 5 nm-rel, és annak half-node-jával. Elvileg, valamikor 2023-ban.
#55919 morgyi : A Samsung a saját lapkáját gyártja magánál a 4 nm LPE-n. Ezzel láthatóan kerülik ők is a 7 és 5 nm-t, ahol szar a kihozatal. Az AMD-nek nincs különösebb értelme ezekre váltani, mert az NV-vel ellentétben jól tudnak licitálni a TMSC modernebb waferkapacitására. Az NV azért nem teszi, mert nekik ezek drágák. A Samsung közel negyed adja a 8 nm-es node-ra a wafert, mint a TSMC a 7 nm-est. Ez azért nem mindegy. Ha átmennének a TSMC-hez a consumer termékekkel, akkor durván megnőne azok előállítási költsége.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HPC lapkák eddig is a TSMC-nél voltak. Itt a kérdés, hogy a gaming hova megy. A Samsung azért jött jól az NV-nek, mert olcsó a wafer, és ez fontos, amikor olyan extrém drága komponenseket használnak, mint a GDDR6X.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nyilván olcsóbb egy olyan memória, amit egy szem memóriagyártó gyárt, és úgy árazza ahogy akarja, mert mindenképpen megveszi, aki GDDR6X-re szorul, mint egy olyan memória, amit három gyártó is gyárt, és aktív árverseny van, hogy ne a másik gyártóét vegyék meg. Nem kell mindent elhinni, aminek a Youtube a forrása, oda bárki tölthet fel videót.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nekem mindegy, hogy elhiszed-e, de a piacot a verseny hajtja. Ha te csinálsz valamit, ami kell valakinek, de eközben senki más nem árulja, akkor nyilván ezt kihasználód, mert az a valaki nem tudja mástól megvenni. Ellenben, ha olyan dolgot árulsz, amit melletted még legalább ketten, akkor ott bele kell menni egy árversenybe is, mert ha nem jó az árad, akkor az ügyfelek megveszik azt a másiktól. Ezen gondolkozz el, mielőtt elhiszel mindent, amit a YouTube-on látsz.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem igazán. A partnerek a GPU gyártójánál is rendelhetik a memóriát, mert az olcsóbb. Sőt, az AMD már konkrétan hitelesítő cég is. Tehát ők már úgy vásárolják a memóriát a Samsungtól, hogy azt nem hitelesíttetik előtte, mert vettek maguknak egy rakás ilyen berendezést. Néha vesznek bulk memóriát is, az úgy fog megjelenni a VGA-n, hogy AMD van írva a memóriára is, mert akkor nem csak a hitelesítést végzik, hanem a leválogatást is.
Az NV még nem vett ilyen gépeket, de idővel szerintem ők is fognak, mert sok pénzt lehet spórolni, ha nem a memóriagyártó hitelesíti.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Maradjunk annyiban, hogy a Gigabyte nem nyilatkozik ilyen formában. Nekik van egy sajtójuk, ami hivatalos választ küld a kérdésekre, és ezt névvel teszik, amit elvárnak, hogy közöljenek is. Ha nem válaszolhatják meg, akkor azt írják, hogy ez a kérdés üzleti titkokra vonatkozik, így erre nem felelhetnek, de ezt is névvel teszik, és ezt a választ is névvel kell közölni. Így védekezik a Gigabyte az ellen, hogy őket általános forrásként idézze valaki. Ha úgy hivatkoznak rájuk, hogy a Gigabyte egyik alkalmazottjának a barátjának a régi szobatársa, akkor azok nem ők.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Kérdés, hogy ki mire számított. A Radeon RX 6600 XT gyorsabb, mint a GeForce RTX 3060, nem csak pár százalékkal, hanem érezhetően. Miért adna az AMD 50 dollárral olcsóbban egy GeForce RTX 3060-nál gyorsabb VGA-t? 329-ért lehetne, bőven lenne haszon, hiszen az olcsó gyártásra van tervezve, de az az igazság, hogy úgyis eladják majd mind 400-500 dollár közötti áron is. Miért a kereskedő vigye a hasznot?
Írtam korábban, hogy a régi árakat mindenki felejtse el. Az a baj, hogy az AMD nincs rákényszerítve a versenyre. Egyszerűen érdemesebb nekik követni az NV árazását, és beállni a sorba teljesítmény szerint. Ha a user nem fog PC-t bővíteni, akkor is játszani fog valahol. Konzolon például. Kinek tesznek jót vele? Esetleg fizet az Game Passban az xCloudért. Kinek tesznek jót vele? Esetleg elmegy PC-s kézikonzolra, például Steam Deck. Kinek tesznek jót vele? Egyszerűen ha valaki nem asztali gaming PC-be öli a pénzt, zömében olyan helyekre tud menekülni, ahol AMD-t vesz úgyis.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én nem hibáztatom az NV-t. Az AMD csak követi őket árazásban.
Egy csomó dolog szimpatikus lehet még a piacnak, de ha ráraknak 100 dolláros árcédulát, akkor sem annyiért fog menni a boltokban. Lásd a GeForce RTX 3060-at, amely papíron 329 dollár, aztán...
#56063 Petykemano : A gyártástechnológia költsége megdrágult, de nem annyira, hogy egy ilyen hardvert 379 dollárért kelljen adni. Még 259 dollárnál is bőven lenne rajta haszon. 199 dollár lehet az a határ, ahol már kicsi haszonnal menne el. Viszont hiába írják ezt rá, a kereskedők úgysem ennyiért adják majd. Még a 379 dollárt is sokan keresni fogják, inkább 400-500 dollár lesz ennek a piaci ára, viszont az AMD ennek egy jó részét elrakja zsebre. A GeForce RTX 3060 sem ment semmire azzal, hogy 329 a listaára, jóval drágábban vihető haza a kereskedőknél.
#56066 .Ishi. : Jelenleg az AMD és az NV is elad minden VGA-t. Készletet maximum úgy lehet felhalmozni, ha nem engeded ki a raktárból a termékeket, de miért tennél ilyet, amikor van egy rakás vevő? A raktáridő jelenleg kb. zéró, az MSRP-nél magasabb árakon is elvisznek minden VGA-t, kongnak a raktárak az ürességtől.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Például, hogy az AMD életet lehelt az FSR-rel a régi VGA-kba. Ez sokaknál dönthet gyártói preferenciákról.
Az Xbox Series S és X nem hiánycikk.
#56103 Petykemano : Ma is benne van a DirectX 12-ben és a Vulkan API-ban is nem azonos teljesítményű GPU-k kihasználhatóságának lehetősége. Ehhez úgy kell megírni a programot, hogy megoldható legyen.
A chiplet nem csak annyi lesz, hogy két GPU-t egymás mellé raknak. Sokkal komplexebb probléma ez. Szóval ez működni fog egy NYÁK-on, de azon kívül nem.
A CXL nagyon sokára fog számítani, mert abból előbb szabvány kell. A PCI Express 7.0-ba kerülhet be leghamarabb alapfunkcióként.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az FSR, amit a user elsődlegesen lát. Még van pár lényeges előnye a Radeonnak, a leghasznosabb a mérföldekkel hatékonyabb DirectX 12 driver. A PAL implementációba belevert már az AMD tíz évet, és ez rohadtul meglátszik a teljesítményén.
A SAM nyilván előnyös, de az ugye nem általánosan elérhető. Venned kell hozzá egy olyan platformot, ami támogatja. Ha van, akkor jól jön az extra, de ha nincs, akkor ugye mindegy, hogy mennyivel lehetne gyorsabb.
Nem mellesleg az NVIDIA is eljuthat a SAM szintjére a Resizable BAR implementációjukkal, ha belerakják azt a fejlesztési időt, amit az AMD rakott bele. Csak annyira nem törik magukat rajta, mert milliónyi fontosabb dolguk van. Például a DirectX 12 driver hatékonysága, amin érdemes lenne reszelniük, hogy a shader modell 6.6 jól implementálható legyen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Vulkan eléggé lemaradt a DirectX 12 mögött. Nagyon késve implementálják a Microsoft újításaihoz hasonló pipeline-okat, illetve a Microsoft fejlesztőeszközei lényegesen korszerűbbek. A DirectX 12 óriási előnyt kovácsol abból, hogy a Microsoft egy rakás pénzt önt a PIX-be, ami optimalizálva van AMD-re, NV-re és Intelre is. Tehát van egy alapvető fejlesztőeszközöd, amelyiket minden gyártó támogat, és alaposan fejleszti a Microsoft. Emiatt nem igazán tud annyira erősen terjedni a Vulkan, mert ott ez hiányzik. Van egy RenderDoc, ami önmagában marha jó, de szorosan csak a Radeon GPU Profilerrel van interoperabilitása. Tehát amit a PIX-ből meg tudsz csinálni AMD-re, NV-re és Intelre, azt Vulkan alatt csak AMD-re tudod megcsinálni, a többi gyártóra meg valahogy meg kell oldani a profilozást, erre nem éppen olcsó alternatívák vannak. Ez azért nem egy kedvező alap a fejlesztőknek. A Vulkan határozott előrelépés az OpenGL-hez viszonyítva, de a Microsoft azért még mindig jóval több pénzt tud ebbe belerakni, és ez látszódik is a DirectX 12-es játékok számán. Nem mellesleg amelyik cím támogatja a Vulkan és a DirectX 12 API-t is, annál is az utóbbi a gyorsabb, igaz elhanyagolható mértékben.
Viszont ha megnézed a képességeket, akkor megint a Microsoft lép leghamarabb. A Vulkan nagyon messze van attól a bekötési modelltől, amit a shader modell 6.6 bevezetett.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
sakal83
#56141
üzenetére
Az NV-nek van egy termékskálája, és aszerint lövi be az AMD a sajátjának az árazását. Egyszerűen figyelembe veszik a Radeon teljesítményét, és beárazzák a tempó szerint.
Az RDNA 2 óta nincsenek rákényszerítve arra, hogy jelentősen az NV alá árazzanak. Egyrészt minden hardvert eladnak, ráadásul a boltban eleve az MSRP sokszorosáért viheted a hardvert, másrészt a DirectX 12-es meghajtó teljesítménye tekintetében is előnyben van az AMD, nem is kicsiben, tehát ha nem Zen 3-ad van otthon, akkor simán jobban jársz a Radeonnal, mert a GeForce-ot vissza fogja fogni a processzor. Ez még Zen 3-on is érezhető, hogy az a GeForce-nak kevés, miközben a Radeon már a Zen 2-vel is lényegesen hatékonyabban működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A D3D12 meghajtó alapvetően hozzájárul ahhoz a teljesítményhez, amit a Radeon RX 6600 XT elér, hiszen 1080p-ben még több játékban is érezhető a procilimit. Ez inkább 1440p-ben kezd megszűnni, de nem oda tervezték a 300-400 dollár közötti VGA-kat. Az NV-n majd a V-Cache tud segíteni az új Ryzenben, mert azzal 1080p-ben csökkenni fog a procilimitjük.
Hosszabb távon az NV-nek újra kell írnia a D3D12 meghajtóját, mert a erőforrások dinamikus bekötését az emulációs módszerrel nagyon nehéz hatékonyan implementálni a shader modell 6.6-hoz. Nincs is még ilyen meghajtójuk, holott az AMD és az Intel már kiadta a sajátját. Ez egy borzasztóan nehézen kezelhető helyzet. Bizonyos szempontból jobban járna az NV, ha a Turing alatt GPU-k támogatását kidobnák, mert a Maxwell és a Pascal fogja vissza őket. Amíg azokat támogatni kell, addig nem tudnak teljesen elszakadni a CPU-s emulációtól, így büntetik vele a Turingot és az Ampere-t is.
A Vulkanon látható, hogy a GeForce-ok jól működnek CPU-s emuláció nélkül, csak ugye a DirectX 12 bekötési modellje sokkal másabb, mint a Vulkáné. És ha a Khronos követni akarja a shader modell 6.6-ot, akkor hasonlót kell használniuk a jövőben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HardwareUnboxed két videóban is megmutatta. Többször volt már linkelve itt.
Az Assassin's Creed Valhallában még 1440p-ben is érződik a CPU-limit az erős GeForce-okon. Mi is látjuk, pedig Zen 3-at használunk.
A TPU méréséből szépen látszik: [link] - csak ők 4,8 GHz-re húzott a Ryzent használnak, viszont alapórajeles nyolcmagos Zen 3-mal még 4K-ban is vannak problémás CPU-limites helyzetek a GeForce-szal, de már nem annyira, mint 1440p-ben.
1080p-ben azt látjuk, hogy van egy áttörhetetlen fal, egymás mögött sorakoznak a gyorsabb GeForce-ok, egyszerűen nem tudnak a 6700 XT-nél jobban skálázódni. Hiába van a GeForce 3080 és 3090 között jelentős teljesítménykülönbség, a CPU-limit úgy megfogja őket, hogy az döbbenet. 4K-ban kezdenek élni, de láthatóan ott is kevés a CPU. Az Ubisoftos cimbinél már érdeklődtünk, aki szerint ezzel nem tudnak mit kezdeni, de írta, hogy majd a Zen 3-as 3D V-Cache sokat segít a GeForce-oknak, hogy 1440p-ben is jól skálázódjanak, és 4K-n nagyjából eltünteti majd a procilimitet. Viszont azt is írta, hogy az új motorban ez visszatér, ráadásul erősebben, mint valaha, mert az új konzolok miatt sokkal jobban terhelik a CPU-t, mint a Valhallában.
A gondot az okozza, hogy a GeForce driver a bekötésekhez erőteljesen a CPU-t használja, míg az AMD nagyrészt a CPU nélkül oldja meg ugyanezt a feladatot. Ezzel a motor szintjén nem tudnak mit kezdeni, mert nem ők kényszerítik arra a drivert, hogy a bekötéshez szükséges folyamatot nagyrészt a CPU-n futtassa. Ez az NVIDIA 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
[link] - később leírtam részletesebben a helyzetet. Több tényező van, de a legnagyobb tényező úgy néz ki, hogy a CPU-s emuláció a bekötésnél. Ez kifejezetten érinti azokat a játékokat, amelyek nagy CPU-terheléssel dolgoznak.
Vulkan esetében azért nem létezhet ez a gond, mert ott ez az emulációs réteg hiányzik.
Ettől egyébként lehet, hogy ez a maximum, amit a GeForce-ok tudnak, de azért kételkedek. Sokkal inkább hiszek manapság abban, hogy nagyon drága lenne több teljesítményt kihozni a rendszerből, és ez anyagilag nem érné meg.
#56151 sakal83 : A GCN érában többször megtették. Az RDNA-kkal már nem igazán, az RDNA2-vel meg nem volt rá szükség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez baromság. Az asszinkron compute-nak ehhez biztosan semmi köze. Az egy gyorsítást lehetővé tevő eljárás, amit már a Turing elég jól kezelt, de még ha a GeForce-ok nem is fognak valamiért berakni aszinkronba két pipeline-t, akkor sem azt látnád, hogy 1080p-ből 4K-ba tartva javul a skálázódás, hanem pont fordítva, ugyanis az asszinkron compute hiánya pont GPU-limitet eredményez, és nem CPU-limitet.
Ez a gond egy bekötési és erőforrás-kezelési probléma. De semmiképpen sem ütemezési, utóbbival pont 4K-ban mérnél limites szitukat, nem pedig 1080p-ben.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A TrendForce az év eleje óta jelzi előre a graphics DRAM áremelkedést, csak még mindig nem látni.
Felőlem hihetsz Igornak, csak hülyeséget beszél. Az asszinkron compute nem úgy működik, ahogy leírja. Ha annak hiány okozna limitet, akkor egyrészt GPU-limitet okozna nem pedig CPU-t (mert a CPU oldaláról a munkafolyamat ugyanaz asszinkron compute-tal és nélküli), másrészt 4K-ban okozna GPU-limitet, nem pedig 1080p-ben CPU-limitet. Pont az ellentétét látod a tesztekben, mint amit az Igor által leírtak alapján látnod kellene.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az asszinkron compute-nak nincs többletterhelése. A processzor oldalán az asszinkron compute ugyanannyi munka, mint ennek a hiánya. Az asszinkron compute csak azon változtat, hogy a GPU két futószalagot egymással párhuzamosan feldolgoz-e, vagy sem. De a processzor számár az lényegtelen, és semmit sem tud arról, hogy ez megtörténik-e a GPU-n belül vagy sem.
Ez a hardveres ütemezés is egy faszság. Egyrészt az NVIDIA régóta hardveres ütemezést alkalmaz. Ott van a multiprocesszorban az ütemező, ahogy a Gigathread Engine-ben is. Szoftverbe olyan részeit helyezik át az ütemezésnek, amelyek könnyen kezelhetők szoftverből. Ilyet nem csak az NV alkalmaz, hanem az AMD is, mert tökre hasztalan bizonyos függőségeket hardverből kezelni, amikor szoftverből képes vagy előre dekódolt, függőségmentes folyamatot biztosítani. A Fermi után az NV GPU-kból ezért került ki ez a hardverelem. A szoftver gyorsabban megoldja a problémát, de ettől még az ütemezés egy része maradt hardveres, az a része, amit szoftverből nehezebb kezelni. Olyan nagyon itt sem az AMD, sem pedig az NV architektúrája nem különbözik. Amely folyamatok gyorsabban szoftveresen, azokat úgy is csinálják. De ettől egyik dizájn sem lesz teljesen szoftveres ütemezésű, csak az NV és az AMD hülye lenne tranzisztort áldozni lassításért.
A trendforce egy piackutató cég, amely előrejelzéseket ad. Vagy bejön, vagy nem.
Linus és MLID YouTube-sztárok, akik szenzációból élnek.
A "Gigabyte alkalmazottjának a testvérének a régi szobatársától hallottam" pedig nem egyenlő a Gigabyte cég hivatalos közleményével.#56161 sakal83 : Nincs szükségük arra, hogy megbeszéljék az árakat. Az NV beáraz, az AMD meg hozzáigazítja a sajátját. Egy szót nem kell erről egyeztetni.
#56162 Cifu : Már kiderült, hogy nem mindegyik D3D12 játék érintet. Csak azok, amelyek minimum feature_level_12_0-t igényelnek. Ezekben viszont mindben érezhető a CPU-limit a GeForce-szal. Ha a feature_level_12_0 nem minimum követelmény, akkor a GeForce-ok limitje nem jön elő. Az NV peche az, hogy az új D3D12 játékok mindegyike feature_level_12_0 igényel minimum, ezért lett nagyon látható a jelenség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56318
Abu85
HÁZIGAZDA
Petykemano
#56317
Abu85
HÁZIGAZDA
válasz
Petykemano
#56317
üzenetére
Nem. Ez a kártya nem tud alapból 55 wattal 32 MH/s-ot csinálni. Az alap teljesítménye inkább 28 MH/s, és ehhez 90 wattos fogyasztás tartozik. De lehet tuningolni, ahogy a többi hardvert is, csak a kirakott táblázatban ezt nem állították a többi hardvernél.
Az AMD Polarisokat gyárt a bányába.
[ 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
Yutani
#56319
üzenetére
Ha bányára tervezel, akkor simán tudsz bármit ilyen hatékonnyá tenni.
A Polaris 30-nak van olyan kínai bányászoknak tervezett verziója, ami 40 MH/s-ot tud 70 watton. Ez csak paraméterezés kérdése. Az otthonra szánt RX 570-en is el tudod érni 80 watton a 35 MH/s-ot, és az nagyon nem bányára tervezett paraméterezést használ.
A gond az, hogy ezek a kártyák headlessek, és a bányászok is inkább kijelzőkimenettel rendelkező megoldásokat akarnak, hogy el tudják őket később adni. Emellett az is gond, hogy van egy minimum teljesítményszint, ami alatt nem elég jó a fejlesztés, mert a hely is érték, és ha csak 40 MH/s-ot tud a hardver, akkor sok kell belőle, vagyis hamarabb kell új épületet építeni az új bányagépeknek. Ez pedig költség. A bányászok optimálisan 60 MH/s fölött gondolkodnak, azt pedig nem tudja elérni a Polaris.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56324
Abu85
HÁZIGAZDA
Petykemano
#56322
Abu85
HÁZIGAZDA
válasz
Petykemano
#56322
üzenetére
Áh, az MSI Gaming X az túl drágán gyártható ehhez. Itt az OEM-eken van a hangsúly, a Tul ezernyi olyan VGA-t gyárt, amik sosem kerülnek kereskedelmi forgalomba. Például múltkor csak egy félmilliós indiai rendelésért újraindították két 28 nm-es GPU gyártását. Ezek nem járnak fejlesztési költséggel. Kapnak rendelést, van rá szabad gyártósor, és mehet is a gyártás. Occsóé direktben leszállítják. Kb. adhatják 30-50 dollárért, de félmilliós tételben ez már sok miközben a gyártása és összerakása pite tétel. Bőven megéri lehajolni érte.
A problémát mindig a gyártósorok kihasználása jelenti. Az a jó, ha ezek állandóan működnek, de nem minden gyártósor alkalmas modern hardverekhez. Itt valami régit gyártanak, mindig amire éppen szükség van. Ha kell, akkor terveznek hozzá másik BIOS-t, specifikálnak egy új paraméterezést, amíg ennek a költsége alacsony, addig megcsinálják, mert többet nyernek azon, hogy a gyártósor üzemel, mint amennyit buknak a befektetett erőforráson. Az AMD még 40 nm-es GPU-kat is gyárt, vietnámi iskolákba mennek. Kis tételek, de éves szinten hoznak pár tízezer dollár nyereséget, és igazából nem kell érte csinálni semmit.
A Radeon RX 6600 XT eleve úgy van tervezve, hogy el van eresztve a GPU. Ezért is tud bizonyos játékokban 2,8 GHz fölött működni. Valójában a Radeon PRO W6600 mutatja, hogy a Navi 23 sokkal hatékonyabb, mint amilyen paraméterezéssel rakják a Radeon RX 6600 XT-re. De az AMD ennél a modellnél számításba vette, hogy nagy teljesítményre paraméterezve is hatékonyabb, mintha energiahatékonyra terveznék a beállításait, így a teljesítményre mentek rá, hogy minél nagyobb árat kérhessenek érte. Ez elég jó döntés volt, mert írták is, hogy a raktárakat már a megjelenés napján kipucolták, ráadásul úgy, hogy némelyik AIB, bőven az MSRP felett adta a terméket. Amíg minden hardvert eladnak heti szinten, addig nem lesznek ezek olcsóbbak. És tudnák olcsóbban adni. A gyártási költség igen alacsony, még 299 dollárért is bőven nyereséges lenne a Radeon RX 6600 XT. Olyan 179 dollár körül mozoghat az a léc, ahol ugyan még maradna nyereség, de már megfontolandó lehet a termékek minőségén csökkenteni, hogy olcsóbb alkatrészekkel növeljék a nyereséget.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56326
Abu85
HÁZIGAZDA
Petykemano
#56325
Abu85
HÁZIGAZDA
válasz
Petykemano
#56325
üzenetére
Mi európaiak eleve nem vennénk meg azokat a hardvereket. Ázsia egyes részein viszont nincs pénz modern hardvereket venni. Emiatt gyártják még a nagyon régi hardvereket. Ezeket már nem támogatják, de annyira olcsón adják, hogy megéri ezekkel felszerelni a szegény iskolákat például.
Azért adják drágán, mert ennyiért is megveszik mindet. Ez látható azon is, hogy raktárideje a termékeknek gyakorlatilag nincs is. Ahogy bedobozolják őket, már mennek is egy megrendelőhöz.
Egyszerűen túl nagy az igény ahhoz, hogy mindent kiszolgáljanak. Ennyi. Vagy elfogadja ezt valaki, vagy elszokik konzolra. Ott is elég nagy amúgy az igény.
Az amúgy egy fontos felfedezés volt az NV-nek és az AMD-nek is, hogy ha megveszik ezeket a VGA-kat drágán, akkor miért is adják olcsón? Szóval ennek még lesz böjtje a következő generációkban. Ezen tényleg csak az változtathat, ha elegen szöknek át konzolra. Addig hülyék lennének az érintettek 200 dolláros szinten adni olyan termékeket, amelyeket 300-ért is kipucolnak a raktárakból.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56329
Abu85
HÁZIGAZDA
Petykemano
#56327
Abu85
HÁZIGAZDA
válasz
Petykemano
#56327
üzenetére
Azért nem gyártanak többet, mert nincs végtelen gyártókapacitása a bérgyártóknak. Jelenleg mindenki annyit gyárt, amennyi fizikailag lehetséges a meglévő és működő üzemekben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56333
Abu85
HÁZIGAZDA
Petykemano
#56332
Abu85
HÁZIGAZDA
válasz
Petykemano
#56332
üzenetére
Vannak a bérgyártóknak gyártósoraik. Azok tele vannak. Annyit gyártanak, amennyit lehet. Több lapkához több gyár kell, de azt meg kell építeni, ami lassú folyamat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56337
Abu85
HÁZIGAZDA
Petykemano
#56334
Abu85
HÁZIGAZDA
válasz
Petykemano
#56334
üzenetére
Ott, hogy nincs megépítve a gyártósor. Odamehetnek, hogy kellenek nekik plusz gyártósorok, de mi van, hogy ha felhúznak egy új gyárat ezért, és addigra már nem lesz akkora igény a termékre?
#56336 Yutani : A bérgyártók számára a partnerek biztonsága kritikus. Már lefoglalt gyártósort nem adnak oda másnak. Ha megtennék, akkor az üzleti modell kerülne veszélybe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#56340
Abu85
HÁZIGAZDA
Petykemano
#56338
Abu85
HÁZIGAZDA
válasz
Petykemano
#56338
üzenetére
Ha a többletkereslet gyorsan megszűnhet, akkor nincs értelme kockáztatni.
A bérgyártók ugyan bővítenek, de mit? 6-5-4-3 nm-re építik a gyárakat. Az meg nem jó a régebbi hardvereknek.
Olyan nagy kockázatot nem vállaltak, elvégre jóval kevesebb 7 nm-es wafert igényeltek, mint az AMD. Kb. bekalkulálták azt, hogy mennyit tudnak eladni az OEM-eknek a procik mellé, a maradék pedig megy asztaliba, ha addigra találnak egy partnert, aki kiadja dobozos formában. Egyelőre nem állnak a gyártók sorban.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
#56445
Abu85
HÁZIGAZDA
Petykemano
#56444
Abu85
HÁZIGAZDA
válasz
Petykemano
#56444
üzenetére
Ez a poszt nekem inkább arra mutat rá, hogy mennyire hülye manapság a média úgy általában, hogy minden pletykát készpénznek hisz. Aztán csodálkozik, hogy a valóság durván messze van.
Nyilván a DG2-512 EU lehet erősebb a 3070-nél, de leginkább 1080p-ben, komoly procilimit mellett, ahol az NV drivere olyan limites, hogy sok DX12 címben a Radeon RX 5600 XT is elveri, holott procilimit nélkül a közelében sincs. Persze majd rámondják, hogy erre az esetre gondoltunk, és nem a csúcsprocis, 4K-s mérésekre.
Az Apple-lel meg az a gond, hogy már az M1 IGP-ke is rohadtul nehezen skálázódik erősebb grafikait terhelés mellett. Mindenki le van nyűgözve a TFLOPS-on, de ha mondjuk Unity-vel ráküldesz egy komolyabb compute shadert, akkor úgy összefossa magát, hogy még az Intel IGP-i is játszva összeveri. Ha magas a regiszternyomás, akkor már nem nagylegény, hanem a "futottak még" mezőnyének versenyzője. Ilyet tudna csinálni az AMD és az NV is, de azért tömik ki a GPU-ikat erőforrásokkal, hogy ne csak tíz éve is elavultnak számító shaderek futhassanak rajta normálisan. Ezzel lemondanak egy csomó ALU beépítéséről, ami amúgy hozhatna nekik 50-70-90 TFLOPS-os elméleti eredményt is, de összességében így is jobb 20-30 TFLOPS-on maradni, mert valójában regiszterek és LDS kell ahhoz, hogy egy 300 wattos GPU-t ne verjen agyon egy komplex programban az Intel belépő IGP-je.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Jó de hol? Én tudok neked mondani olyan körülményt, ahol a Radeon RX 6600 XT is 50%-kal gyorsabb a 3070-nél. Ezek így önmagában nem sokat jelentenek. Mert nagyon könnyen bele tudod futtatni a GeForce drivert egy procilimitbe. Aztán az csak egy mérés lesz a sok százból, amiből mondjuk 90-nél más az erősorrend.
[ 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
sakal83
#56468
üzenetére
Az AMD-nél 100%-ban a hardver határozza meg, hogy milyen órajelen fut. Te tudsz amúgy a TDP limittel babrálni, de ezen kívül semmit sem tehetsz, maximum tuningolhatsz.
Na most az AMD az órajeleket úgy határozza meg, hogy van egy saját tesztcsomagjuk különböző alkalmazásokkal. Az alapórajel az a paraméter, amit a kártya a tesztcsomagjukban legalább elért. A game clock az a paraméter, amiben a legtöbbször működött, míg a boost az, amit el tudott érni maximum.
Te használhatsz más programokat, és ilyenkor az órajel is lehet eltérő. Akár a megadott referenciák alá és fölé is mehet, az abszolút minimum és maximum ugyanis igen nagy, közel 1 GHz-es tartomány.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ugyanazt, amit a notebookoknál. Ez a VESA szabvány része, csak nem nevezik el az implementációjukat. Papíron bármilyen VESA Adaptive-Sync kijelzővel működik, de ugyanúgy el kell kezdeniük majd egy hitelesítést, ahogy az NV-nek, mert ezeknek a kijelzőknek a döntő többségét AMD-re szabták/szabják. A driverben kell csinálni rájuk egy profilt, hogy képi hibák nélkül üzemképesek legyenek. Azt nem tudni, hogy az Intel csinál-e ilyet.
Az NV korában azt mondta nekem, hogy általánosan ezt nem lehet hivatalosan engedélyezni, mert az Adaptive-Sync ugyan szabvány, de pár tényezőről nem gondoskodik, és mára az a helyzet, hogy minden monitorgyártónál tucatnyi AMD-s mérnök lédereg, akik igyekeznek a hardvert és a firmware-t úgy terveztetni, hogy a Radeonnak legyen jó. Ezzel nem tudnak alapból mit kezdeni, de a driverből tudják szabályozni a dolgot, hogy a Radeonokra szabott firmware-hez igazodjanak. Viszont ez sokkal tovább tart, mint jó firmware-t írni, így az NV úgy döntött, hogy csak a 144 Hz-es kijelzőkig profiloznak, mert a többi 400-500 darabra nem lenne erőforrásuk. Utóbbiakon még bekapcsolható a G-Sync Compatbile, csak nem garantálják, hogy hibátlanul működni fog.
Ugyanezt az Intelnek is le kell majd rendeznie, mert az AMD még ma is ugyanazt csinálja, mint két éve, egy csomó AMD-s mérnök dolgozik azon majdnem minden kijelző esetében, hogy azok day0 szinten Radeonra legyenek szabva, le se szarva azt, hogy van másik gyártó is. Az NV és az Intel bele tud nyúlni a driverből, de egyrészt nem day0 szinten, másrészt iszonyatos erőforrást emészt fel egy Radeonokra megírt firmware kódot leprofilozni, és mindegyikre specifikus hackeket gyártani a driverbe.A problémát amúgy maga a HDMS-s FreeSync okozza. Ez egyáltalán nem szabványos, tehát biztosan csak az AMD-n működik, de ennek a licencköltségét nem kötelező megfizetni akkor, ha a VESA Adaptive-Sync firmware-implementációja, vagyis a DisplayPortos FreeSync Radeonokra van szabva. És innen ered az NV baja, hogy utólag kell driverekben hitelesíti a kijelzőket. Egyszerűen a gyártók nem engedik a fejlesztés közelébe a mérnökeiket, mert egy rakás költséget kellene fizetniük az AMD-felé, ha megtennék.
Ezen a szinten nem valami tisztán játszik az AMD. Mire az NV eldöntötte, hogy támogatni fogják a szabványt, addigra egy csomó mérnökkel és konkurenseket szívató szerződéssel rendezte le a piacot az AMD. De az Intel ugyanarra képes lehet, amire az NV, utólag rászabni az egyes kijelzőkre a drivert, de manapság már 1000+ darab van, mindre nem lesz erőforrás, ugyanúgy dönteniük kell egy olyan határról, ami értékelhető mértékben csökkenti a hivatalosan támogatandó kijelzők számát. A többire rámondhatják, amit az NV: mehet, csak nem biztos, hogy megy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A VESA Adaptive-Sync a független. A FreeSync az nem, és arra bizony az AMD odarakta a monitorgyártókhoz a mérnökeiket, akik szabványos és nem szabványos FreeSync implementációknak megfelelő firmware-eket írnak a monitorgyártóknak. Plusz, ha a monitorgyártó nem engedi az NV mérnökeit a termék közelébe, akkor nem kell fizetni a HDMI-s FreeSync licenc hitelesítéséért.
A gyártáson itt nem kell módosítani, de az már nem mindegy, hogy a monitort milyen firmware-rel szállítják. Ezért látod, hogy az NV driverről-driverre ad ki támogatást xy monitorral. A driverből igazodnak a nem rájuk írt firmware-re.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A szabványoshoz nem kell, de a sajátjához kell, és azt nagyon sokan használják, a VRR monitorok kb. 90%-a.
Az NV régen azt mondta nekem, hogy az a fő baj az Adaptive-Sync szabvánnyal, hogy a teljes futószalag nem minden elemét fedi le. Emiatt például bizonyos időzítési paramétereket nem, és a Radeonoknak más paraméterek jók, mint a GeForce-oknak. Na most az AMD már eleve úgy íratja a Firmware-t, hogy nekik jó paraméterekkel működjön, és erre az NV úgy reagál, hogy xy monitorokat letesztelnek, és csinálnak rájuk profilt a driverben, hogy a GeForce-oknak rossz paraméterekhez igazodjanak. Működni működni fog mindkettő, de az AMD-nél out-of-box fasza a rendszer, míg az NV-nek dolgozni kell érte per monitor szinten. És ezen nehéz változtatni úgy, hogy az AMD közben árazópisztolyt tart a monitorgyártók fejéhez, hogy ha az NV-nek is kedveznek, akkor bukják az évenként odaöntött pénzt, és egy rakás AMD által birtokolt licencet, amit az AMD ingyen ad nekik, ha jófiúk.
Emiatt van az, hogy az NV még ma is csak driverből csinálja ezt, míg az AMD-nél sose látsz olyat, hogy egy új driver ilyen-olyan FreeSync monitorhoz hoz támogatást. Egyszerűen ezt a supportot a monitorgyártókhoz betelepedett mérnökeik direkten beépítik a firmware-be, így nem kell a meghajtóban egy nem optimálisan paraméterezett firmware-hez igazodni, ahogy az NVIDIA-nak.
A szabványos HDMI VRR-nek van annyi előnye, hogy a HDMI Forum nem volt nagyon felszínes, mint a VESA, így ők gondoltak erre a problémára. Ergo ezt szabványos szinten kezelik is. De a piacpolitikai tényezőket ők sem tudják kezelni, az AMD ettől még ugyanúgy rá fogja fogni a gyártókra az árazópisztolyt, mert a HDMI VRR-t kevesebb hardver támogatja, mint az AMD-felé HDMI-s FreeSyncet. A FreeSync valójában csak a felhasználók felé "free", a gyártókra már komoly láncokat rak. Talán versenyjogilag is némileg kifogásolható láncokat. Egyelőre viszont senki sem szól érte, mert a monitorgyártóknak előnyös, hogy van egy rakás ingyen licencük, és ezért csak el kell kurvásodniuk. Talán más lenne a helyzet, ha az NV ezt a problémát nem tudná kezelni driverből, de mivel kezelni tudják, így a jelenlegi helyzetet mindenki elfogadja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Minél több GPU-t raksz a nyákra, annál tetszetősebb a bányászoknak, mert egy gépben több GPU-t tudsz kiszolgálni.
Ú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.
- Milyen autót vegyek?
- Autós topik
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- A fociról könnyedén, egy baráti társaságban
- Nők, nőügyek (18+)
- LEGO klub
- sziku69: Fűzzük össze a szavakat :)
- Fűnyíró topik
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen