Hirdetés
- Külföldi prepaid SIM-ek itthon
- EarFun Air Pro 4+ – érdemi plusz
- A vártnál korábban érkezhet a Xiaomi 17 Ultra
- Apple iPhone 16 Pro - rutinvizsga
- iPhone topik
- Szívós, szép és kitartó az új OnePlus óra
- Hivatalos a OnePlus 13 startdátuma
- Okosóra és okoskiegészítő topik
- Samsung Galaxy S25 - végre van kicsi!
- Milyen okostelefont vegyek?
-
Mobilarena
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
-
#52581
Abu85
HÁZIGAZDA
deathcrow42
#52580
Abu85
HÁZIGAZDA
válasz
deathcrow42
#52580
üzenetére
Nagyon sokan, hiszen itt is többen beszéltek arról, hogy mindjárt itt a Super.
Műhelytitok, hogy kaptam is leveleket, hogy miért nem írom meg, meg hogy az emberek pénzt költenek miattam, hogy nem szólok nekik, hogy szeptemberben új generáció jön. 
Tehát effektíve sikerült engem is belerángatni, hogy faszé nem írok hazugságot. 
-
Abu85
HÁZIGAZDA
válasz
S_x96x_S
#52578
üzenetére
Mely board partnerek? Amióta megjelentek a pletykák erről a Super sorozatról, azóta beszélek velük. Egyik sem tudott róla semmit. Emiatt kételkedtem az őszi megjelenésben, mert nyáron már csak tudniuk kellene, hogy mit adnak ki egy hónap múlva.
És ezt nem most kezdtem el mondani, régóta közlöm, hogy semmi valóságalapja nincs ennek az őszi frissítésnek, mert nem tud róla senki semmit. Szóval már vártam a hírt, hogy mikor lesz megmagyarázva, hogy mégsem jön ősszel. És természetesen úgy lett tálalva, hogy itt bizony csúszik a dolog, mert ugye olyan nehéz nem módosítani a GPU-n, a NYÁK-on, a memórián, stb. Ez az NVIDIA-nak megugorhatatlan feladat úgy, hogy minden komponens a birtokukban van most is. Ha józan paraszti ésszel összerakja az olvasó, akkor már szirénáznia kellene a fejében a hülyeségdetektornak, mert meglévő komponensek összelegózásáról van szó. És az eredeti őszi megjelenés pletykáját vizsgálva ezt nem volt képes megugrani az NVIDIA. Mekkora marhaság már. Nem lehet, hogy csak kattintásokért kitalálták ezt a Super szériát, hogy majd egymásra hivatkozva megírják ide-oda, hogy biztos lesz, aztán nem is készült őszre?
![;]](//cdn.rios.hu/dl/s/v1.gif)
De amúgy egyik VGA-gyártó sem mondta, hogy nem jön, csak azt, hogy erről még egy hangyafingnyi adatot sem hallottak az NVIDIA-tól. Persze lehet, hogy az NVIDIA most dobja ki a board partnereket, és akkor csak maguk megoldják a gyártást. De vannak erről kétségeim. Szóval, ha jön valami, szólnának a partnereiknek.
-
#52576
Abu85
HÁZIGAZDA
ScomComputer
#52573
Abu85
HÁZIGAZDA
válasz
ScomComputer
#52573
üzenetére
Várjunk, akkor most mégse ősszel jön, ahogy mondták a nyáron? Jó lenne tudni, mert a gyártók még mindig nem tudnak ezekről a termékekről semmit.
Bónusz kérdés, ha az őszi jóslat nem jött be, akkor miért kellene elhinni a télit? De hála az égnek még mindig lehet védekezni azzal, hogy ha ősszel nem jön, akkor majd jön a CES-en. Véletlenül se írjuk le, hogy erről az egészről a Twitter bejegyzéseken kívül egy VGA-gyártó sem hallott. Biztos, hogy sok fejlesztés van vele, hiszen nem kell új NYÁK-ot csinálni, nem kell új GPU-t csinálni, nem kell új memóriát csinálni... remélem az emberek elhiszik az új jóslatot, és nem teszik fel azt a kérdést, hogy esetleg sosem készült semmi őszre.
-
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?
-
-
#50987
Abu85
HÁZIGAZDA
huskydog17
#50984
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.
-
#50980
Abu85
HÁZIGAZDA
huskydog17
#50959
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.
-
#50545
Abu85
HÁZIGAZDA
gainwardgs
#50544
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.
-
#50543
Abu85
HÁZIGAZDA
gainwardgs
#50540
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.
-
#50391
Abu85
HÁZIGAZDA
BerserkGuts
#50390
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.
-
#50389
Abu85
HÁZIGAZDA
Komplikato
#50387
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.
-
#49966
Abu85
HÁZIGAZDA
-=RelakS=-
#49965
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.
-
#49964
Abu85
HÁZIGAZDA
-=RelakS=-
#49963
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!
-
#49962
Abu85
HÁZIGAZDA
-=RelakS=-
#49960
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.
-
#48215
Abu85
HÁZIGAZDA
BerserkGuts
#48209
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
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.
-
#47847
Abu85
HÁZIGAZDA
Quadgame94
#47844
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.
-
#44934
Abu85
HÁZIGAZDA
Hellwhatever
#44930
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#44930
üzenetére
Ne törődj vele. A 850 watt sem volt pontos ajánlás.
-
#44929
Abu85
HÁZIGAZDA
deathcrow42
#44924
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.
-
Abu85
HÁZIGAZDA
válasz
Teasüti
#44844
üzenetére
A Snowdrop 2 DXR 1.1-et használ metszésvizsgálatra, de szoftveres compute shadert bejárásra. Emiatt olyan nagyon gyors rajta az RT, hogy ki se kell kapcsolni. Ettől még hardveres a rendszer, csak azt a részegységet nem használja, amitől a DXR jellemzően nagyon lassú. A DXR-nek a hasznos és gyorsan futó részeit használják.
Az SWO annyiban más, hogy abban van egy külön effekt, ami nem szoftveres bejárást használ, viszont az teljesen különálló gyorsítóstruktúrát generál, mert nem kompatibilis a többi effekt a DXR gyorsítóstruktúrájával. Ez azért van, mert az RTXDI zárt effekt, annak nincs meg a forráskódja az Ubisoftnak, így nem tudják begyorsítani a saját módszerükkel. És ezt ki is lehet próbálni, hogy RTXDI-ra erősen esik a sebesség, mert rá vannak kényszerítve a DXR lassan működő részére. A többi, saját effektnél nincsenek, így azokat nagyon-nagyon gyorsan tudják futtatni.
-
Abu85
HÁZIGAZDA
Mert ez a helyzet sajnos. Látványos, hogy mennyivel jobban működnek ezek a dolgok a Snowdrop 2-ben, hiszen egy rakás olyan dologra használják az RT-t, amivel más meg se próbálkozik, és mindezt kikapcsolhatatlanul, tehát teljesítményben is messze rávernek a DXR-re. Becsukhatjuk a szemünket, de ugyanúgy, ahogy anno a T&L-nél akadály volt a programozhatóság hiánya, úgy itt is az.
Közben megkerestem, hogy az Ubi milyen algoritmusokat implementált a Snowdrop 2-be, amiket DXR-ben nem tudtak megtenni, a programozhatóság hiánya miatt: on the fly BVH generation, flexible LOD, early traversal stop. Ezek miatt olyan veszettül gyors a gyári és kikapcsolhatatlan RT implementációjuk.
-
Abu85
HÁZIGAZDA
válasz
Teasüti
#44818
üzenetére
Igazából a gond az, hogy a hardverhez igazodik az API, és az nem jelent túl jó programozhatóságot. Enélkül meg megette a fene, egy csomó dolog megvalósíthatatlan.
A dolog sokban hasonlít a T&L-re. Ott is jó volt az újítás, de annyira limitált volt a programozhatóság hiánya, hogy gyorsan ment is a T&L, ki is került a fixfunkciós hardver a GPU-kból a következő körben. Nagyjából ugyanez lesz most is, a programozhatósággal a fixfunkciós hardver egy része megy, mert nem hasznos.
-
Abu85
HÁZIGAZDA
Sajnos ez nem ennyire egyszerű. Ha ilyen egyszerű lenne, akkor több játék/motor is csinálna ilyet, de valójában azért csak a Snowdrop 2 hozakodott elő hasonlóval, ráadásul egész jó minőségben, mert egyedi BVH gyorsítóstruktúrát használnak, nem azt, amit a DXR előír.
Az Avatar és a SWO között annyi a különbség, hogy utóbbi két gyorsítóstruktúrát is generál. Egy egyedit, és egy DXR-hez valót egyetlen effekthez. De az általános RT-hez és a hangokhoz is az egyedi adatstruktúrát használja a játék, és ennek jó oka van, DXR-rel nem igazán valósítható meg az, amit hallasz a videóban. Ez a DXR API masszív limitációiból ered. És egyébként az SWO azért zabál annyi VRAM-ot, mert a max. részletesség ugyanarra a problémára kétszer helyez el gyorsítóstruktúrát a VRAM-ban. Ez ugye marhára pazarló dolog, de jelenleg annyira körülményes, rosszul felépített és limitált az RT PC-n, hogy nincs más lehetőség. Kis túlzással ez még mindig egy nulladik generációs, kísérleti jellegű valaminek tűnik.
-
Abu85
HÁZIGAZDA
Igen, csak a Snowdrop 2-ben nagyon sok új dologra adott lehetőséget, hogy el tudták hagyni a DXR-nek azt a nagyon korlátozó részét, ami miatt ma egy csomó játék ilyeneket nem is csinál. Ha mindenki sorban rakná át compute shaderre a bejárást a fixfunkciós hardverről, akkor máshol is lehetne ilyet csinálni. De egyelőre a legtöbb játék a fixfunkciós, beépített hardvereket használja bejárásra a DXR API-n keresztül. Emiatt a Snowdrop 2 egyedi, mert az Ubisoft hajlandó volt kikerülni az API-nak a problémás részét, ami azokat a limitációkat hordozza, ami miatt nincsenek ilyen újítások. Vagy alternatív megoldásként szabványosítani kell a régóta parlagon heverő traversal shadert. A Snowdrop 2 is ezt csinálja csak compute shaderrel.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#44772
üzenetére
Mert az új drivermodulok nem mindig kompatibilisek visszafelé. De erre az NV mindig figyelmezteti a fejlesztőket. A nagyon régi GPU-s PhysX játékok instabilak lehetnek az új driverekkel.
#44773 Teasüti : Akkor érdemes nekikezdened, mert nem tudni, hogy melyik modul meddig fogja stabilan futtatni a régi kódokat.
-
Abu85
HÁZIGAZDA
válasz
Teasüti
#44769
üzenetére
Nincs. Meg nem is ez a PhysX 4-5 fő célterülete, hanem azok az egyedi igények, amik az ipar 4.0-ból erednek.
Ezt amúgy jól látta az NVIDIA. Azért ők sem voltak vakok abból a szempontból, hogy a compute shader átveszi majd az uralmat a GPU-s fizikai effekteknél. Tehát akármit is kínálnak később, az versenyképtelen lesz az egyedi megoldásokkal szemben. Szóval elvitték arra a PhysX-et, ahova még el lehet adni. A másik lehetőség a beszántás volt, gondolom azt még nem akarták meglépni. De az nyilvánvaló volt számukra viszonylag gyorsan, hogy a gaming szintjén a GPU-s PhysX-nek leáldozott, és léptek is, hogy akkor majd kezdenek a technikával valami mást.
Nyilván valamilyen szinten kötöttek kompromisszumokat is, például régebbi PhysX modulokat kivettek a meghajtóból, ami miatt a nagyon régi verziót használó játékok már instabilak is. Erre alig reagáltak a fejlesztők, de például a Warframe reagált rá azzal, hogy lecserélték a GPU-s PhysX-et. A legtöbb játék viszont egyjátékos volt, a játékosbázis rég lecsökkent arra a szintre, hogy ezt nem érdemes tovább karbantartani, majd a user kikapcsolja, ha fagy a program. Viszont erről mindig kaptak tájékoztatást a fejlesztők, hogy mi változott, és mi nem fog a jövőben stabilan működni, csak nincs hajlandóság ezekhez igazodni. Egyszerűen túl drága több éve megjelent játékokat egy maréknyi userért karbantartani. A Warframe annyiban lehetet más, hogy az multi volt, és ott azért még megvolt a játékosbázis.
Egyébként itt jó hír, hogy a 3.4-es verzióval a fejlesztők is szállíthatnak a játékban modult a hardverekhez. És ezt azért intézte így az NV, hogy ha majd végleg kiveszik a GPU-s PhysX supportot a driverből, akkor a fejlesztők fel tudják frissíteni a modult a régi játékokban 3.4-re, és egy patch-csel szállíthatnak saját binárist. Na most persze az megint kérdés, hogy ezt hányan fogják megtenni, de az NV mondhatja azt, hogy mossa kezeit, mert ők megadták erre a lehetőséget. Ez a bináris addig működni fog, amíg a futtatását meg tudja oldani az új architektúra. Ha viszont ez sokat változik, akkor ennek is lőttek.Egyébként, ha valakit érdekel, akkor az NV szerint a 373.06-os driver a váltópont. Ha nagyon régi a GPU-s PhysX játék, és instabil az új driverekkel, akkor vissza kell rakni egy 373.06 előtti meghajtót, és azzal stabil marad. A 373.06-től a játékot kell frissíteni, ha nagyon régi a PhysX modulja. Nyilván ez az új hardvereknél nem megoldható, és ebből kitalálható, hogy az NVIDIA miért nem említi többet a GPU-s PhysX-et.
-
#44766
Abu85
HÁZIGAZDA
huskydog17
#44764
Abu85
HÁZIGAZDA
válasz
huskydog17
#44764
üzenetére
Akkor pontokba szedve:
A lista azért fontos, mert te azt hiszed, hogy minden PhysX játék GPU-val gyorsít. Nem, ahhoz külön kód kell, és a listában szereplő játékok támogatják azt a kódot. Tehát ott van az a pár cím, amiben működik ez, minden más címben hasztalan a GPU-d PhysX-re, mert a CPU-n fut a kód mindenképpen.
Az NV-től régen kérdeztem, hogy egy ideje már nincs GPU-s PhysX, és hogy ez halott-e vagy valami. Nekem azt írták, hogy most az RTX-re megy a pénz, a GPU-s PhysX-et a 4-es verziótól kezdve átalakították professzionális szintre. Ez abban nyilvánul meg az NV szerint, hogy maga a szimuláció sokkal pontosabb, így ipari szintű modellezéshez is használható, viszont a pontosságnak az az ára, hogy 10-20x nagyobb az erőforrásigény. Tehát a PhysX 4-5 már nem optimális játékra, mert valójában a játékokban nincs szükség arra, hogy hihetetlenül pontos legyen a fizika modellezése. Kismértékű változást jelentene csak a kinézetet tekintve, miközben a számítások oldalán 3-4 VGA-ra van szükség hozzá. Nos, röviden ezért nincs GPU-s PhysX játék manapság.
A 3.4-es verzió megmaradt a régi, pontatlanabb fizikánál, azt begyorsították.
A Unity gyárilag négy fizikai motort támogat: PhysX, Havok, Unity Physics és Box2D. A PhysX verziója gyári szintű támogatás mellett valóban 4.1, de nem engedélyez GPU-s gyorsítást, pont amiatt, amiért az NV nem erőlteti ezt manapság. A 4.1-re azért tértek át, mert kedvezőbb a CPU-s kód sebessége az AVX optimalizációknak hála. A PhysX 5-öt viszont már nem is implementálták még kísérleti szinten sem, mert ott már a CPU-s kód is nagyon más, sokkal-sokkal több magot igényel a pontosság miatt. Ez ipari szinten, ahova fejlesztették oké, mert oda nem nehéz 64-magos Threadrippereket venni, de a gémereknek erre nincs pénzük. És az is számíthat, hogy a Unity inkább a Unity Physics fejlesztésére koncentrál, hiszen az gyári megoldás, és ez azért lényeges számukra, mert nem lesznek szopatva az olyan jellegű piacváltástól, amit a PhysX-szel csinált az NV. Ugyanígy az Unreal Engine is ezért fejleszti a saját megoldását, mert a PhysX irányával gaming szinten nem tudnak mit kezdeni.
GPU-s PhysX-re a 3.4 az utolsó, ami játékra is alkalmas, mert az még nem ipari szintű pontosságra van kialakítva. CPU-ból még elmegy a 4-es. Az 5-ös semmiképpen, mert az minden szempontból robotika szimulációra van írva. Az nagyon jó ipari szinten 4-8 GPU-s Threadripper rendszereken, de a gaming nem tud vele mit kezdeni, mert nincs meg a pontosság által megkövetelt teljesítmény egyetlen GPU-ban. Úgy meg pláne nincs, hogy a GPU közben egy rakás más dolgot csinál.
Azokat a részfeladatokat, amiket lehet gyorsítani GPU-val már rég alkalmazzák a játékok compute shaderben. Tehát különösebb haszna ezért sincs a GPU-s PhysX-nek már, mert az adott effektre írnak egy compute shadert és kész, fut mindenen.
Igen, a binárisokat odaadják ingyen, és ennek pont az a hátránya, hogy ha nem működik, és az esetek többségében nem fog, mert nem tud az NV minden egyes specifikus tényezőhöz alkalmazkodni, akkor mehetsz a supporthoz, hogy írják át neked a kódot, és fordítsanak neked olyan binárist, ami működik. Ezt megcsinálják, de erre licencszerződést kell kötni, mert az NV support nem fogja neked ingyen működővé tenni a kódot. Hülyék lennének, ha pénzt is adnak ezért az emberek.
-
Abu85
HÁZIGAZDA
válasz
Teasüti
#44761
üzenetére
Semelyik motor nem használja azt a modult alapértelmezetten, mert licencköteles. Csak CPU-s PhysX-et használnak a motorok alapból, mert az viszont ingyenes.
Ha amúgy sokan használnák, akkor az NV-nek is megérné karbantartani, de az utolsó játék, ami használja sok-sok évvel korábban jött ki. Így egyszerűen a modul karbantartása a driverben csak egy masszív pénznyelő, mert nincs mi használja. Ezeknek mindig ugyanaz a sorsuk, idővel kikerülnek, mert felesleges erőforrást ülni bele, ha a játékok nem nyúlnak hozzá. A kérdés a mikor, de valószínűleg pár éven belül ki lesz műtve. Valószínűleg azt várják, hogy kifusson az utolsó GeForce sorozat, amivel ezt még hivatalosan reklámozták, ami a Maxwell generáció volt. Az Ampere tulajok már nem reklamálhatnak, mert az NV vissza tudja mondani, hogy sosem ígértek nekik sehol sem GPU-s PhysX-et. Maximum működött, de ígéretként sehol sem volt kiemelve. És ezzel az NV bevédi magát a perektől, ha lennének.
-
#44760
Abu85
HÁZIGAZDA
huskydog17
#44745
Abu85
HÁZIGAZDA
válasz
huskydog17
#44745
üzenetére
Ezek a játékok használnak GPU-val gyorsított PhysX-et:
Active Worlds / Alice: Madness Returns / Assassin's Creed IV: Black Flag / Batman: Arkham Asylum / Batman: Arkham City / Batman: Arkham Origins / Batman: Arkham Knight / Borderlands: The Pre-Sequel / Borderlands 2 / Bureau: XCOM Declassified / Call of Duty: Ghosts / Crazy Machines II / Cryostasis / Dark Void / Darkest of Days / Daylight / Fallout 4 / Hawken / Hot Dance Party / Hot Dance Party II / Killing Floor 2 / Lords of the Fallen / Mafia 2 / Metro 2033 / Metro 2033 Redux / Metro: Last Light / Metro: Last Light Redux / Mirror's Edge / Passion Leads Army / Rise of the Triad / Sacred 2: Fallen Angel / Sacred 2: Ice & Blood / Star Trek: D-A-C / Tom Clancy's Ghost Recon Advanced Warfighter 2 / Unreal Tournament 3 / Warface / Warmonger - Operation: Downtown Destruction
Még használt eredetileg a Warframe és a Planetside 2 is. A Warframe lecserélte egy sajátra, míg a Planetside 2 esetében licencproblémák voltak, és a Sony inkább kivette, hogy ne kelljen az NV-nek fizetnie.
Leginkább azért nem használnak ma már GPU-s PhysX-et, mert valójában sosem fizikáról volt szó, hanem grafikáról, és a compute shader kiváltotta ezt. Persze az sem segít, hogy az NV a rendszert nem fejleszti már a játékok szemszögéből. A 3.4-es volt az utolsó verzió, ami játékhoz készült. A 4-5 már nem igazán. A PhysX játékokhoz tervezett verziója 2018 óta gyakorlatilag vegetál. Nem tudni, hogy az NVIDIA valaha is újraindítja-e. Abból kiindulva, hogy már arra is figyelmeztették a fejlesztőket, hogy a PhysX runtime kikerülhet a GeForce driverből, így a GPU-s PhysX effektek a játékokban elszürkülnek majd, arra lehet következtetni, hogy nem jön vissza ez az irány. A karbantartási költségektől pedig 6-7 év vegetálás után valószínűleg megszabadulna a cég.
Valós fizika gyorsításra dedikált hardverből nehéz, mert sok a round trip. Ezért használnak erre a célra csak CPU-t. Azért sem túl célszerű már a dedikált hardver, mert annyi mag van a CPU-kban, mint a dinnyében, szóval skálázni elég jól lehet már.
-
Abu85
HÁZIGAZDA
A Star Wars Outlaws motorja igazából jó. Az Avatar: Frontiers of Pandorához viszonyítva annyi a különbség, hogy nem ugyanazt a memóriamenedzsmentet használja. De maga a motor támogatja az Avatar-féle menedzsmentet is, csak nem aktív a Star Warsban. Ezért tűnik sokkal-sokkal rosszabbnak. Konkrétan a defragmentáció, ami hiányzik, amivel az Avatar nyert bő mínusz 4-5 GB-ot max. részletességen a VRAM terhelést tekintve. De a defragmentáció nem ingyenes, tehát a sebességet tekintve annak költsége van, és a Star Wars esetében úgy dönthettek, hogy inkább azt a plusz 3-5 fps-t választják, annak árán is, hogy a VRAM terhelés 4-5 GB-tal több lesz.
-
Abu85
HÁZIGAZDA
Ja persze... de ez koncepció, fícsőr... igyekszik a rendszer a textúrarészletességet a VRAM-hoz igazítani, hogy ne fusson ki belőle. Aki nem szeretné, hogy a játék on-the-fly butítsa a textúrákat, vegyen 16-24 GB-os VGA-t.
Az a helyzet, hogy az se jobb módszer, ha a részletesség low-med-high skálán manuálisan konfigurálható. Ha 8-12 GB VRAM-od van, mindenképpen kompromisszumot kötsz, és nem biztos, hogy jobb kompromisszum az, hogy minden medium legyen, mint az, hogy a játék majd eldönti, hogy a high mellett melyik textúra lesz medium vagy low részletességű.
-
Abu85
HÁZIGAZDA
A VRAM az egy specifikus téma. Nyilván lehet olyan tartalommal elárasztani a játékot, vagy olyan RT eljárásokat írni, ami lezabál 12-16 GB VRAM-ot is. De ez nagyrészt döntés kérdése. Mellesleg ez a probléma elég egyszerűen kezelhető a textúrarészletesség csökkentésével.
#44655 D55 : Az csak szimplán egy parancslistás gond. Itt sokkal mélyebbek a kihasználtsági lyukak a hardverben. A legtöbb profilozó nem is mutatja, hogy vannak.
#44657 gV : Itt profilozót kellene ráereszteni, és ott lenne látható. De egyedül az RGP alkalmaz olyan módszert, ami jól kimutatja ezeket a kihasználtsági limiteket. Az RGP meg nem fut GeForce-on.
-
Abu85
HÁZIGAZDA
Nem a hardver miatt lassú, hanem a DXR miatt. Ezt hardverrel nem oldod meg, mert a limitáció az API-ban keletkezik. A hardver nagyrészt malmozik, mert nem lehet jól optimalizálni rá a bejárást. Egyszerűen látják a fejlesztők, hogy nem fut jól, de mivel zárt a specifikáció, így nem tudják, hogy hol keletkezik a limit. Nem látják. Következésképpen javítani sem tudják.
Látványos egyébként az új Star Warsban, hogy amelyik RT effekt compute shader bejárással van megoldva, az nagyon-nagyon gyors. Egyedül az a nagyon lassú, ami fixfunkciós bejárást használ, vagyis hozzányúl a hardveres részegységhez, és nem az ALU-kon fut ez a részfeladat. És logikus lenne azt várni, hogy az extra hardverelem miatt majd gyorsabb lesz, de pont az extra hardverelem miatt nem látják, hogy hol vannak a kódban a limitek, és ha azt nem látják, akkor nem tudják hol kell optimalizálni, hogy gyorsabban fusson. De ahol ezt meg tudják tenni, lásd a compute shader bejárást a többi RT effekten, ott nagyon is gyors a működés, mert nem feketedoboz-szerű a kód. Látják, hogy hol a limit, látják mit kell javítani, és javítják is.
Ezért írom egy ideje, hogy hiába várjátok az új hardvereket, a limitek a kódban vannak, a feketedoboz jellegű működésbe rejtve. Azt gyorsabb hardver nem oldja meg.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#44640
üzenetére
Igazából nagyon sok data center CPU létezik az AMD és az Intel mellett, szóval sosem volt egyedül az Intel. A gond az, hogy ha nem Intel CPU-t néznek, akkor AMD-t, mert arra nem kell átírni a szoftvereket. Tehát hiába van a fél tucat ARM alternatíva, egyelőre nem érdekes a piac nagy részének. Azok az ARM alternatívák terjednek, amelyek saját tervezésűek. Lásd Amazon, de ők ugye érdekeltek abban, hogy a saját hardverjeiket használják. És ezzel kifújt a dolog, mert ha nem saját hardver az ARM dizájn, akkor más cég nem igazán érdekelt az ARM-ban.
Egyébként, ha nem lenne EPYC, akkor simán érdekes lenne, mert azért számít, hogy 3-4 watt/maggal dolgozik az ARM, míg a Xeon inkább 7-8 watt/maggal. Viszont az AMD meg szintén 4 watt/mag körül ad egy rakás szálat, és így már nem érdekes az ARM, mert kb. 0,5-1 watt/mag előnyért nem fognak átírni egy rakás szoftvert. És akkor a Zen 5c 2-3 watt közötti működéséről nem is volt szó, amivel az AMD az ARM alá megy x86/AMD64-gyel. Nem igazán néz ki úgy, hogy az ARM a szerverpiacon nagy áttörést érhet el a közeljövőben, ha data center feladatokról van szó. HPC más téma, ott azért lehet keresnivalója. A Grace is inkább erre ment, és nem a data center felé. És valószínűleg a Grace utódja sem fog ezen változtatni, mert túl erős a Turin dense kiadása. Még akkor is nehéz lenne ellene versenyezni, ha jobb watt/mag mutatót hoznának, de az új Zen 5c az ARM magok alá megy itt. Emiatt az NV a data center CPU-piacra nem is igazán lő.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#43265
üzenetére
Ezt is kalapálni fogják egy évig. Az AMD is kalapálta eddig. Ez általános egy új felületnél, hogy eleinte sok a bug.
#43266 b. : Biztos nem marad meg minden. Itt egy felület lesz, mert akkor fókuszálható annak a karbantartása.
A bug azért volt az Intelnél, mert új volt a felület. Itt is lesz legalább egy év, mire összerakják kb. bugmentesre. Az AMD felületén is voltak bugok az elején. Manapság azért nincsenek, mert arányaiban azt a felületet fejlesztik a legrégebben a modern opciók közül. De az elején ugyanúgy bugos volt. -
Abu85
HÁZIGAZDA
Látványos a különbség a sebességben a többi vezérlőpulthoz viszonyítva. De ez normális, nagyjából tizenakárhány éve csak reszelik a kódot, miközben a többiek már újraírták. Kicsit olyan az egész, mintha az NV vezérlőpultja tíz éves gépen nyílna meg... nem jó az a felület már, agyonrétegelt őskövület, ami programszinten is rossz sebességű. Nem véletlenül cserélik le.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#43259
üzenetére
Ez azért objektív. Ma az tekinthető modern felületnek, ami egyszerre kezelhető hatékonyan minden beviteli lehetőségről, és eközben kellően reszponzív a kapott élmény. Az NV vezérlőpultja egyiket sem teljesíti, mert rém lassú az egész, és eközben nagyon rosszul kezelhető érintőkijelzőről. Az AMD és az Intel vezérlőpultja mindkettő követelményt teljesíti, mert egyrészt nagyon gyorsak, ami leginkább abból ered, hogy nem évtizedes kódra épülnek, másrészt kellően átgondolt az UI ahhoz, hogy érintőkijelzőről is pont eltaláld, amit változtatni akarsz.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#42982
üzenetére
Egyáltalán nem az a kérdés. Jelezni kell, hogy mekkora a minta. Ennyire egyszerű. Minden statisztikában ott van a megkérdezettek száma.
Mindig leírod, hogy a másik nem tudja, hogy miről beszél, de sose cáfolod meg. Ez a lenézés definíciója.
#42983 Busterftw : Már önmagában akkor nem beszélhetünk reprezentatív statisztikáról, ha fittyet hány a statisztikai módszertanra.
-
Abu85
HÁZIGAZDA
Nem a minta száma határozza meg a tudományosságot, hanem a módszertan. Ha követi a felmérés a tudományos módszertant, akkor egy kis mintás statisztika is lehet reprezentatív. Ezért tudják eltalálni a cégek pár ezer fő megkérdezésével egy sokmilliós bázis véleményét.
Ha bárki elmegy statisztikát tanulni az egyetemre, akkor azt fogják neki tanítani, hogy a nagy minta a megfelelő módszertan alkalmazása nélkül jobban torzít, mint a kis minta a megfelelő módszertannal.
-
Abu85
HÁZIGAZDA
Ha csak hibák lennének benne, akkor oké, de orbitális hibák vannak benne. Ettől függetlenül lehet róla beszélgetni, csak ne tekintsük reprezentatívnak. Kb. azon a szinten van, mint az MF eredmények.
Nyilván a legnagyobb bajom ezzel, hogy az MF és a Steam Survey lassan felülreprezentálja a médiában a valós statisztikát. Ezért lenne fontos megfelelően kezelni mindkettőt, mert akkor nem kezd el gondolkodni azon a user, hogy jaj, de eltérőek a statisztikák. Persze, hogy azok, ha nem reprezentatívak.
De ha már eleve úgy nézel rá, hogy ez nem reprezentatív, akkor le is tudtad, hogy ezért tér el nagyon y és x statisztika, nem kezded az egyiket felemelni, míg a másikat lehúzni a személyes nézőpont szerint. Ne mondjuk már, hogy nem ez lenne a normális... -
Abu85
HÁZIGAZDA
válasz
Raymond
#42971
üzenetére
Akkora minta kell, amekkora a minta. Csak jelezni kellene.
Akkor a reprezentatív statisztikák miért jelzik a mintavételi torzítást? Most vagy az egyetemen tanítják rosszul, vagy valaki hazudni akar...
Emlékszem volt egy statisztika, amiből kivettek egyszer sokszázezer kínai gépet, mert annyira sokszor szerepeltek, hogy már-már nevetségesen extrémen torzították a statisztikát. Melyik is volt az? Várjál... á igen, a Steam Survey...
Mintavételi torzításra vonatkozó adat nélkül, hogyan lehet megállapítani a hibahatárt? Ezt konkrétan kérlek vezesd le matematikai alapon. Ne úgy, hogy szerinted nem kell megállapítani a hibahatárt, mert csak. Azt már ismerjük, hogy ezek a szabályok szerinted nem fontosak, kidobott állami milliárdok, amikor ezeket oktatják. Csak matematikailag mutasd be kérlek, hogy nélkülük hogyan lehet hibahatárt számolni.
#42972 Raymond : Az MF sem reprezentatív. Pont annyira torzít, mint a Steam Survey. Én viszont arra reagáltam, hogy lenézted a fórumtagod. Nem muszáj komolyan venned, amit ír, de annyira süt az írásodból, hogy mindenkit lenézel, még magát a statisztikát, mint tudományágat is, hogy azt nagyon nehéz hova tenni. Hiányzik a teljes tisztelet azok felé az egyetemi oktatók felé, akik olyan dolgokat adnak át naponta az egyetemeken, amiket te a Steam Survey esetében egyáltalán nem tartasz lényegesnek. Akkor minek oktatják? Ez a statisztika tudományának lenézése.
-
Abu85
HÁZIGAZDA
A Steam Survey konkrétan nem reprezentatív. Ennek ez a tudományosan elfogadott jelzője. És abban, hogy nem reprezentatív minden benne van, aminek benne kell lennie, vagyis jelezve van az olvasó felé, hogy amit olvas az lehet, hogy máshogy van a valóságban, de az alkalmazott mérési módszerekkel ezt tudják összehozni.
Én nem akarok meggyőzni senkit, csak azt akarom tudatni, hogy van reprezentatív felmérés és nem reprezentatív. Tehát reprezentatívként senki se reflektáljon a Steam Survey-re, mert csúfot űzünk a statisztikából, mint tudományágból.
És az főleg nem emel reprezentatívvá egy nem reprezentatív felmérést, hogy nem találsz másikat. -
Abu85
HÁZIGAZDA
válasz
Busterftw
#42962
üzenetére
De konkrétan azt jelenti, hogy nem felel meg a szabályoknak. Azért van az a szabály, hogy ezeket jelezzék, hogy ki lehessen számolni, hogy mennyit téved. Ha nem jelzed, akkor a tévedés kiszámíthatatlan, vagyis nem reprezentatív az egész statisztika.
Ezeket ezért tanítják így az egyetemen. Kb. olyan dolog ez, mintha nem jeleznéd egy gyógyszer mellékhatásait.
Nem véletlenül nem csinál más ilyet. Szimplán a rendszer mintavételezésébe van kódolva a jelentős hibaarány lehetősége. Ennek kiszűrésére is van egyébként megoldás, szintén az egyetemen tanítják.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#42955
üzenetére
A Steam ezeknek a statisztikai módszertani szabályoknak nem felel meg:
- nincs jelezve, hogy mekkora a minta
- nincs jelezve, hogy a megkérdezett mintából mennyi felhasználó élt a visszautasítással
- nincs jelezve, hogy a duplikációk milyen arányban lettek kiszűrve, vagyis nincs meghatározva, hogy adott időtartamra vonatkozóan hányszor szerepel teljesen ugyanaz a gép a statisztikában
- nincs jelezve, hogy egy korábban beolvasott adat, mikor kerül ki a statisztikából, vagyis az adott gép még létezik-e, vagy egyszerűen csak hordozzák évek óta, mert egyszer beolvasták, de lehet, hogy már rég szét van szedveMég egy csomó olyan hibát fel lehet sorolni, ami miatt tudományág a statisztika, és ha nem követed a szabályokat, akkor tudományos szempontból használhatatlan lesz az eredmény.
A Valve ezeket két ok miatt nem jelezheti. Egyrészt szarnak rá, és továbbra is csak nyűg a nyakukon ez az egész. Másrészt annyira kellemetlen lenne ezek feldolgozása vagy bevallása, hogy helyből kivégezné a statisztikájukat.
És akkor még nem is beszéltünk a mintavételi torzításról, ami például az egyik alapvető adat, amikor egy statisztikát készítesz. Ha ez nincs megadva, akkor nem vehető komolyan a statisztika, mert hiányzik az a legfontosabb információ, ami megmutatja a statisztikai hibahatár valószínűségét. Nyilván a Valve-nak megvan ez, de azért nem hozhatják nyilvánosságra, mert a hibahatár elképesztően nagy lehet, tehát minden rész végére oda lehetne írni, hogy teszem azt +/-40%. És mondjuk ez egy kellemetlen dolog, mert ki vesz egy statisztikát komolyan, amiben akkora torzítás van, ami a végeredményt is megváltoztathatja. Ha ezt odaírják, akkor lényegében az egész statisztikájukat leminősítik a "fingunk sincs róla" szintre.
Baj viszont nincs, nem mindenki tanult statisztikai módszertant, így sokan nem ismerik, hogy mitől lesz egy statisztika statisztika.
-
Abu85
HÁZIGAZDA
A COD esetében annyi a helyzet, hogy a CPU-oldali kód nem igazán limitál. Alapvetően az a játék max grafikán mutat olyan terhelésmintát, mint egy másik játék 1080p-ben low grafikán. Ezen úgy lehetne változtatni, ha lassítanák a CPU-oldali kódot, amit nyilván nem fognak, mert akkor minden hardveren lassabb lenne, noha az olló zárulna. A másik lehetőség a grafikai szint növelése, de a COD egy tömegeket célzó játék, és valószínűleg van egyfajta elvárás, hogy hol a terheléshatár, amit még jól tudnak skálázni a gyengébb GPU-kra is, miközben jól néz ki a top GPU-kon is.
Ezért is tehetetlenek a fejlesztők, mert rontani nem fognak általánosan a sebességen, hogy a Radeonok és a GeForce-ok közelebb kerüljenek egymáshoz, javítani pedig nem tudnak a GeForce-on, mert a lassulást okozó többletterhelést az NV drivere adja hozzá, arra nincs ráhatásuk. Az NVIDIA-nak kell kivenni a CPU-oldali emulációkat, hogy felszabaduljon a processzoridőt, amit a játék utána befoghat.
Ugyanez volt a DirectX 11-ben az AMD és az NV között. Ott az NV DirextX 11 drivere sokáig jobban működött, ami látható volt a gyengébb CPU-kon. Most ez fordítva van a DirectX 12-nél. Erre egyébként immunis lenne a Turing, az Ampere és az Ada, mert már CPU-oldali emuláció nélkül is pure bindless dizájnok, csak a meghajtó kódja a legrosszabb lehetőségre van írva, és az, hogy még mindig támogatott a Maxwell és a Pascal, nagymértékben visszahúzza a sebességet az olyan játékokban, mint a COD, és kb. minden részben limites szituációban, pl. 1080p low-medium grafika. De az is gond, hogy ha a Maxwell és a Pascal támogatása kikerül, akkor egy tényleg pure bindlessre írt meghajtót az elejétől kell felépíteni, és az nagyon megfontolandó egy olyan időszakban, amikor aktívan DirectX 12-es minden játék. Egy újraírással ismét jönnek a kezdeti gyermekbetegségek, a hibák, jó másfél év, mire ezt kigyúrják, stb. Ezért nem kezdhetett ebbe még bele az NV, mert látják az előnyöket, de tisztában vannak a kockázatokkal is. És általában van olyan tapasztalat a cégeknél, hogy nulláról újraírni nem jó ötlet.
-
-
Abu85
HÁZIGAZDA
A COD nem a raszter teljesítmény miatt ilyen. A driver az oka, nem a hardver. Egyszerűen sokkal kisebb a Radeonoknál a CPU többletterhelése. Ha a hardver lenne az oka, akkor rég kijavították volna a fejlesztők, de korábban beszéltem erről az érintettekkel, és nem tudnak mit tenni ez ügyben. Nincs ráhatásuk arra, hogy a driver többletterhelése mekkora. Ha sokkal nagyobb lenne a CPU-k órajele, akkor a GeForce-ok jobban skálázódnának.
-
Abu85
HÁZIGAZDA
Tökre van értelme. A működés szempontjából a VGA-ra kialakított áramforrás a 12VHPWR. Ez van direkten rákötve arra a kis csatira a PCI Express mellett. A többi csati extra áramforrás máshoz. Azt már tudni, hogy az alaplap be sem kapcsol normálisan egy energiaigényes VGA-val, ha a 12VHPWR nincs rádugva. Konkrétan egy fail-safe üzemmód lesz, ami felhívja a user figyelmét, hogy kihagyta a csatit.
A 8 tűs csatikat használni kell a tuninghoz.
Egyébként ennek az értelme igazából az, hogy a kábelek elrejthetők. De más értelme nincs.
Műhelytitok, hogy kaptam is leveleket, hogy miért nem írom meg, meg hogy az emberek pénzt költenek miattam, hogy nem szólok nekik, hogy szeptemberben új generáció jön. 
Tehát effektíve sikerült engem is belerángatni, hogy faszé nem írok hazugságot. 
És ezt nem most kezdtem el mondani, régóta közlöm, hogy semmi valóságalapja nincs ennek az őszi frissítésnek, mert nem tud róla senki semmit. Szóval már vártam a hírt, hogy mikor lesz megmagyarázva, hogy mégsem jön ősszel. És természetesen úgy lett tálalva, hogy itt bizony csúszik a dolog, mert ugye olyan nehéz nem módosítani a GPU-n, a NYÁK-on, a memórián, stb. Ez az NVIDIA-nak megugorhatatlan feladat úgy, hogy minden komponens a birtokukban van most is. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az 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.
- Vezetékes FEJhallgatók
- Külföldi prepaid SIM-ek itthon
- EarFun Air Pro 4+ – érdemi plusz
- Kuponkunyeráló
- A vártnál korábban érkezhet a Xiaomi 17 Ultra
- 5.1, 7.1 és gamer fejhallgatók
- Projektor topic
- Apple iPhone 16 Pro - rutinvizsga
- Konzolokról KULTURÁLT módon
- sRGB? DCI-P3? Ez áll a színhelyesség mögött.
- További aktív témák...
- GeForce RTX 4070 SUPER GAMING OC
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- GIGABYTE XTREME RTX 3080 Ti 12GB GDDR6X Videokártya!
- RTX 5000-ES SZÉRIA ÚJONNAN GARANCIÁLIS ELADÓ TERMÉKEK! 5050, 5060, 5070, 5080, 5090.
- Gigabyte AMD Radeon RX 9060 XT GAMING OC ICE 16GB(Bontatlan)
- Samsung Galaxy A56 / 8/256GB / Kártyafüggetlen / 12Hó Garancia / Akku: 100%
- BESZÁMÍTÁS! Asus H370-A i5 9600K 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman T7 Zalman 500W
- Bomba ár! Dell Vostro 3550 - i3-2310M I 4GB I 250GB I DVDRW I 15,6" HD I HDMI I Cam I Garancia!
- Gamer/streamer mikrofon, állvány és USB HUB kitűnő árakon!
- Bomba ár! HP ProBook 450 G8 - i5-1135G7 I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Gar
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest