- iPhone topik
- Samsung Galaxy Buds3 Pro - szárat eresztettek a babok
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Xiaomi 15 - kicsi telefon nagy energiával
- Yettel topik
- Garmin Instinct – küldetés teljesítve
- Android alkalmazások - szoftver kibeszélő topik
- Magisk
Új hozzászólás Aktív témák
-
kisfurko
senior tag
Pedig igaza van. Grafika programozásban baromira nincsenek semmilyen komponensek, meg mindenféle csoda dolog. Van az API és slussz. Létrehozol erőforrásokat, piszkálod azokat, állapotokat állítasz be a rajzolás előtt, meg rajzolsz. Viszont nem lehet mindent tetszőlegesen kombinálni. Pl. nem rajzolhatsz lockolt pufferből, bizonyos beállítások nem kompatibilisek egymással a textúra-mintavételezőben, a ROP-ban stb. Ugyanígy a shader program sem írhat akárhogy, vagy olvashat máshogyan, mint ahogyan deklarálva van a bemenet. Figyelni kell, hogy az előző fokozatból jövő adatok tényleg úgy nézzenek ki, mint ami kell. Amikor sokezer dolgot rajzolsz ki, majd minden dologhoz egyedi textúra-mintavételező, ROP és egyéb kombinációval, és mindez képenként változik, na akkor teszteljed le. A DirectX runtime jelenti az összes érvénytelen kombinációt, no de csak debugnál. Ekkor, természetesen egészen más sebességgel fut, mint release libraryvel. Csomó időbe kerül, amíg rájössz, hogyan lehet reprodukálni debug alatt, ha rájössz. Szóval totál kiszámíthatatlan. Elég egyszer egy rossz kombinációt beadni, a legközelebbi device resetig jöhetnek a mellékhatások. Ha szerencséd van, a következő state change elmúlasztja. Hidd el, a legjobbaknál is becsúszik egy ilyen hiba.
Beszélsz itt automatizált tesztekről egy interaktív programnál...
Aztán vegyük a teljesítményt. Kb. nulla információ van arról, hogy milyen állapotváltás mennyi időt igényel, vagy hogy mi az, amit még meg tudsz változtatni némi késleltetés nélkül. Többnyire próbálgatással deríted ki, hogy milyen paraméterek alapján sorrendezd a rajzolásokat, ami persze egy másik kártyán megint más lehet. Aztán néha kiderül, hogy ami az API leírása szerint gyorsabb lenne, az nem gyorsabb
Aztán vannak olyan dolgok is, hogy a gyártó profilere egyszerűen szétfagy, pedig a saját profiler driverével megy. Úgy igen nehéz teljesítményre gyúrni... -
konkrét példákat hozott az ipse a cikk szerint, milyen hibáik vannak. api szabványok megsértése, shaderek nem megfelelő implementációja miatti szükségtelen többletterhelés. ez azért némiképpen komolyabb, mintsem egy nagyon komplex programról elmondani, hogy egyes, előfordulási valószínűségét tekintve marginális helyzetekben vektorhibák vannak a megjelenített felületen.
-
Goose-T
veterán
A játékfejlesztő játékot fog fejleszteni ezután is, továbbra sem kell polihisztornak lennie. A játékmotor-fejlesztők kapnak több teret ezután az optimalizálásra - arra az optimalizálásra, amit eddig a driverfejlesztők végeztek nagyon nem hatékonyan és utólag dolgozva (új driverrel végre +10FPS x játékban, meg ilyesmik). Most végre a helyére kerülnek a feladatok:
* driverfejlesztők: összekapcsolják az alacsony szintű API-t a hardverrel
* motorfejlesztők: hatékonyan optimalizálják a saját, jól ismert játékmotorjukat a különböző architektúrákra az alacsony szintű API lehetőségeinek kiaknázásával
* játékfejlesztők: na ezek ezután is tök ugyanazt fogják csinálni, mint eddig, fejlesztik a játékot a választott motorra. -
Szerintem az a gond, hogy a grafikus driverek mára egy-egy hatalmas bloatware-ré nőtték ki magukat. De ez nem a fejlesztők, hanem a hagyományos grafikus api-k koncepciójának hibája, hogy mindent meg akar csinálni helyetted, s ezeket a driverbe kell implementálni. Ugyan egy egyszeri fejlesztőnek nagyon jól jön az egyszerűen programozható felület, s nem is érdekli mi van mögötte (bloatware), de egy techbuzi stúdiónak ez korlátozó tényező, mert egy fekete dobozt nagyon nehéz debuggolni vagy rájönni hogy hol van a szűk keresztmetszet teljesítményben. Illetve ott vannak a funkcióbeli hiányosságok is, lásd használható multithreading CPU-ra.
A techbuzik problémáinak megoldására a driverben a grafikus api rétegét radikálisan le kell vékonyítani, s fejlesztő kezébe adni a kontrollt. Ezzel kvázi drivert írnak a fejlesztők, de azért ez nem teljesen igaz, hisz a driver megmarad, csak alacsonyabb szintű a hozzáférés.
A "hibás játék" szerintem szimplán a jelenleg elterjedt grafikus api-k problémáira utal.
Persze más kérdés, hogy mi lesz a nem techbuzi fejlesztőkkel, mert nekik az új api inkább bosszúságot okoz.
Új hozzászólás Aktív témák
Hirdetés
- LG 34GS95UE - 34" Ívelt OLED / QHD 2K / 240Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- BESZÁMÍTÁS! ASUS ROG STRIX B550-F GAMING alaplap garanciával hibátlan működéssel
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest