60fps Linux vs. 60fps Windows

Pár hete (lehet, hogy több) volt itt (is) egy olyan hír, amiben a futási teljesítménye alapján összehasonlítottak egy SteamOs alatt futó játékot egy windowsos verzióval, ahol a SteamOs-es jelentős teljesítménnyel elmaradt. Én már akkor sem értettem a dolgot, főleg hogy az összes oldal ugyanarra a tesztre hivatkozott, pedig szinte bárki megnézhetné élőben, hogy nincs igazságtartalma.
Még akkor megjegyeztem, hogy megnézem magamnak közelebbről a tényeket, főleg mert nem úgy akartam beszélni valamiről mint egy elvakult fanatikus. Az mondjuk már egy tény, hogy semmiféle teljesítménycsökkenést nem érezni futás közben, viszont látni akartam a tényleges adatokat.
Az megjelen cikk és az én próbám között eltelt hosszú idő oka (mert tesztnek túl egyszerű), az egyéb elfoglaltságokon túl, hogy nekem csak egy kiherélt winem van offline játékokra, így felrakni sem volt egyszerű olyat ami mind a két rendszerre megjelent, és nincs rajta DRM. Végül egy nem túl elegáns módszerrel oldottam meg. Mivel legálisan megvan a Portal 2, minimális lelkiismeretfurdalás mellet szedtem le egy warezwin példányt is belőle. Megoldhattam volna úgy is, ahogy korábban többször; Wine alatt Steammel leszedek egy windówszos példányt is, Steamet offline-ba rakom, végül ezt az egészet átmásolom a win partíciómra és úgy indítom el. Most ehhez nem volt sok kedvem, mint látszik leírni is hosszú, duplaannyi hely és idő kellett volna hozzá, a végeredménybe pedig semmit nem számított volna bele.
Nos;

Mind a két rendszeren ugyanazon beállításokkal, mindent maxra húzva indítottam. Azért, hogy ne csak buta fehér falakat kelljen renderelni, főleg az alsóbb területeket néztem, pl. ott ahol tüzek és egyéb fényeffektek is előfordulnak. Wheatley pályáin már vannak extrább eszközök is, fénypadló, lebegtető izék, zselék (most egyik neve sem jut eszembe), mindegyiknek van számítási igénye, emlékszem megjelenéskor hogy leterhelte az akkori nagyongyenge 5700-as Nvidiámat, sok effekt meg sem jelent.
A lényeg;

A Portal2 gyárilag fixen be van állítva 60fps-re. Elvileg ennél csak alacsonyabb lehet. Persze fpsmax 1000 parancsra ez változhat. Gyakorlatban akkor sem nagyon tér el tőle, úgy tűnik a Source engine erre van belőve. Ezt máshol is írták.
Amit én használtam az a cl_showfps 1 és a cl_showfps 2 parancs, ami szépen kiírja a bal felső sarokra az aktuálisan használt értéket. Először még akartam logolni a dolgot, de...
A cl_showfps 1 sok értelmeset nem mutat, mindkét rendszeren végig 60-at láttam, illetve kicsit mozogtak számok, talán 59-61 között, ez nem látszott rendesen.
A cl_showfps 2 már kicsivel informatívabb, nem csak azért mert a pálya nevét is kiírja :)
Itt azért már előfordult némi változás, az érték felment akár 75-80-ra, de ugyanúgy láttam 34-et is. Néhol teljesen értelmetlenül csökkent az érték mondjuk az üres padlót bámulva, vagy gyorsult az areiaľ és faith plate használata közben.

Ami a legfontosabb; Pontosan ugyanakkora értékeket láttam mind a két rendszeren!

Tehát...

*Mivel az értékek mozgását a Source színekkel is jelzi, így elég könnyen észrevehető volt az fps változás. Mivel ezt a játékot már kívülről-belülről ismerem, ezért arra már amúgy sem nagyon kellett figyelnem.
**Ha valaki szintén ennyire szeretné a Portalt, akkor ajánlom a Portal Stories Mel modot, nem story módban igen izzasztó fejtörőkkel van telerakva.
***Ez az első teljesen touch mobiról írt blogposztom :) (Márha küldésnél nem veszik el.) Emiatt bocsánat ha óhatatlanul is hagytam benne elütéseket. Ezeket most többnyire javítottam.

( Mcsiv v | 2015. 12. 28., h – 18:41 )

source/goldsrc esetén developer 1 (illetve az általad említett fps_max) szükséges az fps limit kikapcsolásához, illetve a vert./horiz. szinkronizáció lehet még a ludas a 60-as fps cap esetében.
A random érthetetlen fps értékek pedig a source engine sajátosságai. A BSP formátum amit használnak a goldsrc óta (Binary space partitioning a hivatalos neve) és a quake-ből örökölt dolog úgy működik, hogy terekre osztja a teljes map-et. Ezen terek között vannak meg azon információk, hogy melyik térből melyik tér látszódhat még így csak ezek a részek rajzolódnak ki. Így egy üres padlót bámulva bőven megeshet, hogy a fél map kirajzolásra kerül mivel semmilyen egyéb occlusion culling nincs alkalmazva (a backface culling-ot leszámítva). Ez még alapvetően nem is lenne probléma szerencsés esetben, de mivel semmilyen Z hiearchy nincs a rajzoláshoz, azon felül hogy a teljes geometria átmozog a videókártyán (kissebb baj) az egész map kirajzolásra is kerülhet (nagyobb baj, mert elviszi mind a fill rate-et, mind a memória sávszélességet).

// Happy debugging, suckers
#define true (rand() > 10)

Igen, erről olvastam egy oldalon, ami most pont nem érthető el. Portalnál amúgy is van egy kis kavarás, pont a portalok miatt. Azt hiszem a Narbacular Droopsban volt először úgy megoldva, hogy a két egyszerre látható területet nem kétszer rajzolták meg, mint pl. a Duke Nukem 3D-ben a tükröknél. A Valve pedig felvette őket technológiástul, belehackelték a Source-ba, majd lett a Portal. Vicces, hogy a portalok körüli effektek nagyobb terhelést rónak a kártyákra, mint maga a portal használat. Jó, persze, ott valószínűleg csak pár vektorirányról van szó.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Mind a Narbacular, mind a portal ugyan úgy működik mint a tükrök. Lényegében két különböző kamerából renderelik a teljes scene-t újra, ezért esik meredeken az fps mikor portal-t nyitsz, nem az effekt miatt. Őket pedig nem a technológia miatt, hanem pont az ötlet miatt vették meg kilóra;)

// Happy debugging, suckers
#define true (rand() > 10)

Lehet, kopnak az emlékeim :)
Portal nyitáskor semennyire nem esik az fps. Mai géppel már nem, de régivel érzékelni lehetett a gyorsulást amikor lejjebb vettem az effekteket, a portalok körüli (talán) flare nélkül semmit nem akadozott, míg azzal igen.
Viszont a light bridge és az excursion funnel okozott némi ideiglenes fps vesztést mind a két rendszeren.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

( bbandi | 2016. 01. 01., p – 15:47 )

Javíts ki, ha valamit félreértek, de ezzel csak azt bizonyítottad, hogy a Portal 2 nem ütközik VGA limitbe se windowson, se linuxon, ezzel nem lehet teljesítményt összehasonlítani. A Portal2-nek amúgy is nagyon alacsony a gépigénye, lehet az NV5700-at megizzasztotta, de igazából az is csoda, hogy futott rajta, az már akkor 8 éves volt.

Ráadásul a valve játékok valószínűleg kivételesen jó minőségű portok, érthetően, a steamos miatt ebbe komoly energiát fektettek. Ha jól sejtem erre a cikkre hivatkozol az elején:
http://arstechnica.com/gaming/2015/11/ars-benchmarks-show-significant-p…
Sajnos a Metro/Mordor port minősége sokkal közelebb áll az átlaghoz ahogy hallottam. Sőt, talán pont a Metróról hallottam, hogy néhány effekt hiányzik linuxon, mert túl bonyolult lett volna átírni OpenGL-re.

Mindezektől függetlenül, hamarosan elstartol a Vulcan API (a Khronos által továbbfejlesztett AMD Mantle), ami állítólag legalábbis pariban lesz a DX12-vel, ez adhat némi reményt a Linux (Mac) gamingnek. Szerintem részben ezért is vett vissza a Valve a steamos fejlesztés tempóján, erre várnak.

Kijavítalak, nincs igazad. Azt bizonyítottam, hogy nem futnak alacsonyabb teljesítménnyel a játékok Linux alatt, ahogyan az arstechnika cikke alapján sok oldal állítja. Midegy mennyire alacsony a gépigénye, attól még valós értékeket mutat a futtatása. Linuxos telefonomon 70 fps körül fut a Half-Life 1. Annak is alacsony a gépigénye, viszont a vele egyidős Tomb Raider 1 kb. 30-ra képes. A port minősége ugye;
A Mordor egy hulladék port, ami valszeg egy sima wine-t használ, így annyira releváns mintha Playstationt emulálnánk egy Mac-en. A realtime DX to OGL konvertálás sokat kivesz a processzor teljesítményéből, és nagyjából bármelyik átlag Linux user képes lett volna ugyanezt ugyanígy elindítani az ostoba 'portolás' cimke nélkül is. A Metro-ról viszont nem ezt hallottam. Amit meg tudok majd még nézni az a Witcher 2 és talán az utolsó, ha abból is kijön a natív Linux port, ezek nem Valve termékek. Nem várok gyengébb eredményt. Visszaemlékezve, az Unreal meg a Quake motoros cuccokkal sem voltak annak idején gondok, pedig hírben sem létezett még a milliókat Linuxgamingbe ölő cég, vagy akár a Steam.
No meg jelenleg az OGL többet tud mint a DX, így eleve értelmetlen sírni azért mert az utóbbi nincs Linux alá. A Valve kommunikációja a témában a nulla felé konvergál, semmit nem tudni milyen tempóban halad a fejlesztés. Vissza biztosan nem vettek belőle.

☼☆♫♪♫♪☆☼
AGA@
Fork portal és az egyik logóm :)

Jó, akkor sarkítok: Hasonlítsuk össze egy La Ferrari meg egy Golf sebességét autópályán: Mivel mindkettő tud 130-cal menni, a Golf nem lassabb, mint a La Ferrari.

Oké, akkor a Mordort vegyük ki a képletből, mert az pocsék port, van ilyen, de ahogy hallottam a Metro elég jó, talán átlag felettinek is lehet nevezni, és mégis rosszabbul fut linuxon (megtaláltam hol olvastam a kevesebb effektről: http://prohardver.hu/hir/nyomtatobarat/igy_nez_ki_ibuypower_steam_masin… ). Márpedig az átlagos port minőséget figyelembe kell venni szerintem - hiába közel azonos minőségű az alsó rétege az SW-nek, ha az aalkalmazás általában vacak rá.
A witcher 2 amúgy érdekes lehet, korához képest elég nagy a vga igénye abból ítélve, hogy pont annyira süvített a vga-m hűtése, mint a witcher 3 alatt :) - viszont arról is olyanokat lehetett hallani megjelenéskor, hogy pocsék port.

OGL meg lehet többet tud, mint a DX, ehhez nem értek, mégis minden (elsősorban) DX-re készül - tavaly vagy tavalyelőtt jelentek meg nagyon jó cikkek arról, hogy miért nagyon rossz OGL-re fejleszteni (azt hiszem pont egy Valve fejlesztő indította). Ezért bizakodom a Vulkanban, sokszor olvastam róla, hogy ezeknek a problémáknak a nagy részét javították, meg hogy windowson is jobb lehet képességeiben/teljesítményében mint a dx12, viszont multiplatform, szóval van rá esély, hogy megtöri a DX (majdnem) egyeduralmát.

IMHO amíg más grafikai API-t használ minden windowson meg mindenhol máshol, és a windows lefedi a piac több mint 90%-át, addig a nem-windows PC gaming gyengébb lesz.

A sarkítás sem sikerült, mert mondjuk inkább két La Ferrariról van szó. Az egyiken Bridgestone a másikon Michelin gumi van, ugyanarra képesek.

Az a két kép ott ugyanaz, az egyik DX9 a másik DX11 beállítással készült. Olyan nem létezik, hogy pixelre pontosan ugyanoda áll valaki egy újraindítás után. Attól még lehet igaza amit leírtak, de az a cikk ugyanannyira nem bizonyít semmit mint az Arstechnica-é, így kétséges.
Mindenesetre megnézem a Metro-t is ha nem lesz drága, sajnos csak a sima van meg, és csak a Redux verzió fut natívan Linux alatt. No meg annyira nem köt le, ez már mellékes.

Fejleszteni sok mindenre rossz sok ember szerint. Pont a grafiakai dolgok azok, ahol a lusta, nem kreatív designerek azon szoktak sírni, hogy milyen nehéz az életük a korábbi kényelmes legózáshoz képest. AMD-ben meg semennyire nem bízom. Örülök, hogy léteznek, elég rossz lenne a félhasználóknak egy konkurencia nélküli két szereplős piac, a mostani évüket elnézve viszont még csoda, hogy léteznek.
A DX meg a win gaming egyeduralma már évek óta nem létezik. Ugye DX-et csak win és Xbox használ, míg OGL-t minden más. Itt már nem csak az asztali gépek számítanak más oprendszerrel mint az OSX/Linux, hanem a többi konzol, az androidos cuccok, vagy bármi más amire a jövőben fejlesztenek.

Nem vagyok én sem elégedett. Pl. ott a Talos Principle. Optimust technológiát nem támogatják Linux alatt, ostoba, elavult workaroundot mutogatnak megoldásként, ami még rosszabb mint amit a rockstarék csináltak a GTA4-gyel mikor az övék sem támogatta ugyanezt, merthogy ott öt év alatt azért összejött a patch, igaz az windows alatt. A Ubisoft, a Square Enix, az EA még csak nem is gondolkozik abban, hogy más rendszerre is elkészítse a cuccait. Bár rosszul hangzik, de szerintem akkor lesz majd tényleg elterjedt ez a gaminglinux vonal, ha megjelennek a torrentoldalakon a linuxos változatok is. Ez azt jelentené, hogy van rá igény.

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

( turul16 v | 2016. 01. 02., szo – 20:36 )

Az emlitett cikban a legfurcsabb az volt, hogy CPU testen is lassabb volt a Linux,
ami egy eleg valoszinutlen dolog.
Az energia gazdalkodasi, vagy orajel tuning dolgok elterhetnek alap beallitasoknal,
Mindketott maxi energia pocseklasra, es turbo engedelyezesre
veve nem kene elterest mutatni.
Regen win nagyon szar volt tobb magra utemzesben, valoszinuleg ezt mar megoldottak.
Regi Linux kernel nem kezelte az uj intel energia gazdalkodast,
ez is evek ota megoldott dolog.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.