- OLED monitor topik
- Samsung LCD és LED TV-k
- Kormányok / autós szimulátorok topikja
- Amlogic S905, S912 processzoros készülékek
- Milyen monitort vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Apple MacBook
- Autós kamerák
- Jóárasított AI PC-ket szeretne látni az AMD
-
PROHARDVER!
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
Az a gond, hogy mindent csak így nézel, hogy NVIDIA vagy AMD. A valóságban sokkal árnyaltabb a helyzet. Itt fejlesztési modellről van szó, amit az AMD is csinált régen, és sok bugot eredményezett. Most az NV is ezt csinálja és sok bugot eredményez. Nem az AMD-t kellene követnie az NV-nek, hanem olyan fejlesztési modellre kellene állniuk, ami nem rak össze a több WHQL meghajtó érdekében több, egymással teszteletlen modult. Ezzel kevesebb bug keletkezik, és az erőforrásokat valós fejlesztésekre lehet használni.
Az AMD jelenleg funkcionálisan az NV előtt van a driver fejlesztését tekintve, mert több erőforrást rakhatnak arra, hogy valóban hasznos optimalizálásokkal élhessenek. Ennek látod az eredményt a GUI-ban, és a D3D12/Vulkan implementáció hatékonyságában. Ha az NV-nek nem a bugok reszelésére kellene fókuszálnia, akkor nekik is jóval hatékonyabb lenne az explicit API-kra írt implementációjuk, és nem lenne ott az az overhead probléma, lásd itt: [link] , ami miatt kisebb procival sokat esik a GeForce-ok teljesítménye. És ez egyébként valódi érték lenne a usereknek, mert alapvetően megvan az NVIDIA-nál a humánerőforrás optimalizálni, csak nem tudják használni amiatt, mert konstans bugokat hőlésznek és javítanak.
Nekem persze mindegy, hogy az NV hogyan csinálja, de én biztos nem így csinálnám, mert rosszabb teljesítményt ad és több bugot.
-
Abu85
HÁZIGAZDA
Az mindegy, hogy a fejhasználóknak van-e jelentősége. Nyilván amikor az AMD csinálta így, akkor szintén hátrányos volt a usernek, hogy csak azért keletkeznek a driverben hibák, mert nem tesztelt modulok vannak összefordítva. Aztán hotfix hotfix hátán. Viszont ahogy anno az AMD marketingesei is eladták a vezetőségben, hogy számít a WHQL meghajtók száma, úgy most az NV marketingesei is eladják ugyanezt. És valószínűleg az NV rendszerprogramozói ugyanúgy mondogatják a vezetőségnek, hogy a bugok kb. fele csak abból keletkezik, hogy két külön branch van, de amíg a vezetőség nem mond le a WHQL meghajtók számáról, addig mindegy, hogy a programozók vagy a felhasználók mit akarnak. Addig az számít, hogy az NV évente párszor egy slide-ra nagyobb számot tud írni a WHQL meghajtók elé, mint az AMD, és nem számít, hogy ennek mennyi keletkező bug az ára, ami az ügyfelek életét megkeseríti. Az AMD-nél sem számított régen, pedig hogy ütötték őket a userek.
Ez egy ilyen világ. Nem az igényeitek van az első helyen, hanem az, hogy mitől lehet több terméket eladni, és le se szarják, hogy ez rosszabb felhasználói élményt fog jelenteni, amíg több pénzük lesz tőle.
-
Abu85
HÁZIGAZDA
Ez nem gyártói irány. Ez fejlesztési koncepció. Az AMD is csinálta így régebben és sok bugot hozott. Az NV most így csinálja, és sok bugot hoz. Egyszerűen maga a koncepció rossz, ahogy készül a driver.
#52272 Yutani : Igen, és ez egy nagyon fontos tényező, mert maga a fejlesztési koncepciót bizonyosan rühellik, akik dolgoznak rajta, és nyilván látja az NV, hogy nem kis problémákat okoz, amikor egymással nem tesztelt modulokat raknak össze, majd jön a Hotfix, majd a második Hotfix, stb. De marketingben van szerepe, és amíg több GeForce-ot tudnak csak emiatt eladni, addig igenis elviselik a bugokat.
#52274 b. : Nem a driverek száma a probléma, hanem a WHQL driverek száma, mert annak van olyan hátránya, hogy nem lehet csak úgy azonnal kiadni, előbb alá kell, hogy írja a Microsoft. És emiatt két csapat fejleszti az NV drivereket, mert sorozatban csúszna a WHQL driver egy hetet is, aztán nem lehetne rámondani, hogy day0. Az AMD lemond a WHQL-ről, mert korábban nagyon megégették magukat a Catalyst érában, amikor havi egy WHQL volt minimum. Ahhoz két csapat kellett, és ugyanazokat a problémákat tapasztalták, amiket az NV, amire hozták sorban a hotfixeket. De akkor is erőltették, mert a marketingben előnyös volt. Aztán belefutottak egy nagyon komoly szarlavinába, és megváltoztatták a fejlesztési modellt, mert egyszerűen abból keletkezett a bugok fele, hogy egymással nem tesztelt modulokat kellett összerakni.
#52275 deathcrow42 : Nem, mert az önmagában a hibák számát nem növeli nyersen. Csak több adatod lesz, hogy megold a problémát. És még így is belefuthatsz olyanba, amibe belefutott most az NV.
Tényleg nagyon egyszerű az egész. Ez egy fejlesztési koncepció, amit az AMD is csinált régen, amikor még Catalyst volt a meghajtó neve. Két külön csapat van, amely két külön branchet fejleszt. Ezek modulokból állnak, és időnként a WHQL aláírás érdekében olyan modulokat is összeraknak, amelyek egymással nem is voltak tesztelve. Az időhiány adja ennek a problémának az alapját. A másik fejlesztési modell, amikor egy branch van, és azon egy nagyobb csapat dolgozik. Ez évente kevesebb WHQL-t eredményez, mert koncepcióból nem mennek arra, hogy legyen aláírás, vagy ha lesz is, akkor aláírja a Microosft a driver megjelenése után 1-2 héttel. Ezzel a modellel az időhiány nem probléma, és sosem lesz benne olyan bug, ami abból ered, hogy két, egymással nem tesztelt modul van benne. -
Abu85
HÁZIGAZDA
válasz
BerserkGuts #52261 üzenetére
A világért sem akarnak a userekből tesztelőt csinálni. Az volt a gond, hogy az NV nagyon sok WHQL drivert csinál, és annak az a hátránya, hogy több csapat írja a drivert. Mivel több branch van cégen belül, így az egyes modulok az adott branch szintjén lesznek tesztelve, de ha ezeket tovább viszik, akkor a modul nem tesztelt környezetbe kerül befordításra. Ez okozta azt a rengeteg hibát. És az NV ezt úgy oldotta meg, hogy ezeket felkutatták, és egy branch részeként javították. Nyilván ez beletelt pár hónapba. Most megint kettéválik majd a fejlesztés, mert kell a két branch, ha sok WHQL-t adnak ki. Ezért is vonnak ki több architektúrát a támogatás közül, hogy könnyebb legyen tesztelni.
Ha visszaemlékszel, akkor ezzel a fejlesztési modellel az AMD-nek is rengeteg bugja volt még a Catalyst érában, és pontosan ezért vetették el, mert rájöttek, hogy pusztán a fejlesztési módszerbe van kódolva, hogy sok lesz a bug. Az sem biztos, hogy az NVIDIA ragaszkodni fog hosszú távon ehhez a fejlesztési módszerhez, de jelenleg a marketing egyértelműen erőlteti, mert ki tudják rakni, hogy mennyi WHQL-jük van egy évben, és ezt értékként tüntetik fel. Azt nem nézi senki, hogy ez mennyi szükségtelen bugot teremt nekik. Jelenleg a marketing jobban el tudja adni a terméket, mint az, hogy bugmentesebb legyen a szoftver.
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #52253 üzenetére
Kétlem, hogy nagy gond lenne náluk. Egyszerűen csak DLSS-sel sok volt a black screen, és ezt kezelik a NOP-okkal. Ha nem alkalmaznák, akkor black screen fagyásokat kapnál. És igen, a NOP néha lassít, hiszen arra kényszeríti a hardvert, hogy ne csináljon semmit, de alig észrevehető a lassulás mértéke, és bőven nagyobb előnyt ad az, hogy nincs black screen.
Az nagyon egyszerű. Kicserélték a shadereket. A Space Marine 2 eredetileg olyan shaderekkel jelent meg, amelyek nem voltak túl optimálisak a mai GPU dizájnokhoz. Ezt az NV és az AMD korábban megoldotta azzal, hogy kicserélték a shadereket. De amikor megjelentek az új GPU-k, akkor ezeket még nem alkalmazták az új architektúrákra. Ilyenkor szokott előfordulni, hogy az új generáció nem olyan gyors, mint a régi, ahogy ezt láttuk is a korai Space Marine 2 tesztekben. De utólag kicserélték ezeken is a shadereket, és be is gyorsultak.
-
Abu85
HÁZIGAZDA
válasz
BerserkGuts #52248 üzenetére
Nem, nem felejtettek el, bár számos kódot az NVIDIA már nem emberrel csináltat, de azért emberek ellenőrzik még.
De az AI-t az AMD is használja már, csak nem kódolásra, hanem tesztelésre.
Valószínűleg a jövőben mindenre használnak majd a cégek AI-t.
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #52238 üzenetére
Sajnos az új driverekkel esetenként előfordulhat lassulás a GeForce RTX 50-es sorozaton, de a gyártók szerint nem jelentős. Ez azért van, mert némelyik black screen problémát az NVIDIA úgy oldott meg, hogy a shader fordító NOP-ot fordít azokhoz a szituációkhoz, ahol a hardver instabillá válna, és dobná a fekete képernyőt. Tehát a review driver bizonyos szituációkban gyorsabb shadereket fordított, mint az újabb driverek, ahol szándékosan üresjáratokba van kényszerítve a hardver, hogy stabil maradjon. Ez konkrétan azt jelenti, hogy bizonyos shaderek futtatásakor arra kap utasítást a GPU, hogy ne csináljon egy darabig semmit. Állítólag erre lesz kifinomultabb megoldás is később, de annak a fejlesztése egy évig is eltarthat. Ez a NOP-os dolog egyelőre tűzoltás. Azért is lehet majd ezt lecserélni később, mert az instabilitást okozó szituációk szinte mindig DLSS-sel jöttek elő. Tehát a tensor aktiválásakor jön a probléma, és sokszor ezt nem is kell aktiválni, viszont a mostani módszer nem specifikált, általánosan dobja a NOP-ot, így DLSS nélkül is koncepcióból lelassítja a programfuttatást. A későbbi módszer valószínűleg ennél szofisztikáltabb lesz, ami ténylegesen csak a problémára fókuszál, így a DLSS nélküli, vagy jobban mondva a tensor aktiválása nélküli sebességet nem bünteti meg.
-
Abu85
HÁZIGAZDA
Azt mondják a gyártók, hogy az AMD az újabb driverekben elkezdte használni a dinamikus regiszterallokációt az egyes játékokra, így már nem csak az RT a use case, hanem több nem RT-s kernelt is ebben a módban futtatnak. Ezért gyorsulnak most így az egyes játékokban. De még csak kevés játékra vetették be, és legalább fél év lesz, mire sokra leprofilozzák. Az se teljesen tiszta, hogy mennyi kernelt érdemes az új módban futtatni. Van amikor már inkább lassulást okoz, tehát még a meglévő játékoknál is lehet gyorsulás. Egyelőre annyira új ez a hardveres képesség, hogy nem látni előre, hogy hol a teljesítményhatár vele.
Black Ops 6 amúgy egy állatorvosi ló ebből a szempontból. Azzal tesztelik, hogy meddig lehet kimaxolni vele a teljesítményt, mert annak a játéknak azért van pár erős compute shaderje.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #52072 üzenetére
Ez azért nem ilyen egyszerű. Az árak igazából mainline waferárat. De egy node a befektetési költségeket a TSMC-nél visszatermeli 3 év alatt. Tehát utána a waferár bezuhan.
Az NV pedig speckó, mert saját 5 nm-es node-ot használnak, és az csak nekik van. Nekik arra más szerződésük van, tehát ott nem igazán foglalkozik a TSMC azzal, hogy a waferárat levigye, mert nem kell versenyezni azon a node-on a megrendelőkért. Az a node meg is lesz szüntetve, ha az NV többet nem rendel rajta.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #52021 üzenetére
A sima 5060 előállítási költsége 240-255 dollár. Ezek gyártói infók, függően persze a kialakítástól. És ez még nem is a Ti verzió. Nagyon sokára lesz 200 dollár, hiszen minden terméken buknának 40-55 dollárt.
#52023 deathcrow42 : Igazából az AMD sem tudná. Bár sokkal olcsóbb a GDDR6 memória, a 9060 XT előállítási költsége is 190-220 dollár most. Függően a memóriától és a kialakítástól.
Az AMD és az NV másképp számol MSRP-t ez tény, mert a Compun panaszkodtak a gyártók, hogy az NV MSRP számításában nekik 5%-os haszonkulcs jut egy ideje (ezért dobbantott az EVGA), de az AMD is sóher, mert ők meg 15%-ot számolnak az MSRP-jükre a partnereknek. A kisker-nagyker árrés általában hasonló.
-
Abu85
HÁZIGAZDA
válasz
yarsley #51892 üzenetére
A survey az elsődleges grafikus vezérlőt detektálja, ha az ugyanattól a gyártótól származik. Tehát ha AMD proci mellé raktok Radeon VGA-t, akkor a Radeont VGA-t nem fogja látni, és nem is veszi fel az adatbázisba, helyette a proci IGP-je kerül be.
#51894 yarsley : Csak azt tudni, hogy mennyien nem keresik. A userek 4,47%-a potenciálisan rendelkezik valamilyen Radeon VGA-val, amit a Steam nem tud detektálni az IGP miatt. Ez a Steam detektálójának a hibája. Simán lehet detektálni, csak a Valve-ot nem érdekli, mert számukra ez az egész egy nyűg.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51874 üzenetére
Akkor részletesen:
A felmérés önkéntes alapon történik, tehát nem reprezentatív a mintavétel. A Steam időnként megkérdezi a felhasználókat, hogy részt akarnak-e venni, de ez nem kötelező. Nem véletlenszerű maga a mintavétel sem, így nincs biztosítva, hogy az összes régió, korosztály vagy hardvertípus megfelelően szerepel. Emellett a felhasználók hajlamosak nem elfogadni a felkérést, különösen akkor, ha "speciális" konfigurációval rendelkeznek például Linux gépek. Illetve van egy olyan tényező is, hogy a nagyobb úgynevezett digital literacy-vel rendelkező felhasználók többször utasítják el a felmérést. Ez normál esetben nem számítana, de a Mercury-nak volt régen egy olyan felmérése, hogy kisebb piaci részesedéssel rendelkező cégek vásárlói rendelkeznek nagyobb digitális műveltséggel, míg a nagyobb piaci részesedésű cégeknél erőteljesebb a nyáj hatás.
Viszonylag erős a torzítása is, ami elsősorban a hardcore PC játékosokat tükrözi, nem az átlagfelhasználót. Ez egyes rétegeket alul- vagy felülreprezentál, és mivel a minta összetétele nem tisztázott eredetű, nem lehet tudni, hogy melyik réteg van alul- és melyik felülreprezentálva.
A Steam felhasználók földrajzi eloszlása sem egyenletes, és emiatt nincsenek normalizálva az adatok régió szerint. Emiatt vannak az ide-oda ugrálások időnként, hogy amikor már annyira extrém baromságot mutat a Steam statisztika, hogy az a Valve szégyneérzetét is kilövi az űrbe, akkor a Valve kézzel belenyúl, hogy kitöröljön belőle milliós nagyságrendű mintát. De hogyan tudták, hogy annyit kell törölni? Hogyan számolták ki? Ja, hogy arról sincs semmilyen feljegyzés. Lehet, hogy csak hasra ütöttek? Esetleg számmisztika?
Emellett, és egyben legnagyobb bajként felróva... az adatok megjelenítése nem transzparens, mivel a Steam nem ad részletes módszertani leírást a mintavételről, a súlyozásról, vagy az adatfeldolgozásról. Emiatt nem lehet ellenőrizni, hogy milyen szűréseket vagy korrekciókat alkalmaznak. Ez különösen ott nagy baj, amit említettem az előbb, hogy a Valve időnként hasraütésre töröl milliós mintát, mert már szégyellik felvállalni a statisztikájuk torzítását. De fel lehetne hozni azt is, hogy egy új játék vagy hardver megjelenése idején az adatok ideiglenesen megugorhatnak, majd visszaesnek, és ezzel nem az a baj, hogy megtöténik, hanem az, hogy az ábrázolás nem mindig teszi nyilvánvalóvá.
Ezekért a bekezdésekért egyenként buktatnak az egyetemen, a Valve pedig mindegyik nagy hibát elköveti.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51871 üzenetére
A steam stat sose volt jó, mert attól, hogy nagy a minta, még olyan dolgokat csinál, amiért egyetemen buktatnak a statisztika órán.
-
Abu85
HÁZIGAZDA
válasz
S_x96x_S #51865 üzenetére
Azon kívül, hogy a Steam statisztika szokás szerint szar és az is marad, amíg nincs statisztikai módszertan alkalmazva rajta, nincs rá semmilyen logikus magyarázat. De ez különbözteti meg a tudományos alapokon nyugvó jó statisztikát az összehányt szar statisztikától, hogy előbbi logikus, utóbbi pedig hasznavehetetlen, és egyetemen buktatnak érte.
Ne keressetek logikát a tudományos alapot nélkülöző statisztikákban, így a Steam statisztikában sem.
-
Abu85
HÁZIGAZDA
válasz
T.Peter #51862 üzenetére
Nyilván, de ugye ehhez Nanite-szerű dolgok kellenek, hogy minden poligon legyen. Mondjuk pont erre megyünk minden motorban, tehát nagy jelentősége a jövőben nem lesz az OMM-nek, hiszen eltűnnek azok a szituációk, ahol segíteni tud.
Ezért kellene másfelé fejleszteni a DXR-t, hogy a komplex geometriát kezelje jobban, mert pont arra mennek a motorok.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51749 üzenetére
Semmi köze a rendszerchiphez ennek. A prev-gen legnagyobb gondja, hogy 5,5 GB memória áll rendelkezésre. Lehet sokkal erősebb a rendszerchip a PS4 Próban, extra memóriát nem tud adni, emiatt mindenből sokkal kisebb részletességűt kell használni, másképp nem fér bele a memóriába. A shaderek ettől jobbak maradtak PS4 Prón, mert jóval több szamítási kapacitás van benne, nyilván a felbontás is jobb maradt.
-
Abu85
HÁZIGAZDA
A memóriamenedzsmenttől függ. Az Intellel beszéltem erről még decemberben, és az a tapasztalatuk, hogy a legtöbb stúdió nagyon egyszerű menedzsmentet ír, amit könnyű ugyan kezelni, elég gyors is, de nagyon pazarló lesz az eredmény. A legtöbben úgy állnak hozzá ehhez a kérdéshez, hogy majd ha kevés a VRAM, akkor a rosszabb grafika megoldja a problémát, mert ezt ugye eleve skálázhatóra tervezik.
Erre egyébként vannak megoldások. Például az AC Shadows eléggé memóriazabáló lett volna, ha az eredeti memóriamenedzsmenttel érkezik, ami bőven 24 GB-ot igényelt volna 4K-ban. 10 GB lett volna a minimum igény. De az Ubisoft a játék csúsztatása miatt lecserélte a memóriamenedzsmentet az AMD-nek a D3D12MA-jára, és azt úgy konfigurálták, hogy minimalizálja a memóriahasználatot. Így végül ugyanaz a grafika a kiadott játékban belefért 11 GB VRAM-ba is 4K-ban, maximum részletességgel, tehát 13 GB-ot faragtak az egészen. És teljesítményben mindössze 1-7%-ot esett a sebesség, függően a GPU dizájntól.
-
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51683 üzenetére
Úgy, hogy a GDDR6 olcsó. A 9060 XT 16 GB kapcsán van egy érdekes infó egy gyártótól, hogy ha csak annyi árrést raknának rá, amennyit az 5060 Ti 8 GB-ra, akkor simán tudnák adni 239 dollárért. Szóval, ha az AMD a jelenlegi NV MSRP árrésekkel dolgozna, akkor már 229 dollárért is adhatna 16 GB-os VGA-t.
A GDDR7 drágítja meg az NV kártyákat jelenleg, de majd valamikor ősz végén ez kedvezőbb lesz. GDDR6-tal sokkal olcsóbb ugyanaz a memóriamennyiség.
-
Abu85
HÁZIGAZDA
Megjött a másik oldal reakciója az eseményekre a javasolt guide-ban:
We’d like you to test it in any way you see fit. We’re very confident in our product, so we have no intention of hiding anything from your readers.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51636 üzenetére
Az AMD ár szerinte hasonlít össze. A 9060 XT 16 GB ára 349 dollár, míg a 8 GB-os 5060 Ti ára 379 dollár. Adja az NV a 16 GB-os 5060 Ti-t 349 dollárért, és azzal lesz összehasonlítva.
Ez amúgy az AMD-nél is nyilván annak a kihasználása, hogy a GDDR7 memória kb. 4x drágább a GDDR6-nál, de az NV-nek nem volt kötelező GDDR7 memóriát használni. Rakhattak volna rá olcsóbb memóriát is, és akkor árazhatnák lejjebb.
-
Abu85
HÁZIGAZDA
válasz
bitblueduck #51598 üzenetére
[link] - Ha tudni akarod, hogy ez hogyan zajlik a háttérben, akkor ebben a videóban több információ van erről. Én nem szeretnék kifejezetten nyilatkozni erről, de JayzTwoCents kitálal mindenki helyett.
[link] - kiemelten ajánlom ezt a részt. A Digital Foundry-nak például egyre több videója van, amiben csak NV szerepel. Az AC: Shadows PC tesztből mindenkit kihagytak.
-
Abu85
HÁZIGAZDA
válasz
Busterftw #51595 üzenetére
Csak nem tudják megszerezni máshonnan a drivert. Alapvetően nem a hardver a gond. Az a gyártóknál jóval a start előtt elkészül, és nyilván két héttel korábban is ide tudja küldeni nekünk is az ASUS például. A gond az, hogy nem működik driver nélkül, és az csak a gyártótól jön.
Csak annyit mondok arról, hogy ez miért probléma, hogy például az AMD-nek gondot okozott, hogy a tesztdriver idő előtt kiszivárog. Emiatt a jövőben személyre fogják szabni, hogy visszakövethetővé váljon az útja. Tehát effektíve minden tesztelő egyedi drivert kap, és azzal fel kell majd jelentkezni egy szerverre, hogy a szerver aktiválja azt telepítés után. Ezzel az AMD azt próbálja meg elérni, hogy ne szivárogjon ki a driver a start előtt, de nyilván használható arra is egy ilyen módszer, hogy ha valakinek nincs hozzáférése, akkor hiába szerzi meg az állományt, a szerverre már nem tud feljelentkezni az aktiváláshoz. Tehát mindegy, hogy lesz-e hardver, driver nem lesz csak start után. És ezek a modulok, amik ehhez kellenek már ott vannak az AMD és az NV driverben is. Sőt, az NV új rendszere olyan modern, hogy a drivereket távolról tudja vezérelni, tehát a tudtod nélkül tud módosítani rajtuk, akár menet közben át tudnak kapcsolni benne egy beállítást.
Minden csatorna odamehet a cégekhez, hogy xy-nak interjút akar. Általában teljesítik, csak nagyon sok idő szokott lenni.
-
Abu85
HÁZIGAZDA
válasz
Busterftw #51593 üzenetére
Nem azt tartja senki problémásnak. Azt szabadon bemutathatja mindenki. Az a gond, ha ezt úgy kéri egy cég, hogy ha nemet mond egy média, akkor szankcionálja a médiát.
#51589 deathcrow42 : [link] - itt elég részletesen magyarázza Steve, hogy mihez nem ad a jövőben az NV hozzáférést, ha nem teszik meg, amit kérnek.
-
Abu85
HÁZIGAZDA
válasz
bitblueduck #51587 üzenetére
A kéréssel semmi gond. Ilyenek jöttek korábban is, mindenki részéről. És egyszerűen visszautasítjuk, mert vannak saját irányelveink. A gond ott kezdődik, ha egy médiát a függetlenségből eredő szabad döntése miatt szankcionál egy cég, például azzal, hogy jó, akkor nem kaptok többet hardvert.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51584 üzenetére
Nem. Lefizetsz, hogy csináljak meg neked valamit. Akkor lenne ez adok valamit, hogy kérjek valamit szintű dolog, ha ugyanolyan szintű felek lennénk, de mivel cégként sokkal erősebb befolyásod van, így ez lefizetésnek számít.
#51585 gbors : Júniusban lesznek tesztek róla. De a gyártók szerint 5-20%-kal gyorsabb az 5060-nál a 9060 XT 8 GB, és papíron ugyanannyi az ára.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51577 üzenetére
Ez például nem elfogadható helyből sem, mert beleszól a szerkesztési irányelvekbe.
"- a standard tesztek mellé legyen plusszban MFG oldal, mert ez az új fícsör nálunk, ezekkel a játékokkal: wukong meg cyberpunk meg mittomén. Ezért kapod a repjegyet,"
Ezt a részt egyetlen független oldal sem fogja aláírni, mert lefizetés.
#51580 lenox : Ha nem vagy független, akkor a másik lehetőség a propaganda. És azzal meg az a baj, hogy a propaganda az ugyanaz a termék. Leszünk ezren, de mindannyian pontosan ugyanazt csináljuk, mert azt igényli a propaganda. Emiatt ez nem lehet érték, mert önálló döntések hiányában nem tudsz értéket előállítani.
-
Abu85
HÁZIGAZDA
Lófaszt adott pénzt arra a cég, hogy felépítsen valaki egy oldalt. Csak így lehet ezt felépíteni szerinted?
Nem, jelen helyzetben nem igazán működik a függetlenség. Ez nem egy alapjog, hanem egy kivívott, és amit látni lehet, hogy a függetlenség kevesebb pénzt hoz, mert a cégek fizetnek azoknak, akik hajlandók propagandát csinálni. Ha a függetlenség érték lenne, akkor a GN és a HUB sem balhézna, de mivel jelenleg ők is azt látják, hogy a létük forog kockán csak azért, mert függetlenek, muszáj beleállniuk.
#51576 Egon : Oké, elérhető a teljes előadás a neten erről. Kérlek linkeld be azt a részt, ahol Huang kifejti, hogy az 5070 az MFG miatt gyorsabb a 4090-nél. Előre is köszönöm.
Elég sok köze van hozzá, mert ha mondjuk menne az MFG a 4090-en, amely hardveresen ugyanazt az OFA részegységet használja, mint az 5070, akkor még talán el is érné az NV szimpla kéréssel, hogy ezt a funkciót bekapcsolják a tesztoldalak.
-
Abu85
HÁZIGAZDA
Nem hiszem, hogy a bíróságon megállná a helyét egy ilyen panasz.
Ha nem lenne VGA, akkor tesztelne mást a HUB. Most is megoldják a tartalmat azzal, hogy basztatják az NV-t, amit csinál.Ezt Huang állította, én csak az állítását közlöm.
De amúgy a tesztekben hogy lesz, majd a 4090-re is bekapcsolják az MFG-t? Ja várjál, arra az NV nem engedélyezte. Na ezért akarják az MFG-t bekapcsolva látni, mert csak az új generációra aktíválták ezt a szoftvert. Ami egyébként az Ada generáción is működhet, mert ugyanaz az OFA van benne, mint a BW generációban.
-
Abu85
HÁZIGAZDA
Azért lehet jogod ezekre a hardverekre, mert felépítettél egy olvasó-/nézőbázist, ami értékes, és ezt figyelembe szokták venni a gyártók. Ha egy nagy médiától csak azért elveszik a hardvert, mert valamit nem tudnak kialkudni, akkor zsarolják a hardverrel az adott médiát.
Ha ez nem lenne probléma, akkor nem lenne belőle ügy. Itt alapvetően arról van szó, hogy egy cég propagandaoldalakat akar független média helyett. Nyilvánvaló, hogy a GN és a HUB hátrányos ilyen szempontból, mert nem akarnak propagandát gyártani nekik.
Neked is hátrányos lesz, ha megszűnik a GN és a HUB, mert azt fogod látni majd a propagandatesztekben, függetlennek álcázva, hogy az 5070 gyorsabb a 4090-nél és csak 549 dollár. Nem lesz olyan oldal, ami megmutatná neked, hogy ez egy orbitális hazugság volt. Nyilván ilyen szempontból teljesen érthető, hogy az NV miért akarja, hogy a GN és a HUB a propagandájukat gyártsa le, csak ettől neked userként pont, hogy nem lesz jobb, mert hasznos információktól fosztanak meg majd téged. -
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51566 üzenetére
Az elég nagy probléma lenne, hiszen akkor a cikk írója kijelentené, hogy a szerkesztőségi irányelveket felül tudja írni egy külső cég, csak azzal, hogy megzsarolja az oldalt valamivel.
A gyártók folyamatosan kérik a médiát ennek és annak a tesztelésére. Ez évek óta így van. A különbség az, hogy nem zsarolták eddig a médiát a termékek elérhetőségével. Mert a kérés az tök rendben van, ugyanis a média tudja azt mondani rá, hogy "menjetek a faszba", és semmilyen retorzió nincs utána. -
Abu85
HÁZIGAZDA
válasz
deathcrow42 #51558 üzenetére
Egy valamire való oldal eleve nem ír alá egy olyan szerződést, amiben a hardvert biztosító fél beavatkozik a szerkesztési irányelvekbe. Hiszen, ha valaki megteszi, akkor megszűnik az oldal függetlennek lenni.
Ami most történik, hogy a két Steve problémásnak tartja, hogy az MFG teszt egy feltétele annak, hogy hardvert kapjon egy média. Ez szintén beavatkozás a szerkesztési irányelvekbe. Ha ennek valaki enged, akkor nem független médiatermék lesz, hanem cégpropaganda. Emiatt van az, hogy a függetlenségükre valamit is adó oldalak, inkább vállalják, hogy nem tesztelik a terméket időre, de nem engedik meg azt, hogy a függetlenségükről lemondjanak.
#51559 FLATRONW : Ez akkor lenne elvárás, ha nem fenyegetnének azzal, hogy ha nem teszed meg, amit kérnek, akkor elvesznek tőletek dolgokat. Például a hardverhez való hozzáférést. És itt most nem az MFG-ről van szó, hanem a független média elveiről. Hogy nem engedik meg azt, hogy az adott médiát egy cég propagandafelületként használja.
#51560 lenox : Elég nagy hátrány is, hiszen gyakorlatilag a fennmaradás függ attól, hogy van-e hardver időre. Az alapvető gond az, hogy az NV rájött arra, hogy a világ már nem vágyik független, hiteles tartalomra. Annyira sok a YouTube tesztelő, hogy lassan mindenki zaj lesz. Emiatt nem számít, hogy a GN vagy a HUB fennmarad-e, mert százával várnak a helyükre azok, akik hajlandók propagandát rakni a felületükre. És a nézőnek ez is jó, mert annyira a tartalomfogyasztás számít már, hogy nem érdekli a userek úgy 99%-át, hogy amit néz az független tartalom-e, vagy propaganda. Emiatt állt bele ennyire a két Steve, mert ők ilyen szempontból nagyon sérülékenyek, egy olyan felületre dolgoznak, ahol a nézők 1%-a foglalkozik ezzel a kérdéssel, így muszáj saját maguk kihangsúlyozniuk, akár nyers eszközökkel is, hogy aki MFG-t tesztel, az lehet, hogy propagandista. Ezzel a saját függetlenségüket végzik.
#51561 Egon : Kérni lehet kérni bármit. Rengeteg kérés érkezik felénk is, csak független média vagyunk, így visszautasítjuk az igényeket a tesztelési módszerekre.
A GN és a HUB azért tolja ezt ennyire hangosan, hogy felnyissák a userek szemét, hogy ők nem engednek a zsarolásnak. Így próbálják a saját munkájukat értékként beállítani. És ezzel nagyot kockáztatnak, mert így elveszítik majd a hozzáférést azokhoz a lehetőségekhez, amikből kontentet tudnak gyártani, de a másik lehetőség, hogy az NV propagandaoldalai lesznek, amit viszont nem akarnak, mert a függetlenségüket áldoznák fel.
-
Abu85
HÁZIGAZDA
válasz
Heroes fan #51555 üzenetére
A 9060 XT teljesítményben nem az 5060-nal, hanem az 5060 Ti modellel versenyez. Az 5060 ellen nem lesz semmi, mert árban az 5060 ellen van árazva a 9060 XT. Régen még volt szó 9050-ről, de szerintem nem adják ki még, de az nem új lapka. Az AMD-nek a gondja, hogy a Navi 44-et nem lehet úgy lassítani, hogy jó versenytársa legyen az RTX 5050-nek. Az NV ide külön GPU-t tervezett, hogy legyen elég alacsony a teljesítménye, de a Navi 44-et nem tudod úgy megvagdosni, hogy végül nagyon az 5060 alá menjen sebességben.
-
Abu85
HÁZIGAZDA
Egy nagyon apró, de annál lényegesebb különbség van. Az NV nem kéri, hogy teszteljék a képgenerálást. Követeli, és ha ezt nem teljesíti valaki, akkor nem adnak kártyát. Ez ilyen formában zsarolás. Ha csak kérnék, akkor semmi baj nem lenne, mert minden szerkesztőség hozzájutna a hardverhez, és elküldhetné a picsába az NV-t. Itt viszont alapvetően arról van szó, hogy mivel az NV a hardver elérhetőségével zsarolja a médiát, nem tudni, hogy a megszülető tesztek manipuláltak-e, vagy tényleg függetlenek. Erről beszélt a két Steve nemrég.
-
Abu85
HÁZIGAZDA
Mi köze az ARM-nak ahhoz, hogy nincs 32 bites CUDA runtime?
Használhatják, hiszen van hozzá támogatás. Ezt kellene az NV-nek is csinálni, és nem lenne annyi bug a meghajtókban.
A ZLUDA az egyetlen reális lehetőség arra, hogy a GPU-s PhysX valaha is működőképes legyen még az RTX 50-es VGA-kon.
#50995 D55 : Nem, ez nem hardveres gond. Egyszerűen hiányzik a 32 bites CUDA runtime. Az NVIDIA nem írta meg a szoftvert. Túl drágának tarthatták, így nem fért bele a költségkeretbe. Azért vegyétek számításba, hogy az NV már egy AI cég. A K+F AI-ra megy, és ha ezért be kell áldozni mást, mondjuk a GPU-s PhysX-et, akkor beáldozzák, mert az AI-ból jön vissza a pénz, a GPU-s PhysX-ből nem. Az NV egy profitorientált cég, ha valamit túl drágának ítélnek, és nincs reális megtérülése, akkor nem írják meg a szoftvert. Tök mindegy, hogy mennyire érinti hátrányosan a játékosokat, ez már nem a fő piac. Ha emiatt bepipulnak a userek és nem vesznek több GeForce-ot, akkor több kapacitás marad a drágábban eladható AI gyorsítókra, tehát az NV-vel ezzel nem csesznek ki, csak több pénzt fognak keresni akkor, ha nem kell több GeForce-ot gyártani.
-
Abu85
HÁZIGAZDA
válasz
Busterftw #50991 üzenetére
A ZLUDA van messze a legközelebb ahhoz, hogy ez az egész egyáltalán működjön, mert pont azt biztosítja, amit az NV már nem szállít.
Kibaszottul hangsúlyozom, hogy ehhez nem nyílt PhysX kell. Nem a PhysX-szel van probléma, hanem a futtatási környezet hiányával. A kód a játékokon belül működik, azt értelme sincs cserélni, mert nem amiatt nem futnak az effektek. Új futtatási környezet kell, ami meg tudja enni a kódot, és el tudja juttatni a GPU-ra. Ez tényleg nem világos?
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #50984 üzenetére
Oké, akkor segítek.
Tehát vannak játékok, amelyekben nem megy a GPU-s PhysX a GeForce RTX 50-es sorozaton. De fontos megérteni, hogy nem a játék baszódott el, hanem a 32 bites CUDA támogatása nincs meg. Konkrétan hiányzik a runtime, ami a játékba épített kódot futtatni tudja.
A megnyitott kód sem kompatibilis azzal, amit a játékok tartalmaznak, mert a szóban forgó címek még valamelyik PhysX 2 verziót használták, és az 5.6.0 lett megnyitva. Tehát jelentős eltérés van a korábban szállított és a most megnyitott kódok között.
De nem ez a gond, hanem az, hogy akkor sem érnénk el semmit, ha az adott játékban szállított PhysX 2 GPU-s kódját nyitná meg az NVIDIA, mert az alapprobléma nem ez a kód, ez le van szállítva valamilyen köztes nyelvre lefordítva, de a futtatási környezet már nem létezik a hardver felé. Tehát ahhoz, hogy ez működjön a jövőben, egy másik futtatási környezetre van szükség. Hiába cseréled a kódokat a játékban valahogyan, attól még futtatási környezeted nem lesz.
Ennek több megoldása van egyébként:
- Az egyik, hogy átírják kódokat compute shaderre, de az nagy meló, viszont ehhez csak DirectCompute futtatási környezet kell, az meg ugye ott van még mindig az összes meghajtóban.
- A másik, hogy használod a HIP-et. A kódra ráereszted a Hipify-t, de ez sem túl előnyös, mert maga a HIP kód is igényli a CUDA futtatási környezetet. Tehát ezzel a módszerrel csak azt oldanád meg, hogy AMD-n működjön a GPU-s PhysX, de GeForce RTX 50-en továbbra sem fog. Akkor működne csak, ha az NVIDIA írna direkt támogatást a HIP-hez.
- A harmadik megoldás a játék visszafejtése, és a 32 bites bináris átfordítása 64 bitessé. De annyi buktatója van ennek, hogy szinte lehetetlen megcsinálni, anélkül, hogy meglenne a közösségnek az eredeti játék teljes forráskódja. És itt tényleg csak az a gond, hogy 32 bitből nehéz forráskód nélkül 64 bites programot csinálni. Ezt nem oldja meg a nyílt PhysX, mert ettől pont az a tényező hiányzik még, amire szükség lenne: a játék forráskódja. Azzal nem nyers semmit, hogy kicseréled mondjuk a PhysX-re vonatkozó dll-t, mert vagy a 32 bites CUDA runtime, vagy a 64 bites futtatási állomány fog hiányozni.
A ZLUDA azért reális alternatíva, mert az a gyökerénél kapja el a problémát. Nem foglalkozik azzal, hogy átírja a játékot, mert eleve nem az a gond. A runtime hiányzik, és mivel a ZLUDA nem igényel 32 bites CUDA runtime-ot, a CUDA kód futtatásához, ezért pont megkerüli azt a problémát, ami hiányzik a GeForce RTX 50-es sorozatnál. Ezzel a módszerrel nem kell átírni a játékot, nem szükséges visszafejteni azt, nem szükséges a játék forráskódja, mert a 32 bites CUDA runtime-ot cseréli egy olyanra, ami képes gépi kódot generálni a GPU-kra. Azokra is, amelyeknél az NVIDIA nem akarja, hogy kapjanak emészthető kódot, például a GeForce RTX 50-es sorozat.
Egyébként nem muszáj a ZLUDA, más hasonló kezdeményezés is jó, de muszáj azt a tényezőt célozni, ami hiányzik, és az a 32 bites CUDA runtime. Mert hiába cseréled a GPU-s kódokat a PhysX-ben, ettől még runtime-ot nem ad az NVIDIA neked a meghajtóban, ami lefordítja a kicserélt kódot a Blackwell GPU-kra. Tehát nekünk nem a játékot kell babrálni, hanem másik runtime-ot kell írni, ami az NVIDIA hozzájárulása nélkül is kódot generál a GPU-kra.
---
Ami történik a PhysX-szel az nem a régi játékok futtathatóságát szolgálja. Az NVIDIA projekteket indít, fejleszt és zár le. Nagyon tipikus policy ennél a cégnél, hogy ha egy projektet már nem akarnak fejleszteni, akkor megnyitják. És ezért nyitották meg a mostani kódokat, mert a jövőben már nem akarnak ehhez hozzátenni. Ugyanígy tettek a GameWorks bizonyos effektjeivel, stb. Az a célja ennek, hogy a jövőben egy ponton túl nem lesz support. Ott a forráskód és mindenki megoldhatja maga a problémáját, az NV ebből kiszállt, mert nem látják már a hasznot a projektben. A GameWorks után most a PhysX jutott el erre a szintre. Az NVIDIA mindig így csinálja. Ha lelőnek belsőleg egy projektet, akkor megnyitják, hogy vihesse mindenki.
Egyébként más cég is így csinálja. Ha volt egy zárt projekt, amire már nem akarnak figyelni, akkor azt meg szokták nyitni. Ez a jelzés, hogy a projekt már nem fókusz, de aki akarja használhatja tovább, ha karbantartja a saját kódját.
-
Abu85
HÁZIGAZDA
válasz
huskydog17 #50959 üzenetére
Ezzel a nem működő játékokat nem lehet helyrerakni. Nem a PhysX a gond, hanem a CUDA 32 bites futtatási környezetének hiánya. Azt egy nyílt PhysX nem oldja meg, mert egyrészt attól még nem tudod kicserélni a játékban a kódot, másrészt nem tudod a 32 bites binárist átalakítani 64 bitessé.
Ezt a problémát a ZLUDA kezdeményezése tudja megoldani, ami lehetővé tenné a meglévő kód futtatását a 32 bites CUDA futtatási környezet nélkül is.
-
Abu85
HÁZIGAZDA
válasz
gainwardgs #50544 üzenetére
A többiről nem tudok. Az F1 24-nél ez ismert. Az RT okozza, és igazából az AMD-n is okoz valamennyire mikroakadásokat, csak pont nem az RDNA4-en, mert ez hardverből immunis arra, ami ezt ebben a játékban okozza. Azért nem látod az új Radeonokon. De ezt a korábbi VGA-kon, se AMD-n, se NV-n nem lehet javítani driverből. A programot kell átírni, pontosabban optimalizálni.
-
Abu85
HÁZIGAZDA
válasz
gainwardgs #50540 üzenetére
Nem. F1 24. Ismert probléma. Ki kell kapcsolni az RT-t és jó lesz.
-
Abu85
HÁZIGAZDA
válasz
Busterftw #50509 üzenetére
Ennél sokkal egyszerűbb a magyarázat. A játék maga a Path Tracing módban nem engedi, hogy allokáljon több memóriát Radeonon 13 GB-nál. Hiába van mondjuk 24 GB a 7900 XTX-en. Nem férhet hozzá, mert a kötelező allokáció 13 GB. Ezért nullázik 7700 XT-n, mert ott meg az allokáció maga nem történhet meg a 12 GB VRAM miatt. Az AMD hozhat 100 GB-os VGA-t is, akkor is kötelezően 13 GB-ra vannak kényszerítve a játékban. Az egyedüli megoldás a Path Tracing kikapcsolása, mert akkor már úgy allokálja a Radeon memóriáját a játék, mint a többi VGA-ét, és elkezdi használni az egészet.
Majd a Crimson Desert című játéknál fogják visszaadni ezt a cukiságot, mert exkluzív szerződést kötöttek a Pearl Abyss-szal.
-
Abu85
HÁZIGAZDA
válasz
4264adam #50393 üzenetére
Igazából elég kevés, azért fut lassan, mert koncepcióból van lassúra tervezve. De amúgy ezt a mai CPU-k simán kinyomnák magukból, csak nem olyan a kód, hogy megcsinálják, ezért a rossz kód miatt lassú az egész. Valószínűleg ezért is van némi ellenérv, hogy ez valaha is nyílt forráskódú legyen, mert akkor látnák, hogy mennyire lassú futtatásra volt tervezve koncepcióból. Na nem mintha olyan nagy titok lenne, csak az bizonyít lenne. Emiatt is pusztult ki, mert jöttek a komolyabb fizikai motorok, amiket jól integráltak az egyes motorokba, és azok lealázták a PhysX-et teljesítményben. Onnan még növelhették volna a teljesítményt, de az NV inkább lelőtte a fejlesztést, és átvitték a robotikára.
-
Abu85
HÁZIGAZDA
válasz
BerserkGuts #50390 üzenetére
De játszható teljesen. Ki kell kapcsolni a GPU-s PhysX effekteket. Amúgy is csak grafikai dolgok.
-
Abu85
HÁZIGAZDA
válasz
Komplikato #50387 üzenetére
Elég sok költség lenne, mert akkor meg kellene tartani a 32 bites CUDA támogatását. És itt igazából ennek a karbantartási költsége a gond. Meg eleve a GPU PyhsX az utóbbi években egy nagy nyűg lett. Gyakorlatilag minden driverben ott van, de évek óta semerre sem fejlődik. Vagyis minden egyes driverben szükséges lefuttatni a teszteket rá, ami gyakorlatilag kidobott pénz. Mivel ez nem szabvány, így nem kötelező ezt a végtelenségig támogatni. Az NV bármikor dönthet arról, hogy inkább kihúzzák a támogatást és elengedik. Ezzel azért kb. tízezer dollárt spórolnak évente. És ez lehet, hogy kevésnek tűnik, de az NVIDIA ezt úgy nézi, hogy miért költsenek erre, ha semmi haszna? Ezért az NV szemszögéből ez sok költség, mert ők a 0 dollárt tartják elfogadhatónak.
A megoldás erre az lenne, ha kiadnák a PhysX teljes forráskódját. A GPU-sat is, és akkor a community meg tudná oldani a támogatást. Szimplán átírják a teljes kódot compute shaderre és meg van oldva az örökös support, mert a compute shader egy szabványos API-hoz van kötve, azt azért kötelező támogatni.
#50388 rumkola : Két külön dologról beszélsz. A CPU-s PhysX runtime még most is működik, hiszen annak a 32 bites binárisa le van fordítva x86-ra, és amíg ez az ISA nem kerül ki a CPU-kból, addig a futtatásával sem lesz gond. A GPU-s PhysX döglött meg. Az pár tucat játék csak. De a szóban forgó játékok is működnek tovább, csak a GPU-s PhysX nem megy, de a CPU-s PhysX megy, ahogy előbb említettem, az binárisan van fordítva, és az csak x86 ISA-t igényel.
-
Abu85
HÁZIGAZDA
válasz
gejala #50359 üzenetére
A gyártók szerint nem egyetlen hiba okozza, hanem legalább egy tucat különböző hibát azonosítottak, ami fekete képernyőhöz vezet. Ebből hármat oldottak meg, amik mindegyike csak az RTX 50-en jött elő.
Az egyik hiba pedig a shader fordítóból eredhet, legalábbis erre utalnak azok a tesztek, hogy az új driverek a régebbi shader fordítóval jól működnek. És ez azt jelenti, hogy a fekete képernyő attól van, hogy az egyes kártyák beállított órajelei nem bírják az új shader fordító jobb hatékonyságát. Effektíve olyan, mint az instabil tuning, lefagynak, csak alapórajelen teszik, vagy gyári tuninggal. Mondjuk ezt könnyű megoldani, mert csak vissza kell lassítani a fordított shader kódokat, és akkor megszűnik a gond. Néha fordítanak bele random NOP-ot, és akkor kényszeríthető a hardver arra, hogy ne dolgozzon semmit. Csak nyilván ki kell deríteni, hogy worst case mennyire kell visszalassítani a fordítót, hogy elmenjen vele a gond.
-
Abu85
HÁZIGAZDA
Nekem mindegy, hogy az NV mit tesz. Azt is elfogadom, ha úgy gondolják, hogy elfogadható az, hogy nem tudod ellenőrizni, hogy jól csatlakozik-e a kábel. Ettől nekem semmi bajom nem lesz. De ez nem bolondbiztos a megoldás, és ebből csak az NV fog kijönni rosszul. Ráadásul most még tehetnének valamit, mert alig tízezres tételt szállítottak, tehát simán vissza lehetne hívni mind, és áttervezni a tápáramkört. Mindössze három hónapot veszítenének, és lenne egy bolondbiztossá tett megoldásuk, ami nem tudna leégni. Ez alapvetően a userek, a gyártók és az NVIDIA érdeke. Akár a tiéd is, ha valaha vennél majd ilyen hardvert.
Der8auert is kikezdték, pedig nem akar mást, csak azt, hogy ti felhasználók minőségi hardvert kapjatok a pénzetekért. Neked például érdemes eldönteni valamikor, hogy a saját érdeked ellensége vagy-e.
-
Abu85
HÁZIGAZDA
válasz
-=RelakS=- #49965 üzenetére
Igazából nem ócska a kártya, csak nem készült fel a dizájn minden eshetőségre. Kvázi nem bolondbiztos. És a bolond most nem bántás. Ez így egy mérnöki probléma, mert be lehet helyezni a csatit úgy, hogy látszólag fasza, aztán mégsem az, de erről semmilyen információt nem kapsz. Ettől a kínai cucctól sem. Tehát a dizájn jó, csak nem bolondbiztos. És csak az NV tudja megoldani, hogy bolondbiztos legyen. Az ilyen kínai cégek addig egyszerű dolgokkal hülyítik az embereket, hogy drágáim, ez megoldja, csak adjátok nekem a pénzem. Az egészen kb. mindenki veszít. Az NV bizalmat, a user VGA-t, de a kis kínaiak nyernek rajta, mert fillerés holmikat tudnak eladni, mert a user reménykedik, hogy hátha biztonságosabb lesz. Amúgy nem lesz.
-
Abu85
HÁZIGAZDA
válasz
-=RelakS=- #49963 üzenetére
A kártyára, ahogy a 3090-nél volt.
Semmit, ez a kábel oldalán nem megoldható probléma. A VGA-gyártók tudják megoldani. A tápgyártók maximum annyit tudnak tenni, mint az ASRock, hogy raknak hőszenzort a kábelbe, így lelövik a tápot, ha 105°C a hőmérséklet a csatlakozón belül. De ez sem igazi megoldás, mert ekkor nem egy leolvadó géped lesz, hanem egy instabil géped, ami lefagy terhelésnél.
Ezt senki nem tudja megoldani az NV-n és a partnerein kívül!
-
Abu85
HÁZIGAZDA
válasz
-=RelakS=- #49960 üzenetére
Amit a 3090-nél alkalmaztak: load balancing. Csak akad rá 5 dollárjuk kártyánként, de ha nincs szerintem bele is rakhatnák az vételárba. A userek kifizetnék.
#49961 VoltanIgor : Még ha azon segít is, a táp oldalán nem segít, és ott is izzani fog. Tehát a gondot egészében nem oldja meg.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW #49871 üzenetére
Az mindegy, mert a 32 bites runtime-ra az offloadhoz is szüksége van a hardvernek, kell az API interoperabilitáshoz. Tehát a társkártyás irány is le lett zárva.
Az offload régen azért működött, mert ugyanazt a runtime-ot betöltötte a fő GPU és a társkártya is. De ugye most pont az a baj, hogy a Blackwell ezt nem tudja már betölteni. Tehát már az API interoperabilitásra sem képes, így az offloadra sem.
Technikailag ez úgy működhetne, hogy a CPU-n futna a runtime, de arra meg timebomb van a driverben, hogy Radeon mellé ne rakj társ GPU-t PhysX-re, és ugyanúgy timebombozná a Blackwellt is, mert maga a védelem azt nézi, hogy a runtime be tud-e töltődni a fő GPU-n. Ha nem, akkor tuti, hogy az Radeon.
Ezt amúgy még mindig ki lehet szedni, csak az egész driver erre van felépítve, tehát az egész nagyon körülményes. Újra kellene írni az egész supportot, annak az összes tesztelési költségével. Erre pénzt nem fognak áldozni, egyszerűbb az, hogy kuka az effekt és kész.
Az egésszel egyébként nyer az NV, mert így egy csomó játékot kiütnek eleve, az újabbak még mennek, de alig van ilyen cím. Szóval idővel a teljes GPU PhysX runtime kiszedhető. És akkor ennek a tesztelési költsége is megspórolható. A PhysX 4/5 amúgy is robotikára van tervezve, és azt lehetne majd pénzért adni. Tehát nemhogy olcsóbb lenne a driver fejlesztése, hanem egyenesen pénzkereseti lehetőséget adna.
-
Abu85
HÁZIGAZDA
válasz
Busterftw #48225 üzenetére
Most ugye tudod, hogy melyik cégről beszélünk? Milliárdokat termel negyedévente, és nem szeretnének havi plusz százezer dollárt költeni azért, hogy nektek legyen +10%-otok?
Most ne haragudj, de te is tudod, hogy a userek nagy része nem ért hozzá. Fingja sincs, hogy mi a jó neki, csak korlátozott információk alapján kiszelektálnak egy baromságot, és torkuk szakadtából ordítják, hogy az nekik nem jó. Az NV ráadásul pontosan tudja a vásárlóbázisáról, hogy segítség nélkül felbontást sem tud váltani a 99%-uk. Tehát most tényleg olyan emberek véleménye alapján kellene meghatározniuk a szoftveres döntéseiket, akik három kattintást nem tudnak önállóan elvégezni?
-
Abu85
HÁZIGAZDA
válasz
Busterftw #48221 üzenetére
Elbeszélünk mind egymás mellett. Nem kötelező ám a régi hardverek supportját leállítani. Erre van az úgynevezett legacy support. Ott is annyi drivert hoznak, amennyit akarnak. Ha havi 10-et, akkor havi 10-et, senki sem akadályozza meg nekik. Ami viszont hasznos lenne, hogy le kellene választani a régi hardvereket a fővonalbeli supportról, mert már nagymértékben rontja az új VGA-k sebességét a kötelezően régi hardverekhez igazodó kód. Aztán lesz két driver. Egy fő és egy legacy. Mindkettőt az adott hardverekre lehet szabni. Aztán tényleg hozhatnak belőlük naponta frissítés, senki sem mondja, hogy ne tegyék.
Egyébként az AMD sem csinál mást. Van egy GCN batch és egy RDNA batch. És nekik még nem is különbözik olyan extrém módon a két alapdizájn, mint az NV-nél, így az AMD maximum +2-3%-ot nyer ezzel a megközelítéssel, nem tudnak kihozni belőle +10-15%-ot, ahogy az NV ki tudna.
-
Abu85
HÁZIGAZDA
válasz
BerserkGuts #48209 üzenetére
Alapvetően igen. Ha az NV átírná a D3D12 implementációját, hogy natívan kezelje a legtöbb erőforrást, akkor gyorsulna.
-
Abu85
HÁZIGAZDA
Létezik egy overhead probléma, évek óta van, de azt addig nem tudja korrigálni az NV, amíg támogatni kell az Ampere sorozatot, illetve alatta minden korábbit. Ha csak az Ada és a Blackwell marad a support listán, akkor megoldhatóvá válik, mert az overheadet alapvetően az okozza, hogy az újabb hardverek hiába jobbak a bekötés szempontjából, a Maxwell/Pascalra szabott modell fut rajtuk is, ami sokkal több CPU-időt vesz el. És ezt nem csak a HUB mérte ki, tényleg nem tagadja senki sem a gyártók részéről. De ahhoz, hogy ezt lecseréljék le kell állítani a Maxwell, Pascal, Turing és Ampere supportot. Az Ada és a Blackwell abból a szempontból szerencsés, hogy a két dizájn megegyező bekötést alkalmaz hardveresen. Egyébként már azzal sokat érnének el, ha a Maxwell és a Pascal búcsúzna, mert a Turing és az Ampere is modernebb hardver, de igazán ezt a négyet kellene kidobni. Vagy a másik megoldás, hogy szétválasztják a drivert, ahogy az AMD tette, hogy van egy GCN-es batch és van egy RDNA-s batch. Ugyanezt az NV is meg tudná csinálni, és akkor Maxwell/Pascal kuka, lenne egy Turing/Ampere batch és lenne egy Ada/BW batch. De ezzel meg az a gond, hogy úgyis az új batch kapná a figyelmet, ahogy az AMD-nél is igazából az RDNA-s batch-re koncentrálnak. Tehát ennek a módszernek is megvan a maga hátránya. Ráadásul az AMD-nél nem is kell nagyon eltérő implementáció RDNA-ra és GCN-re, míg az NV-nél nagyon eltérő kellene a Turing/Ampere és az Ada/BW-re. Az a helyzet, hogy jelenleg az NV számára egyszerűbb és olcsóbb a Pascal dizájnt célozni emulációval a bekötés szempontjából, és akkor mindegyik új hardver emulál. A CPU oldalán megvan rá az erőforrás. Csak nem hasznos például 1080p-re meg 1440p-re az új 5090-en még a legerősebb CPU-val sem.
-
Abu85
HÁZIGAZDA
válasz
Raymond #48190 üzenetére
Nem ezt mondta anno a HUB. Ott arról volt szó, hogy az AMD driver overheadje sokkal kisebb, és ezt onnan lehetett detektálni, hogy a két Radeon a tesztelt két, hasonló kategóriás GeForce mellett sokkal jobban teljesített ugyanazokkal a CPU-kkal, ha a CPU-limit látható volt. Lásd itt:
És természetesen lehet azt mondani, hogy ez azért nem volt gond, mert mondjuk RTX 3080 alá nem vesz senki sem Ryzen 5600X-et. Ami igaz, de most mit veszel majd a Ryzen 9800X3D helyett az RTX 5090 alá? Ja, hogy nincs gyorsabb proci. Hát igen, így már a driver overhead probléma, mert nem tud skálázódni a VGA, gyorsabb proci híján.
-
Abu85
HÁZIGAZDA
Ez az RTX 50 kezdőkészleti hiány is félig kamu. Igazából arról van csak szó, hogy a kezdőkészlet kb. 90%-a az USA-nak ment. Ez nyilván minden USA-n túli piacot szarul érint, de az USA-ban lesz elég termék.
-
Abu85
HÁZIGAZDA
Azért a neurális shadereket ne keverjük ide. Azokat tök egyszerű lesz támogatni a DirectX új shader modell frissítésével, hiszen abban jönnek a kooperatív vektorok. És ennyi. Nem kell semmi más hozzá, ráadásul ezeket azért visszafelé is elég jól támogatják a meglévő hardverek. Nem csak az érkező generáció, hanem már az előzőek is. Még a Qualcommnak a rém buta Adreno IGP-je is tudja támogatni. Tehát ez egy olyan képesség, amelyre a hardver már most ott van több tízmilliónyi user számítógépében. Nem kell hozzá új GPU-t vásárolni.
A többi dologgal sokkal nagyobb munka van. Például a Displaced Micro-Mesh Engine, vagy a Opacity Micromap Engine azért nem terjedt el semennyire, mert kétszer kell hozzá megtervezni a tartalmat a játékba. És itt a geometriára kell gondolni. Ez a gond velük, illetve általában a geometriát érintő fejlesztésekkel. És amíg ezek szabványosak, addig ez vállalható, mert akkor tervezed erre a tartalmat, de kétszer senki nem fogja ezeket letervezni és szállítani. Emiatt nem ugyanaz a dolog, mint mondjuk a neurális shaderek vagy a SER esetében, amelyek ugye nem növelik meg egy 4 évig fejlesztett játék fejlesztési idejét 6 évre. Vagy, ha 4 év alatt végezni kell, akkor nem kell másfélszer több embert alkalmazni, hogy legyen letervezve kétszer a tartalom.
#47867 gbors : Nem is mondtak mást. Az NV elsődlegesen a DLSS4-gyel hangsúlyozza a teljesítménynövelést. Alma-alma vonalon nem mondanak annál többet, amit megmutattak a mostani dián. Ezt csak azért rakták bele így, hogy senkit se érjen váratlanul, és ezt ki is hangsúlyozták. Ez azért fontos, mert így kritikus szempont azt hangsúlyozni, hogy DLSS4-gyel jön majd a teljesítmény, amiről szólniuk kell majd a teszteknek.
-
Abu85
HÁZIGAZDA
[link] - igen, bár nem hiszem, hogy csodadriver, egyszerűen csak arról van szó, hogy kicsi a PAL többletterhelése, mert nagyon hatékonyra van megírva. De a helyzet egyértelmű, ma már az AMD driverének a többleterhelése a legkisebb.
Igen, ma már alig van olyan CPU, amiben nincs IGP. Tehát effektíve mindenki APU-t vásárol jelenleg.
Egyedül azt nem értem, hogy ez hogyan tartozik a topikhoz.
-
Abu85
HÁZIGAZDA
Egyébként erre visszatérve, igazából a Microsoft sem annyira rossz. Itt igazából arról van szó, hogy van egy nagyon fontos feladat most, amire elmegy az erőforrás. A shader modell jóra tervezése. És ez marha sok munkát leköt. Emiatt a DirectX-be most csak olyan funkciók kerülnek, amelyek viszonylag könnyen integrálhatók a szabványba. Egy SER például nem ilyen, vagy mondjuk a DGC sem. Tehát nyilván a Microsoft is érzi, hogy mire lenne igény, de a shader modell 7 mindennél fontosabb, mert konkrét funkciók buknak el azon, hogy nem elég modern a háttér itt.
Az NV újításai elérhetők lesznek a szabványon túl, aminek megvan a haszna, de az mindig egy olyan kockázat, hogy lesz egy extra kódutad egy adott hardveres generációra. Ez egy rakás melóval jár. Például azzal, hogy csak egy generáció kap egy extra kódutat, amit aztán külön karban kell tartani. Figyelni kell arra, hogy az a külön kódút a következő generációnál hogyan működik. Lásd ugye a DMM esete, ami volt a 40-es RTX sorozatban, de az 50-esben már nincs. Tehát ha valaki beépítette volna ezt egy játékba, akkor az a játék most nem futnak az 50-es szérián, vagyis ki kellene adni rá egy patch-et. Vagy ha úgy építette volna be, hogy ha RTX 40-et detektál, akkor kapcsolja be, akkor arra kellene patch, hogy a még érkező hardvereknél kapcsolja be, ahol elérhető. Ezért van az, hogy a szabványra várnak a fejlesztők, mert ott egyértelmű, hogy mi a követelmény a gyártók felé, és nem a gyártók döntenek arról, hogy ilyen-olyan fícsőrt egy-két generáció múlva kiszednek.
-
Abu85
HÁZIGAZDA
Az RT esetében a szabványos megoldás a döntő, mert azt támogatják a játékok. A GeForce RTX 40-ben is van Displaced Micro-Mesh Engine, Opacity Micromap Engine, Shader Execution Reordering. Ezek közül a Cyberpunk 2077 használta egyetlen egy beállításra a Shader Execution Reorderinget, és nem is a legjobb minőségre, mert abban nincs ott. Tehát a 40-es sorozat három nagy RT újításából egy jutott el a játékosokhoz, egyetlen egy játékban, egyetlen beállításban. Ja és az 50-es szériával a Displaced Micro-Mesh Engine megy a levesbe, vagyis az úgy halt meg, hogy nem is használta semmi. Hihettek abban, hogy ezeket majd használni fogják, de előbb szabványosítani kell őket. A Shader Execution Reordering egyébként kurva jó, tényleg megérné szabványosítani, de annyira lassan halad mostanában a Microsoft, hogy az AMD is inkább olyan hardveres megoldást épített magának, hogy ne kelljen specifikus kódot írni ennek a működéséhez, hanem működjön bármilyen kóddal. És nem azért van ez, mert jobb a hardveres megoldás, hanem azért, mert igazából a jelenlegi tempóval ezt a Microsoft akkor fogja szabványosítani, amikorra a most érkező generáció már a múzeumokban lesz.
-
Abu85
HÁZIGAZDA
Ezt az NVIDIA osztotta meg a hivatalos prezin. Nekik szerintem elhiheted.
#47849 PuMbA : Az RT-nél valós teljesítmény az igazából ott van, ahol a 40-es széria teljesítménye volt, mert minden előny, amit említettél olyan funkciókból jön, amelyek a DirectX Raytracingben nem érhetők el. Az nagy kérdés, hogy a Microsoft ezeket mikor építi be. Egyelőre nagyon lassan haladnak a DXR fejlesztésével, mert a traversal shader is évek óta csúszik. Az NV újításai még nincsenek is megszavazva a GAB által, és ez a lépcső nagyon fontos, mert az NV-nek a DGC-je is évek óta ott áll a Microsoftnál, pedig kész, alapvetően a legújabb hardverek is támogatják, a konkurens hardverek is, és sehol sem tart még. A szabványosítása el sem kezdődött.
-
Abu85
HÁZIGAZDA
válasz
Quadgame94 #47844 üzenetére
Nem ez a baj. Maga a Blackwell SM igazából összefűzte a feldolgozókat. Amíg ezek különállók voltak, addig külön port is volt rajtuk, stb. Most közös a port is, miközben az eredeti dizájn elemei megmaradtak, vagyis nem változott a konkurensen futtatható warpok száma, miközben a SIMD hossza lényegében megduplázódott. Ez alapvetően hasznos például a neurális shaderekhez, de minden másnál hátrányos valamennyire. Ezt majd a következő generációban orvosolják elvileg, amikor a konkurens warpok száma is megduplázódik, hogy igazodjon a hardver strukturális változásaihoz. De addig ez a dizájnváltás a tradicionális feladatokban visszalépésnek számít. Viszont neurális shaderekben előrelépés. Ezzel a hardverrel nagyon a jövőre készült az NVIDIA, csak eléggé messze vannak a neurális shaderek, mert azoknak nincs alternatívája, nincs fallbackje, tehát vagy megy vagy nem, ergo meg kell várni, amíg mindenkinek RTX 50-je vagy RX 9000-je lesz. Mondjuk még szoftveres szinten sem áll erre készen az API, tehát előbb ezt kell megvalósítani a HLSL-ben. Az is legalább egy év innentől számolva.
Itt igazából a TSMC 4 nm a legnagyobb limit. Kurva sok feldolgozót lehet abba rakni, csak nem lehet mindent. A Blackwellnek hatalmas a gyomra, de nagyon szűk a nyelőcsöve. Kell a 2 nm, hogy a nyelőcső is vastag legyen.
-
Abu85
HÁZIGAZDA
Itt van teljesítményteszt DLSS4 nélkül. A Resident Evil 4 DLSS nélkül, vagyis natívban. Azért lett ez kiválasztva, mert ez a best case scenario. Fix szám nincs, de ott ez fps-t jelent. 10-20% között van az extra.
Ugye a többinél azért sokkal nagyobb az előrelépés, mert 1 vs. 3 generált képkocka van összehasonlítva.
#47843 b. : Nem altatnak. Kiadták eléggé világosan, hogy mi van. A kép, amit beszúrtam az az fps-t méri, nem számítási teljesítményről van szó.
-
Abu85
HÁZIGAZDA
[link] - ez a lényeg. Ez már nem a klasszikus értelemben vett GPU, hanem egy olyan formája, ami már egyszerűbben programozható.
Mindenki, aki heterogén memóriamenedzsmentet biztosít, nem ért egyet azzal, hogy hagyományosan kell bekötni a GPU-t. Jelen pillanatban az AMD sem, az NVIDIA sem, és később az Intel sem fog, csak ők még nincsenek kész a saját megoldásukkal.
A hogyan egyébként lehet sokféle, nyilván az MI300A hardverkiépítése más, mint a GH200 Superchipé, de az elvi háttere, hogy miért csinálják ezt, ugyanaz. És ha ez nem lenne fontos, még ma is PCI Express sávokon lenne nem koherens módon bekötve a GPU.
-
Abu85
HÁZIGAZDA
Ez tök jó, csak ha rád építenék a stratégiát, akkor éhen halnának a cégek. A tömegpiacra kell stratégiát építeni, és ott bizony most a Cray EX255a és a Cray EX254n megy. Amik már nem klasszikus dedikált GPU-s rendszerek. Ha ilyenre volna igény, nem a Cray EX255a és a Cray EX254n menne az új gépekbe. Az tehát teljesen mindegy, hogy te mit gondolsz erről, se a piac, se az AMD, se az NVIDIA, de még az Intel sem ért veled egyet, mert ha egyetértenének, akkor nem olyan jellegű rendszerek készültek volna el, vagy készülnének a jövőben, mint az MI300A, GH200, stb.
-
Abu85
HÁZIGAZDA
Nem, ez teljesen valid megoldás. Semmiféle öszvér dolog nincs benne. Egyszerűen piaci igény az, hogy egyszerűen lehessen programozni. Hagyományos host CPU plusz nem memóriakoherens PCIe GPU dizájnt nem lehet, mert lassú a két lapka közötti összeköttetés.
Ha ez nem kellene a piacnak, akkor újabban nem a Cray EX255a és a Cray EX254n lenne a sláger. Hanem a régi megoldások, de ezek az új dizájnok HPC-ben kezdik a régi kialakítást teljesen kiszorítani.Ezért gond például, hogy az Intel a saját XPU koncepcióját erre törölte, és 2027-ig elő sem veszik.
-
Abu85
HÁZIGAZDA
Itt leginkább az számít, hogy a memóriát hogyan látják ezek a részegységek. Egy MI300A például látja a teljes memóriát a tokozáson. Az XCD és a CCD is. Nem véletlen, hogy a Cray EX255a akkorát tarolt a mostani top500-ban. A Grace Hopper Superchip nem ennyire szofisztikált, de annyira gyors a két lapka közötti összeköttetés, hogy sokkal kedvezőbben lehet alkalmazni bizonyos optimalizálásokat, mint hagyományos host CPU + dedikált GPU struktúrával. És itt a kulcs, hogy megteheted azt, hogy kihagyod az adatmásolással járó bonyolult kódot. De egyébként hosszabb távon az NV is arra fog menni, hogy egy tokozáson legyen ez ugyanolyan memóriatípussal. És akkor ott már nem sok különbség lesz a manuális másolós és a "csak úgy out of box működik" megközelítés között. Az MI300A-t konkrétan ez adja el, hogy csak úgy out of box is működik gyorsan.
#45788 lenox : És ezt jól látják az NV-nél. Egyrészt van az, hogy ha szarráoptimalizálod a sebességre, akkor jó az a megoldás, amit alkalmaznak, de a piac nem akar szarráoptimalizálni. Írni akarnak egy viszonylag egyszerű kódot, és inkább vesznek több hadvert, hogy jöjjön a sebesség. A Cray EX255a pont ezzel szakít nagyot a kasszáknál, hogy erre a ne is foglalkozzál vele szemléletre dolgozik. Lehetne jól csinálni más dizájnokkal? Hogyne lehetne, de a piacot inkább érdekli az egyszerűbb kód lehetősége. És erre egyébként a HPE tudatosan dolgozik a marketingben, az a selling point, hogy egyszerűbben programozható. Csinálhatnák azt is, hogy gyerekek akkora teljesítmény van benne, hogy pasztmek, de nem, arra épül a marketing, hogy egy csomó kódot meg sem kell írni, mert csak a hardver out of box elvégzi.
-
Abu85
HÁZIGAZDA
Ez koncepcionálisan hasonló elvű, mint például az Instinct MI300A. Csak nem annyira arányos, meg nincs egy tokozáson, de a működési elve hasonló.
Ha megnézed az új top500-at, akkor az újonnan telepített gépekben is ez a két dizájn most a kedvelt, nyilván nem véletlenül. Óriási haszna van a memóriakoherenciának. Az mindegy, hogy különálló fizikailag a memóriachip, az összeköttetés a lapkák között ezt a gondot megoldja.
-
Abu85
HÁZIGAZDA
Tipikusan már nem fognak akadozni, mert a mai textúra streaming rendszerek "intelligensek". A legújabbakat már eleve úgy tervezik, hogy ha elfogy a VRAM, akkor elkezdi kidobálni a textúrákat és automatikusan csökkentik a minőséget, hogy több VRAM maradjon. Tehát a VRAM egy jobb motorban ma már nem ott lesz korlát, hogy akadozik, hanem ott, hogy minőségvesztést okoz a grafikát tekintve.
Arról nem is beszélve, hogy manapság léteznek iszonyatosan jó memóriamenedzsment libek. VMA és D3D12MA. Ezekkel nagyon jól lehet játszani a VRAM terhelésével. Az a fura, hogy miért nem használja ezeket mindenki, mert van olyan módjuk, ami spórol a VRAM-mal, és úgy tényleg gigabájtokat lehet megspórolni.
-
Abu85
HÁZIGAZDA
Valószínűleg nem kellett ezt újratervezni az elejétől, mivel alapvetően a parancsmotor számít, tehát azt eleve tervezhették már korábban, és úgy döntöttek, hogy akkor előre hozzák az RDNA 4-be. De nyilván nem tudták már mindegyik GPU-ba beépíteni, így töröltek hármat, és terveztek két újat.
Valószínűleg nem volt olcsó. De azt mi nem láthatjuk, hogy mennyi UE5-ös cím érkezik, ami majd Work Graphs képességet használ.
-
Abu85
HÁZIGAZDA
Igazából nem egy Navi 4x lett törölve, hanem három. Amúgy már kint lenne a teljes sorozat. A gondot sem hardveres probléma okozta, hanem egy jóval korábban meghozott döntés a Microsoft részéről. Régóta levegőben lógott az, hogy az ExecuteIndirect nem elég jó, a Microsoft fülét rágta folyamatosan az Epic, hogy nekik így lassan működik például a Nanite, stb. Erre volt két megoldási javaslat, amit az NV és az AMD adott le. Aztán a Microsoft végül az AMD megoldását választotta, és azt szabványosították mára Work Graphs néven. Na most ezt a mostani legújabb GPU-k ugyan támogatják, de nem olyan jó hatékonysággal, mint elméletben kivitelezhető lehetne. Az AMD erre készült is egy erre formált hardverrel, aminél nem csak 30-40% között gyorsít a Work Graphs, és azért lett újratervezve az egész RDNA 4 generáció, hogy ezt a hardvert be tudják építeni. És elsődlegesen ez az Unreal Engine 5 miatt fontos, mert az Epicnek kritikus képesség a Work Graphs, ezzel tud igazán gyorsan futni a motor. Persze megmarad a fallback mód, ami most van, de az még ExecuteIndirect módszerrel dolgozik egy rakás trükköt bevetve, nem túl előnyös sebességű global atomics is van benne, ráadásul a procit is terheli. A Work Graphs módszer ezektől mentesül.
-
Abu85
HÁZIGAZDA
Nincs sok realitása az 500 dollárnak. Jelenleg a csúcs-Radeon kapcsán az AMD is inkább 999 dollárban gondolkodik. Ezek változhatnak, de jelenleg ezek a tervek. Valószínű azért nem 999 dollár az 5070 ára, hogy százzal az AMD megoldás alatt legyen, mert azt az NV is látja most, hogy -20 GB hátrányban lesznek.
-
Abu85
HÁZIGAZDA
Most így áll:
2499 - 1299 - 899De ez még változhat. Még tesztelik a piacot. De ez az aktuális tervezet.
És ha valaki sokat vár az RDNA 4 árától, akkor az se lesz igazán olcsó. Bár az tény, hogy 1000 dollár alatt lesz a teljes portfólió. De a perf/wattban nagyon nagy az előrelépés az új node miatt, és azt ki fogják fizettetni.
Itt igazából egyetlen probléma van az NV-nek, ha az 5070-et a top RDNA4-gyel eresztik össze: a 12 vs. 32 GB VRAM.
-
Abu85
HÁZIGAZDA
A február elejéhez az kell, hogy szeptemberben gyártsák. Ha a következő hónaptól kezdik gyártani, akkor az optimális esetben február vége, de inkább március.
Igen, csak idekeverted a VGA "marzsot" úgy, hogy az NV-nek ez nem is lényeges, mert a VGA-ik nagy többségét a partnereik gyártják. Az NV-nek a GPU-k lényegesek, de azok meg natúr GPU-k, se memória nincs rajtuk, se semmi VGA-specifikus komponens.
-
Abu85
HÁZIGAZDA
A 4090-4080-4070 is egyszerre lett bejelentve, mégsem egyszerre jelentek meg.
Kétlem, hogy csak a következő hónaptól fogják gyártani, mert akkor az azt jelenti, hogy csak februárban jöhetnek leghamarabb.
Az NVIDA nem is gyárt nagy mennyiségben VGA-t. A partnerei gyártanak ilyet. Az NV GPU-t gyártat nagy mennyiségben a TSMC-vel. A többi komponenst a partnerek veszik meg hozzá, hogy ebből VGA legyen.
-
Abu85
HÁZIGAZDA
válasz
Raymond #45281 üzenetére
Ő még sosem tévedett, igaz nem sokszor beszél.
#45282 paprobert : Most itt úgy beszélünk, mintha lenne más választásuk. Vagy megveszik a memóriát, vagy nem, és akkor nem adják ki a terméket.
#45283 b. : Azt azért kétlem, hogy az 5070 megjelenésére is ennyire drága lesz a GDDR7. Azért a GDDR6X-re is jellemző volt, hogy kb. két hónap alatt esett az ára 40%-ot az első bevetésekor. Ugyanez esélyes a GDDR7 esetében is.
-
Abu85
HÁZIGAZDA
válasz
paprobert #45279 üzenetére
Persze, hogy olcsóbb a GDDR6 és a szélesebb memóriabusz. De itt nem az a lényeg, hogy most olcsóbb-e, hanem olcsóbb lesz-e mondjuk egy év múlva. Mivel az aktuális generáció ismét két-két és fél évre készül, figyelembe kell venni azt, hogy az életciklus során hogyan alakulnak majd az árak, és a kezdeti egy-két hónap ára ugyan hihetetlenül magas lehet, ugyanazzal a problémával, mind a GDDR6X-nél, de arra számítanak, hogy fél év múlva azért már nagyobb lesz a GDDR7-re az igény, így a memóriagyártók elkezdenek túltermelésbe futni. Aztán gyorsan összeesik majd az ár, ha ez megtörténik.
A köztes generáció így jó fejlesztési alap is lehet, hiszen jöhetnek új GDDR7 memóriák, amikkel növelhető 2025 végén a VRAM. Ez különösen hasznos az NV-nek is, hiszen jövőre rá tudják kényszeríteni a most vásárló réteget arra, hogy frissítsenek a Super verziókra.
Mellesleg szó sincs jelenleg 1000 dollárról. Jóval több lesz az ár. Ezen túlmenően a 4 nm-es node egy relatíve olcsó opciónak számít ma már. Azért nem váltottak 3 nm-re, mert az túl drága.
-
Abu85
HÁZIGAZDA
Lesznek több VRAM-mal rendelkező GeForce-ok, de csak a GDDR6 verziók. A GDDR7 így is extrém drága, nem tudnak több memóriát rakni rá, mert dupla annyi memóriachipet kellene alkalmazni. Már 16 GB-nyi GDDR7-et is 400 dollárért mérnek a memóriagyártók. Ebből 32 GB-ot 800 dollárért adnak. Ez lesz egyébként a legdrágább komponens az új NV VGA-kon, teljes kapacitáson drágább, mint a GPU maga.
Egyébként ezt az NV is gondnak látja, de mit tehetnek, a memóriát ki kell fizetni.
-
Abu85
HÁZIGAZDA
válasz
Hellwhatever #44930 üzenetére
Ne törődj vele. A 850 watt sem volt pontos ajánlás.
-
Abu85
HÁZIGAZDA
válasz
deathcrow42 #44924 üzenetére
A "Minimum recommended PSU" 1200 watt lesz. De ez nem sokkal több, mint a 850 watt, ami a 4090-hez van írva hivatalosan ilyen ajánlásként. Meg ugye ezek az ajánlások nem igazán pontosak.
Új hozzászólás Aktív témák
Hirdetés
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 NVIDIA é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.
- Villanyszerelés
- Kínai és egyéb olcsó órák topikja
- Autós topik látogatók beszélgetős, offolós topikja
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- OLED monitor topik
- Magga: PLEX: multimédia az egész lakásban
- Nyaralás topik
- C# programozás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- További aktív témák...
- Csere- Beszámítás! Asus Rog Strix B550-F Gaming Wi-Fi II Alaplap
- Lenovo ThinkPad X13 G2 multitouch
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Acer Predator Helios 300 Gamer notebook - i7 10750H 16GB DDR4 1TB SSD RTX 2060 6GB WIN10
- Bomba ár! Dell Latitude E7440 - i5-4GEN I 8GB I 500GB I 14" HD I HDMI I Cam I W10 I Gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest