- Fotók, videók mobillal
- iPhone topik
- Google Pixel 9 Pro XL - hét szűk esztendő
- Mobil flották
- Samsung Galaxy Z Flip7 - kis fogyás is sokat jelent
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Macrodroid
- MIUI / HyperOS topik
Új hozzászólás Aktív témák
-
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.
-
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.
-
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...
-
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. -
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Xiaomi 14 512GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest