- Samsung Galaxy Z Flip7 - kis fogyás is sokat jelent
- Magisk
- HMD Skyline - jó szerelés
- Ez össze van rakva - Segway Ninebot F3 Pro
- Fotók, videók mobillal
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- iPhone topik
- MIUI / HyperOS topik
- Samsung Galaxy S25 - végre van kicsi!
- Vivo X200 Pro - a kétszázát!
Ú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. -
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
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.
-
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.
-
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.
-
#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. -
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?
Új hozzászólás Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Lenovo ThinkPad X1 Carbon G8, i7-10510U, 16GB, 1TB SSD, 4K kijelző + WWAN (ELKELT)
- Eladó ANDROID TV box 4/64GB tárhely / 12 hónap jótállás
- Apple iPhone 14 128Gb Kártyafüggetlen, 1Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest