- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Ez össze van rakva - Segway Ninebot F3 Pro
- iPhone topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A35 5G - fordulópont
- Listázzák az olaszok a Redmi 15C-t
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- A Z Fold7, vagy a Magic V5 a vékonyabb valójában?
Új hozzászólás Aktív témák
-
-
gabber01
addikt
Az ilyen speciális felhasználásokat megértem, persze. De a túlnyomó többség semmire nem használja igazából, csak azért rakja fel, mert "ez jól beállít mindent és több heccsátot tud osztani, mert jobban megy majd a game".
Vagy azt se tudják, hogy mire szolgál, csak felrakják mert benne van a driver csomagban és nem is foglalkoznak vele. -
-
hapakj
őstag
Így van. Tehát az nVidia hw alkalmas rá és képes is rá. Igaz, főleg 6-8 magnál jön meg a gyorsulás, akkoriban meg az még annyira nem nagyon volt jellemző. Érdemes lenne bepattintani pár régebbi VGA-t valami erős több magos CPU mellé s megnézni mit csinálnak Deferred Contexttel. Mint írtam a tech kicsit megelőzte a korát
-
Abu85
HÁZIGAZDA
Ez szintetikus program, ami csak grafikát mér. És itt volt az a probléma, hogy ha a program egy játék, vagyis nem csak grafikát számol, akkor már baromira nem ez a helyzet. Ezért értette félre az egész iparág, hogy itt ez működhet. Mert csinálták egy darabig, aztán mindenki mutatta, hogy tök jól a szintetikus programok, de játékban, gyakorlatban nem működik. Aztán erre a problémára jött is a Mantle, ami viszont játékban is működött, majd onnan DirectX 12, Vulkan, a többi már történelem.
-
Abu85
HÁZIGAZDA
Ha képes lett volna, akkor a deferred context egy ma is létező elterjedt irány lenne, de mivel nem volt képes rá, így megbukott. Még egyszer kihangsúlyozom. Megbukott. Ezt onnan tudhatod, hogy több játék érkezett egy teljesen új, gyártófüggő Mantle API-ra, mint szabványos DirectX 11-es deferred contextre. Tehát a fejlesztők inkább vállaltak egy nem szabványos irányt, mint egy szabványost, ami nem működött. Helyette DirectX 11-ben manuális többszálúsítást használtak immediate contexttel.
-
Abu85
HÁZIGAZDA
Attól lesz rossz, amit a gyakorlatban láttál. Hogy nem tudta ellátni a feladatát az OpenGL, mint szabvány. Kenegethetjük, hogy ki mennyire hibás benne, de végeredményben az API-t ez kivégezte.
#74 hapakj : A deferred contexttel a legnagyobb gond, hogy egy komplex alkalmazásnál nem működött. Erre volt is példa az Ubisofttól az Anvil egy verziójától kezdve. Azt azért rakták deferred contextre, mert végig hitegették őket a cégek arról, hogy ez működni fog, a driverket adták oda, hogy csinálják a kódot, és majd hozzák a sebességet. Aztán az Intel és az AMD elkezdte mondani, hogy ezt benézték, mert nem fog igazán működni, de az NV még mondta, hogy működni fog az. Aztán végül kiderült, hogy nem működik, csak már túl későn.
A probléma egyébként az a rengeteg kontrollálhatatlan driver szál volt, és nem véletlen, hogy a Mantle ezt tüntette el elsőként, és innen a DirectX 12 és a Vulkan is.
-
hapakj
őstag
Hát amúgy deferred contexttel kapcsolatban érdekes, hogy az intel azért kimérte és kétszer is megemlíti a cikkben, hogy a hw-es gyorsítás a dx11 deferred contexttel hoz gyorsulást. A grafikonon is látszik, hogy 1080 szépen gyorsul deferred contexttel, míg a Vega az lassul.
Bár az nvidia is csak 6-8 cpu magnál kezd gyorsulni. Valszeg nem volt hatékony a deferred context ezt aláírom, meg igazából vágom a technikai hátterét is, hogy miért. De látszik, hogy megfelelő mennyiségű maggal és hw-es támogatással hozott eredményeket.
Valszeg abban az időben, még nem volt jellemző ennyi CPU mag, meghát nvidian kívül senki se támogatta, szóval,nah, nvidia kicsit megelőzte a korát
-
hapakj
őstag
Ha a szabvány nem mond semmit arról, hogy mi legyen a nem szabványos kód esetén, akkor mitől lesz rossz az implementáció? Ok írok egy példát.
Feladat, számoljuk ki 1*A + 1*B + 0*C -t. A szabvány azt mondja, legyen A, B és C jól specifikálva, ha nincs dobjunk egy errort.Definiáljuk A = 3, B = 4,
C - nincs definiálva
1) nvidia: visszaad 7-et (A+B), és dob egy hibát - szabványos, conform
2) sok implementáció (pl intel, apple): visszaad 0-t, dob egy hibát - szabványos, conform
3) amd: visszad: 34224-t, nem dob hibát, crashel
- öööhmmm Az OpenGL szabvány remekül leírja, hogy csomó objektum, mikor van valid meg invalid stateben és hogy ha invalid resouce-t használsz, akkor error-t kell küldeni meg undefined behaviour de ennyi. Pl textúra. Akkor lesz valid, ha összes mipchain fel van töltve. nVidia driver rajzol annyival, amennyi fel van töltve, más implementáción fekete kép. Persze mindkettőn lekérdezhető, hogy invalid a texture state. S ez mind szabványos viselkedés.
Az hogy hibák nehezen jönnek szembe az az OpenGL design hibája is, hogy minden művelet után le kell kérdezni volt-e hiba? Az ARB debug output ebben már előre lépés volt, hogy van callback.Amúgy a 3 eset közül, hát a 3. az nyilván no-go, az 1 és 2 kérdéses, másak az előnyei. 1-el gyorsan lehet haladni, lehet iterálni, algoritmusokat kipróbálni, de veszélyes, hogy esetleg valami olyat csinálunk, amit nem akarunk. A 2. opció biztosítja, hogy jó kódot írunk, de sokkal nehézkesebb lehet vele haladni.
Amúgy a Vulkan sem egy szent grál ilyen téren. Ott ugye megfogták és kiszedték a teljes hibakezelést az implementációból. Lényegében mindenki driveréből nvidia driver csináltak, hiszen bármi nem szabványos kód is működhet véletlenül, ha a hw-en megengedett
S elő is fordul, mert nem mindenki fog minden validációs layerrel bekapcsolva fejleszteni. Pl szinkronizációs layer, mert kegyetlen lassít. Lehet dugig van intelen szinkronizációs hibákkal a kód, de remekül megy, mert ott nem kell szinkronizálni a hw jellegéből adódóan.
Ott az az előrelépés, hogy elvileg vannak a szabvány validation layerek, s elvileg azok jelzik a hibákat, s talán majd minden implementációval működni fog. De ennek ellenére vannak vendor specifikus layerek is. Amúgy jah, nagy előrelépés, lemásolták a koncepciót amit DX mindig is követett -
Abu85
HÁZIGAZDA
Az a fő kérdés itt, hogy az NVIDIA szándékosan fogadja-e el a nem szabványos kódot, vagy csak rosszul írták meg a saját implementációjukat. Ha szándékosan fogadják el, akkor azt nyugodtan lehet úgy értékelni, hogy nem érdekli őket az API specifikációja, önhatalmúlag félreértelmezik. De persze nem kizárható, hogy nem jól írták meg a meghajtójukat. Azt is emberek írják, akik hibázhatnak. Az OpenGL-nek persze ez már mindegy.
Itt nem arról van szó, hogy nincs hardveres támogatás, hanem arról, hogy maga a funkció lassított egy csomó esetben. Emiatt pedig kétségessé vált az, hogy ezt szállítani kellene-e meghajtóban, mert a hardver ugyan lefuttatná a kódot, de lassabban, mint ha nem lenne elérhető a funkció. Utóbbival nem menne sokra senki. Ezért lett kukázva teljesen ezt a deferred context irány. Ha működött volna, akkor lenne rá support, mert hardveresen nem igényelt semmi extrát. Ezt onnan lehet tudni, hogy az Ubisoftot még hitegette mindegyik gyártó, hogy működni fog ez, kaptak is drivereket, amikor az Ubi ezt a deferred context irányt választotta. Aztán megszívták, mert egy gyártó sem tudta szállítani nekik az ígért sebességet, mindegy volt, hogy végül a funkciót engedélyezték-e a driverben vagy sem. Többségében nem, mert pont azokon a helyzeteken lassított, amikor a legnagyobb szükség volt a teljesítményre.
-
hapakj
őstag
A szabvány nem csak azt határozza meg, hogy mit lehet, hanem egyben azt is, hogy mit nem lehet.
- s hogyan sérthette meg az nvidia implementációja azt amire az OpenGL specifikációban nem tértek ki? Tehát Undefined Behaviour? Ez a szabvány hibája, nem pedig az implementáció-é.Nyilvánvaló, hogy ha bele van írva a specifikációba valami, akkor azt úgy értelmezik, hogy úgy működjön, ahogy le van írva,
- nem tapasztaltam, hogy ezt az nVidia implementációi bármikor is megszegték volna. Mint írtam szabványos kóddal semmi gond nem volt nVidian.Hát van itthon Terrascale kártyám. Explicit azt írta ki, hogy a Concurrent CommandLists nincs támogatva D3D11 alatt, ahogy nVidia Tesla kártyákon sincs, de Fermi-n viszont már igen.
-
Abu85
HÁZIGAZDA
A legnagyobb hiba egy implementációnál, ha nem csak a szabványos kódot fogadja el. Ennél nagyobb hiba nem létezik, mert így a szabvány értelmét veszti, hiszen írhatsz olyan nem szabványos kódot, ami fut. És akkor mi értelme van így a szabványnak, ha olyan kódot is elfogad az implementáció, ami nem szabványos?
A szabvány nem csak azt határozza meg, hogy mit lehet, hanem egyben azt is, hogy mit nem lehet. Nyilvánvaló, hogy ha bele van írva a specifikációba valami, akkor azt úgy értelmezik, hogy úgy működjön, ahogy le van írva, és ne értelmezze úgy egy gyártó sem, hogy jó hát neki ez nem tetszik, ezért még többféleképpen is működhet, mert az biztos jó lesz.
Ha belefért volna ez a dolog, akkor nem végezte volna ki ez az API-t.
A szabványosságot a conformance test adja. Ha átment, akkor szabványos.
Akkor nagyon szűken értelmezed a többszálúságot, mert alapvetően az, hogy különböző kontextusokat kioszthatsz különböző szálakra, már többszálúság.
Igen, az egy runtime funkció, és sosem működött. Emiatt a legtöbb DirectX 11-es játék, nem is használta, mert hasznosabb volt Directx 11-ben is azzal a körülményes módszerrel dolgozni, amit felvázoltam az OpenGL-nél. Egyszerűen gyorsabb volt az eredmény, mint deferred contexttel.
A DirectX 11 deferred contextet már a Radeon HD 5800 is támogatta. Nem kellett hozzá speciális hardver. A gond az volt, hogy lassított egy csomó esetben. Emiatt nem használták a játékok. Ha valami nem működött, lassította a teljesítmény, akkor persze, hogy hanyagolták. A deferred context működésképtelensége hozta el igazából a nagy API váltásokat. És persze a gyártók támogatták ezt, de igazából minek, ha nem működött...
-
hapakj
őstag
A "nem szabvány követő implementáció" konkrétan megkérdőjelezi egy API létjogosultságát.
- Mi? Az nVidia implementáció követte a szabványt. Semmi problémája nem volt a szabványos kóddal, tökéletesen működött rajta. A helyzet az volt, hogy a szabványt nem betartó kód is ment rajta. De itt a fejlesztő nem követi a szabványt, nem pedig az implementáció. Arra meg általában az OpenGL specifikáció is kb annyit írt, hogy Undefined Behaviour, abba meg az is belefér, hogy működik a dolog. Egyébként az általad említett ARB_debug_output ha jól emlékszem nVidia driverrel is szépen mutatta a nem szabványos használatot, amellett, hogy közben jó eredményt adott.Az viszont nem szabvány követés, hogy szabványosan megírt kód nem működik. Amit az AMD csinált.
Az AMD az OpenGL meghajtóját kétszer is újraírta.
- jóhát a tapasztalataim nem az API végnapjaitól vannak, hanem előtte. Hát jól tették, hogy újraírták. Bár abban az időben az Intel, meg nVidia driverei teljesen jók voltak OpenGL-ben a több kontextus kezelése, meg amiket leírtál az nem multithread rendering. Ezekkel nem lehet párhuzamosan rajzolási parancsokat kiadni. Az általad említett usecasekre sem nagyon találtam példát, s mint említetted elég körülményes.
A DX11 deferred context az igazából API runtime funkció, tehát mindenütt elérhető emulálva, de igazából kell hw-es, meg driver support. Azt mondjuk elég régi nVidia kártyán is láttam támogatva, hasonló korú AMD-sen nem. Illetve még egész modern Intelen sem. Még nem mélyedtem bele a témába, de inkább hanyagolt funkciónak tűnt, mintsem nem működőnek, amiatt mert sok helyen kb csak emulálva ment.
-
Abu85
HÁZIGAZDA
A "nem szabvány követő implementáció" konkrétan megkérdőjelezi egy API létjogosultságát. Mert mi értelme a szabványnak, ha nem kínál szabványosságot?
Mégis megtették. Tényleg nem tudom, hogy miért, de alapvetően mindenki tudhatta az NV-nél, hogy ha nem követik a szabványt, akkor a szabványt kérdőjelezik meg, és ölik meg.
Az AMD az OpenGL meghajtóját kétszer is újraírta. Másodjára azt érték el vele, hogy maga a Khronos is AMD hardvert javasolt a fejlesztésekhez, mert szabványkövető volt az implementáció az API végnapjain. Persze nyilván ez már az API-n nem tudott segíteni. Főleg úgy, hogy jött/ott volt a Vulkan.
Lehetséges volt OpenGL-ben az, hogy több szálban különböző kontextusokat használj, majd ezeket fel lehetett használni textúraadatok betöltésére, vertex puffer frissítésére, vagy az új shaderek fordítására különböző szálakon. Csak rohadt körülményes és kiszámíthatatlan volt az egész, ahogy például a DirectX 11-nek is borzasztóan szarul működött a multi-threard része. De ugye ezért jöttek az újabb API-k.
És a DirectX 11-nek a deferred context többszálúságát mindenki implementálta a gyártók közül. Azért nem volt lényegi hatása, mert a játékok nem használták ezt, mert szarul működött. Helyette olyan módszert használtak a játékok, mint a manuális többszálúsítás immediate contexttel. Ehhez hasonlót használtak modern OpenGL programok is. Nem volt tökéletes, de sokkal jobban működött, mint a deferred context. De persze a DirectX 12/Vulkan lehetőségeit meg se közelítette. -
hapakj
őstag
Mint írtam, nem volt nagy nehézség váltani az Intel IGP-re és kijavítani a hibákat.
Nem szépítek én semmit, az nVidia nem szabvány követő implementációja nyilván nem tett jó az API-nak, bár szerintem az AMD nem működő implementációja sem
Amúgy nem gondolnám, hogy az nVidiának bármi érdeke lett volna kinyírni az OpenGL-t, hiszen egy high level API-n keresztül jobban a kezébe tudja tartani a kontrolt, s ugye az nVidiánál ez nem ördögtől való. Az OpenGL-t inkább az nyírta ki, hogy PC-n nem sok értelme volt. Valszeg az AMD OpenGL driverei is azért voltak vackok, mert a DX-re koncentráltak.
Nomeg, hogy az OpenGL teljesen alkalmatlan multithread renderingre. már a DX11-ben is voltak erre megoldások, bár ha jól tudom azt is ténylegesen csak nVidia implementálta.
-
Abu85
HÁZIGAZDA
És milyen jót tett az OpenGL-nek, hogy az NV implementációján nem tudtad ellenőrizni, hogy jó-e a kód. Ja nem, konkrétan megölte az API-t.
Szépítheted, hogy ez milyen jó volt, de ettől még konkrétan kivégezte az NVIDIA az OpenGL-t. Azt ne kérdezd, hogy miért tették, de nyilván tudatában voltak azzal, hogy egy API-nak az a legkárosabb, ha szabadelvűen javítgatják az implementációban a hibás kódot. Ez pusztán szakmai háttérből ered. Tudták jól, hogy így az API elveszíti a létjogosultságát, amiért egyáltalán létezik.
És az most szerintem mindegy, hogy a Vulkan API-val sokkal jobban jártunk, tehát végül jól jött ki ebből az ipar.
-
hapakj
őstag
Hát nemtom. Szerintem akármilyen szabványt használunk, teljesen alap, hogy a lehető legtöbb gyártó implementációval tesztelünk. Kb a legkevesebb volt kijavítani az nVidia specifikus szabványtalanságokat, cserébe a hw-ükön lehetett haladni a fejlesztéssel és jól és hamar implementálták az új featureöket.
Az a fejlesztő aki nem tud beröccenteni, két - három másik platformot, pl Intelt, aminek kiváló szabványos implementációja volt az magára vessen.
Azzal viszont meg egy fejlesztő sem tud mit kezdeni, ha a driver szar. Jah, igazából tudtunk. Be kellett rakni egy másik code path, ami nem PBO-n keresztül tölti fel a textúrákat csak hogy menjen AMD-n is.
-
hapakj
őstag
A mindent meglévő implementáció azért nem működik, mert mindent megeszik.
- Hogy mi? Mint mondtam a kód a legtöbb platformon működött.A szabványt meglehetősen szigorúan implementáló Intel és Apple OpenGL driverekkel is. A legtöbb mobil platformon is működött és nvidia-n is. Tehát ezek működő implementációk voltak.
AMD-n pedig nem működött.
Az hogy az nVidia nem teljesen szabványos implementációja hogyan volt káros az OpenGL-re az egy teljesen más kérdés, s az is más, hogy az AMD nem működő drivereket produkált.
-
Abu85
HÁZIGAZDA
A mindent megevő implementáció azért nem működik, mert mindent megeszik. És ez ki tud végezni egy teljes API-t, mert nem látja el a feladatát az API, ha akármilyen hibás kódot elfogad egy implementáció.
Az OpenGL valahol az OpenGL 3-tól került ilyen válságba. Az OpenGL 4 után pedig elég nagy volt a válság. Tehát az, hogy a Khronos Group arra kényszerül, hogy azt javasolja, hogy AMD és Intel GPU-n fejlesszenek a stúdiók, egy API halála, mert tulajdonképpen az API azt a feladatát nem látja el, amiért létrejött, hogy ugyanaz a kód fusson akármilyen, adott implementációt biztosító hardveren. Amikor egy API fejlesztője ezt akár csak a különböző fejlesztői fórumokon is kimondja, azzal magát az API-t öli meg, mert megkérdőjelezhetővé teszi a létjogosultságát, ha szelektálni kell a fejlesztésre használhatónak ítélt hardvereket.
Az, hogy szándékosan félreértelmez egy implementáció bizonyos specifikációkat, az a legnagyobb hiba, mert bugok lehetnek egy driverben, de a szándékos félreértelmezés nem javítható, mert az szándékosan ilyen. És az NVIDIA ezzel a hozzáállásával konkrétan megölte az OpenGL-t. Nem tudom, hogy ez koncepció volt-e számukra, de megtették, és ki is pusztult az OpenGL mára. Annyi előnye volt az egésznek, hogy a Khronos okosabban csinálja a Vulkan API-t, ott már nem engedi meg ezt senkinek.
-
hapakj
őstag
Ez mind világos. Tisztába vagyok vele, hogy az nVidia implementációja mindent is megevett, de legalább működött.
AMD viszont. Hát abban az időben rengeteg probléma volt vele
A fentebb említett srgb textúra feltöltés PBO-val. Vagy a compute shaderek se nagyon nyekkentek meg Közben semmi hibát nem adott se nVidián se Intelen és helyes eredményt produkált, meg a debug warningok is ki voltak javítva erre odafigyeltünk. Egyszerűen az AMD implementáció messze nem működött. Ment is nekik bug report, de érdemben nem reagáltak
Hja az srgb PBO feltöltés aztán pár hónappal később meg is javult. Nyilván mert az konkrétan hiba volt.
az AMD és az Intel OpenGL implementációja legalább az egyértelműen hibás kódot nem hajtja végre.
- hát az AMD a helyeset se -
Abu85
HÁZIGAZDA
Ez jogilag lehetséges. A termék működik a driverrel, az nem köthető vezérlőpulthoz, de például az NVIDIA App egyes részei ahhoz vannak kötve, és azzal az EU-nak nincs is baja, mert azok a részek nem szükségesek a termék alapvető működéséhez. Tehát ez többszintű dolog. Az NV sem akar itt mindent regisztárcióhoz kötni, csak az egyes beállításokat. Ha meg azok nem kellenek, akkor használd a natúr drivert vezérlőpult nélkül. Az mindig szabad lesz.
-
Abu85
HÁZIGAZDA
Az egész OpenGL-nél arról volt szó, hogy a maga a Khronos Group-ot valamiért nem érdekelte, ha a gyártói implementációk nem egységesek. Volt is egy felvetés régebben arra vonatkozóan, hogy ezt újradolgozzák, és akkor resetelik a conformance testet is, hogy egyértelmű legyen az egész. Ez Dan Baker szerint ott bukott el, hogy egy gyártó szükségtelennek tartotta.
A fentiek miatt érkezett az ARB_debug_output kiterjesztés, ami legalább szólt, ha klasszikus nem szabványosan csináltak dolgokat a gyártók. Sőt, néha tippeket is adott. Csak ezzel meg az lett a probléma, hogy az ARB_debug_output hiába sipákolt, a fejlesztő mondjuk egy NV-s gépen azt mondta, hogy működik ez, akkor minek hozzányúlni. És ez volt a nagy baj, mert az NV nagyon szabadon dolgozott az implementációban. A hiányzó szinkronizációkat megcsinálta automatice, mert miért ne? Biztos nem gond az, hogy ez nem szabványos. Aztán a fejlesztő lesett, hogy ez a nem szabványos kód, amire az ARB_debug_output bőszen sipákol, hogy hibás, NV-n fut, máshol meg nem. És ez ölte meg az OpenGL-t. Mert ezt a helyzetet a Khronos Group nem tudta kezelni. Sőt, az OpenGL végnapjaiban konkrétan azt javasolták, hogy használjon mindenki a fejlesztéshez AMD és Intel GPU-t, mert az AMD és az Intel OpenGL implementációja legalább az egyértelműen hibás kódot nem hajtja végre.
A Vulkan esetében több nagyságrenddel jobb a helyzet. Eleve nagyon szigorúan veszi az egészet a Khronos. Az érkező kiterjesztéseket jól átdolgozzák, amikor felveszik KHR-be. Nagyon egyértelmű, hogy mit és hogyan kell implementálnia a gyártóknak. Nincs is olyan baj a Vulkan API-val, hogy hibás és hiányos kódot csak úgy lefuttat az egyik implementáció, mert az olyan cool, ha csak úgy a driver kiegészíti a kód hibáit, hogy azok nem látszódjanak.
-
hapakj
őstag
válasz
Predatorr
#54
üzenetére
Szerintem még regisztrációhoz sincs joguk kötni. A driver a termék része, mert azzal lesz működőképes, s az EU-ban valszeg nincs joguk forgalmazni a nélkül.
Igazából nem is tudom honnan jött ez a regisztrációs agymenés
Igen, jó volt. Mindig működött.
- miért most nem működik?
-
Predatorr
őstag
Felhasználóként egyáltalán nem érdekel, hogy egy termék miért szar. Ha nem tudják rendesen megcsinálni, menjenek akkugyárba összeszerelőnek, hátha az menni fog.
Igen, jó volt. Mindig működött.
Szerintem meg pedig de. Először csak regisztrációhoz kötik, aztán jöhet a többi, mint az AI-nál. Az biztos, ha csak a reget meglátom, az azt megelőző lesz az utolsó nV meghajtóm, és az utolsó nV kártyám.
Hát a legtöbb párkapcsolat ilyen. -
hapakj
őstag
válasz
Predatorr
#52
üzenetére
ööööö. Hát sem egy szakdolgozat, sem bármilyen DOS-os alkalmazás közelében sincs komplexitásban meg lehetőségekben, amit egy videókártya driver tud nyújtani.
Jah, DOS-ba semmi vezérlőpult nem volt, csak a játék beállításaiban kellett display módot állítani, hogy VESA vagy 13-as mód, vagy melyik. Meg manuálisan beállítgatni a hangkártya IO címét, DMA és IRQ számát. Tényleg milyen jó is volt driverek nélkül
Amúgy az, hogy két modul külön külön jól működik, tényleg nem egyáltalán evidens, hogy együtt jól fognak működni.
"aztán nV egyszer csak fizetőssé tesz a drivert is..."
- ööööö. lol. Szerintem erre explicit joguk sincs -
Predatorr
őstag
De, pont, hogy logikus. Láttam már pár szoftvert. Anno kivágták államvizsgáról, aki hibásat írt (külön téma volt a hibakeresés), ma meg „iparági norma” a szar.
Szopjanak a fejlesztők, azért fizetjük őket, nem? Nem rémlik, h mondjuk DOS alatt annyira hiányzott volna bármiféle vezérlőpult, tehát nincs rá szükség. Olyan, mint autókban az elektronika: elfedi a szar kunstrukciót. Sőt, évekig nem kellett cserélni. Most meg ezzel kényszerítenek újabb vásárlásokra, aztán nV egyszer csak fizetőssé tesz a drivert is...
AMD RTX remek kódbázis...
-
hapakj
őstag
hááát, ez annyira nem ment, hogy nem a specifikációval értelmezésével volt a gond. Csodálkozom, hogy egyáltalán át mehetett a conformance teszteken. Valszeg csak addig kalapálták a drivert, míg azon át nem ment
Az egyik probléma srgb textúrák PBO-n keresztül feltöltése volt. Mire rájöttem mi a hiba és rá tudtam keresni, kiderült, hogy csomó fórum bejegyzés volt erről AMD dev fórumain, hogy mások is belefutottak.
-
Abu85
HÁZIGAZDA
A reportot nem a gyártó dönti el. Conformance test van, és aszerint van hitelesítve, hogy egy meghajtó milyen verziónak felel meg. Mondjuk az OpenGL ebből a szempontból kényes, mert a gyártók basztak egységesen értelmezni a specifikációt, így végül ez az API halálát is okozta, hiszen minden gyártóra külön kódútra volt szükség. A Khronos ebből tanulva sokkal szigorúbb a Vulkan API-val, ez előnyös is lett.
-
-
Abu85
HÁZIGAZDA
válasz
NvidiaRTX
#47
üzenetére
De a te meggyőződésed hogy jön ahhoz a témához, hogy egy driver sosem lesz kész? Ez mindenhol így van, mert a driverek sosem lesznek készek. Minden hónapban van egy-két új kiadás. Ha valaha is kész lenne, akkor sosem jönne új meghajtó.
Az a te megküzdési saját stratégiád, hogy próbálod erőteljesen bebeszélni magadnak, hogy a saját döntéseid csak jók lehetnek. Nyilván azért van erre szükséged, mert amúgy bizonytalan szoktál lenni, de ha meg tudod megad győzni arról, hogy mégis jól döntöttél, akkor pszichológiailag az teljesen rendben van. Viszont a témához aztán semmi köze annak, hogy ki hogyan simogatja a saját elméjét.
A tényszerű valóság a driverek ügyében az, hogy minden hónapban jön legalább egy frissítés. Amíg ez megtörténik, addig kijelenthető, hogy a driverek sosem lesznek készek.
-
NvidiaRTX
őstag
"hogy egy driver sosem lesz kész"
Igen ezt párszor már tapasztaltam AMD-nél és a konklúzióm ez lett:
Soha többet AMD.
"Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak"
A hivatalos szóvivő azt mondja amit mondanak neki meg amit szeretne hallani a nép (lásd a mostani kormány), míg a meg nem nevezett forrás vagy a kívülállók (444) sokszor a valóságot mutatják be. -
Abu85
HÁZIGAZDA
válasz
Predatorr
#43
üzenetére
Ha van két modul, ami külön külön jól működik, akkor nem logikus feltételezni, hogy együtt meg nem működnek jól. Persze lehetséges, csak ritkán fordul elő. Most nyilván előfordult.
Azt is érdemes számításba venni, hogy egy driver sosem lesz kész. És ez nagyon-nagyon fontos, mert itt nem arról van szó, hogy egy szoftver majd elérheti a gold állapotot, amikor már nem látni benne hibát, ettől még van benne, csak nem látni, vagy nem kritikus a bug. Amikor a vezérlőpultokat cserélik, akkor az AMD és az Intel is úgy csinálta, hogy elértek egy relatíve jó állapotot, és kiadták, majd utána még bő egy évig javítgatták azokat. Az NVIDIA is ugyanebbe vetette bele magát. Tudták ők is jól, hogy ha elérnek egy kiadásra jónak tűnő állapotot, amit be mernek vállalni a tényleges cseréhez, akkor még legalább egy évig javítgatni fogják a bugokat. Sőt, ugye az NV úgy váltotta le a vezérlőpultot, hogy az NVIDIA App még nem is implementált mindent, tehát még messze nincs kész funkcionálisan, de ki kellett adni, mert szorít az idő. Sőt, újabban azt is kérdezgetik, hogy bizonyos funkciók szükségesek-e, vagy pusztán dobják ki, mert senki sem használja őket.
Ezt fel lehet fogni hibaként, és tulajdonképpen az is, de a fejlesztés jellegét tekintve bele volt számolva, hogy mostantól még bő egy évig bugok sorozatába futnak majd, és javítgatják majd azokat. Ezzel jár, ha a meglévő kódbázist kidobják, és írnak újat. Aztán ahogy az AMD és az Intel is lehozta igen stabilra a saját váltását, az NV is meg fogja oldani úgy 2026 közepére. És ez tervszerűen be van kalkulálva, nem váratlan dolgokról van szó. Tudták, hogy ugyanúgy szopni fognak a váltással, ahogy az AMD és az Intel is szopott, de meg kell csinálniuk, mert húsz évvel korábbi szinten ragadtak, és azt kötelezően modernizálniuk kell, hogy ne kelljen két program a funkciókhoz, és gyors legyen a vezérlőpult. Ha például megkérdeznéd az AMD-t és az Intelt, hogy szoptak-e rendesen a saját váltásukkal, akkor azt mondanák, hogy igen, gigaszopás volt, de visszagondolva minden szopás megérte, mert most meg jó és modern kódbázisuk van, aminek a karbantartása olcsóbb. Az NV is ezt fogja mondani két év múlva. Kurva nagy szopás lesz/volt, de hosszabb távon megéri modernizálni.
-
-
-
GreatL
őstag
válasz
NvidiaRTX
#37
üzenetére
420-as AIO-val stresszteszt 80 celcius, nem megy fölé. Tuningra beírkodtam amit mindenki ír (E-Core, P-Core, Ring, RAM), működnek a dolgok. iGPU-val használom, ami 2500 MHz-en fut így jobban teljesít játékokban mint a gyári beállítása. Várom az RTX 50-es VGA sorozatot.
-
Abu85
HÁZIGAZDA
Ezek úgy szoktak belekerülni, hogy volt egy build, amivel tesztelték, és szuper volt, majd módosítottak valamit, nem is magában a funkcióban, és külön a módosítást tesztelték, de a funkció maga korábban működött, így nem volt okuk feltételezni, hogy gond lesz.
Ehhez hasonlók egyébként nagyon-nagyon sűrűn előfordulnak egy ekkora változásnál. Az AMD és az Intel is szívott hónapokig hasonló bugokkal, amikor ők modernizáltak.
-
kamuintro
csendes tag
Több olyan beállítás is van benne ami eddig nem volt, szóval felőlem 20 százalékot is zabálhat le biztos nem törlöm. Az a HDR beállítási kényelem amit ad, hogy HDR-be nézhetem az SDR filmeket, animéket és be tudom állítani és testre tudom szabni a tartalomhoz illően, az aranyat ér.
-
tomas51
senior tag
Szerintem közel sincs a játék akkora fps re kitalálva, próbáld lockolni mondjuk 100 ra, ha úgy stabil akkor valószínű minden oké csak a játék nem tudja le kezelni, van ilyen
van olyan játék aminek a portja pl 60 fps re van jól írva és ott gond nélkül megy, de felette meg mindenféle fura dolog történik -
gekkoXT
senior tag
Nekem az első nvidia app-os studio driver-ről minden gpu-t használó szoftver fagyott. Játéknál ment a hang, kép elment. Képszerkesztő videó vágó programoknál akadozások, lassulások voltak. Visszaléptem az előző driverre, egyből megszűnt a gond.
Köszönöm az idegbeteg órákat. -
#26
Alogonomus
őstag
hapakj
#22
Alogonomus
őstag
Biztosan nem tudatosan adták így ki. Még akkor sem reális forgatókönyv, ha kicsúsztak a határidőből, és mindenképpen ki kellett adni, mert már beígérték. Akkor már inkább gyárilag kikapcsolták volna a funkciót az eddigi verziókban.
Valószínűleg viszonylag kevesen tesztelték a béta állapotában, és akik tesztelték, azok is inkább a zöld oldal rajongói voltak, tehát nem rohantak azonnal a fórumokra panaszkodni, így az Nvidia ritka hibának hitte a sebességcsökkenést, pedig az szinte minden tesztelőt érintett.
A public béta tesztelők létszámának nyilván az sem tett jót, hogy a teljes funkcionalitáshoz kötelezően létre kellett hozni egy Nvidia fiókot, és sokakat elriasztott, hogy mindenféle személyesebb információkat megosszanak a Céggel. -
Predatorr
őstag
ÉN nem vettem észre lassulást, de eleve slimmerrel irtom a szemetet a driverből. GFX eleve soha fel sem került. Azt viszont észrevettem, h AMD-ről PH-ra nem kerül negatív hír (pl. h dobják a csúcskategóriát, és csak igényteleneknek „fejlesztenek”), nV-ról meg pozitív (pl. PH:-n kívül minden tele az új nV kártyákkal), és ha valaki rossz tapasztalatot ír AMD-ről, máris jön a valóságtagadás.
-
#22
hapakj
őstag
Alogonomus
#19
hapakj
őstag
válasz
Alogonomus
#19
üzenetére
Amúgy érdekes, hogy jött most elő a hiba. Utána nézve tényleg elég általánosnak tűnik a lassulás. Kizártnak tartom, hogy így kiadták volna
Semmit se nyernek vele, csak egy botrányt, amit javítani is kell majd.Meg ha jól tudom hónapokig public beta is volt az App-ból. Annyi idő alatt simán ki kellett volna derülnie. Mintha épp az utolsó pillanatba csúszott volna be valami malőr vagy akadtak össze dolgok.
-
#19
Alogonomus
őstag
Alogonomus
őstag
Csak beigazolódott, amit Abu is megjósolt az Nvida App bejelentésekor.
Az Nvidia is kénytelen végigjárni a hibajavítások sok hónapos/éves rögös útját, mire egy tényleg jól működő keretrendszerig eljut. AMD is sokat szenvedett, mire összeállt a jelenleg már szinte hibátlan Adrenalin. Idővel majd az Nvidia is kiismeri a programja működését, és amikor egy dolgot javít benne, akkor egy másik dolog majd nem fog elromlani tőle, amit végül csak az egyik funkciócsomag teljes kikapcsolásával lehet a következő verzió érkezéséig elfedni. -
scdlsc
senior tag
Engem a nyomorult elnevezések kergetnek őrületbe. Radeon (TM - mert k..va fontos odaírni a saját kliensükbe, hogy trademark) Super resolution. És akkor az mit is csinál? Felskáláz? A frame generation meg nem nagyobb felbontást generál, hanem plusz képkockát rak oda? Vagy az a fluid motion frame? Miért nem lehet egyszerű és világos elnevezéseket használni? Pedig én nem is egyszerű paraszt vagyok, hanem egy Prohardvert is olvasó paraszt, aztán mégis zavaros az egész ezekkel a kacifántos elnevezésekkel. Bár biztos én vagyok a hülye.
-
hapakj
őstag
Jajaja Túl steril volt a tesztkörnyezet. A 15% teljesítményvesztés nem tűnt fel a professzionális szint miatt? Ezt akartad mondani?
- igen ezt akartam mondaniÉn komolyan kérdeztem az indokot. Egyszerűen nem tudom elképzelni.
- én meg komolyan válaszoltam. Az hogy mit tudsz elképzelni nem fedi a valóságot.Itt ugye nem arról van szó, hogy néhány esetben vagy hogy bizonyos környezetben, hanem MINDIG.
- ez az infó honnan jön?Ez olyan, mintha az Audi leszállítana 10000 autót kormány nélkül. Ott sem érteném a szitut.
- ez teljesen értelmetlen -
Akkor várható erről is a updatenkénti hotfix-hír...
-
Cythyel
senior tag
-
ViZion
félisten
nV-ről váltottam AMD VGA-ra... az is ehhh... Villódzás itt, pixelesedés ott.. végül (kis fórumozás után) a mindenféle spéci AMD fícsört kikapcsolva jó lett minden is.
Ezért érdemes volt fejleszteniük fancy nevű kapcsolókat, h aztán off-on legyen minden.
nV oldalán is voltak bajok korábban is, de ez ilyen, így szeretjük.
-
Héraklész
aktív tag
Jajaja Túl steril volt a tesztkörnyezet. A 15% teljesítményvesztés nem tűnt fel a professzionális szint miatt? Ezt akartad mondani?
Én komolyan kérdeztem az indokot. Egyszerűen nem tudom elképzelni.
Itt ugye nem arról van szó, hogy néhány esetben vagy hogy bizonyos környezetben, hanem MINDIG. Ez olyan, mintha az Audi leszállítana 10000 autót kormány nélkül. Ott sem érteném a szitut.Nyilván a marketing felülírta a mérnöki protokollt, de ez hogyan lehetséges egy befutott, prosperáló, stabil cégnél?
-
hapakj
őstag
nyilván nem ez történt, meg valszeg fel van fújva. Teljesen más amikor egy pár ezres relatív steril teszt környezetből kiküldik a csomagot több milliós felhasználó bázisnak, akiknek a gépén 4-5 overlay megpróbál egyszerre belemászni a játékba.
Általában az ilyen dolgok mindig azoktól a cégekről hangosak akiknek nagy a felhasználó bázisa. Nvidia vagy Apple.
Nemrég volt dolgom, pár kisebb telefongyártó problémáival. Hát fogtam a fejem
Normal középkategóriás telefonnál vagy beakad a frissítés, vagy teljesen meg is brickeli a telefont, s kb alig lehet találni róla infót a neten -
#6
M0ng00se
őstag
ergoGnomik
#5
válasz
ergoGnomik
#5
üzenetére
bevallom, tenyleg szeretem
-
Abu kedvenc napja amikor lehozhat egy negativ hirt az nvidiarol
-
Settings - Game filters and Photo mode
Beállítások - Játékszűrők és Fotó mód
- elég globálisan kikapcsolni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
s a józan eszemet nem is használom 
- öööhmmm 
Új hozzászólás Aktív témák
Hirdetés
- Háztartási gépek
- Sorozatok
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Okos Otthon / Smart Home
- Milyen billentyűzetet vegyek?
- Véget vetne a hibrid magdizájnnak az Intel?
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Gumi és felni topik
- Call of Duty: Black Ops 6
- Xbox Series X|S
- További aktív témák...
- Csere-Beszámítás! Asus Rog Strix G731GU Gamer Noti! I7 9750H / GTX 1660TI / 16GB D4 / 512 SSD
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- ÁLTALÁNOS IGAZGATÓHELYETTES tábla
- 13-14" Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- Xiaomi Redmi A3 64GB Kártyafüggetlen, 1Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest