Javítja-e a "greedy" opció az Intel driver teljesítményét?

X, Wayland, Mir

A Intel chipek illesztőprogramja jelentős átalakításon megy keresztül. A driver most már rendelkezik megfelelő memóriakezelővel a Graphics Execution Manager (GEM) képében, már van upstream kernel mode setting támogatás és hamarosan érkezik az új 3D komponens, a Gallium 3D is. Az ezeket az újdonságokat hozó munka során regressziókkal és stabilitási problémákkal kell számolni, amelyek többféleképpen - grafikus hibák, lassú 2D teljesítmény, stb. formájában - jelentkezhetnek.

Míg az újabb - 2009 első felében érkező - Linux disztribúciók felhasználói belefuthatnak ezekbe a problémákba, addig a disztribútorok megpróbálnak e "problémás" időszakra különböző driver konfigurációkat ajánlani vagy alapértelmezetté tenni. A Canonical például azzal a gondolattal játszik, hogy a nemsokára megjelenő Ubuntu Jaunty-ban alapértelmezetté teszi a xorg.conf "Device" szekciójában az Option "MigrationHeuristic" "greedy" opciót: 


Section "Device"
[...]
        Option "MigrationHeuristic" "greedy"
[...]
EndSection

Az Ubuntu ettől az opciótól javulást vár. De vajon hoz-e ez a beállítás valamiféle plusz teljesítményt? A Phoronix egyik cikkében ezt tesztelte le. A cikk elolvasható itt.

--

(A saját tapasztalatom az, hogy a "greedy" opció komoly mértékben képes a desktop teljesítményt növelni. Látszólag nem csak az ablakok mozgatásában, görgetésben, stb. segít, hanem a glxgears-ben is hoz valamit (igen tudom, hogy a glxgears nem benchmark). Legalábbis a saját hardver- és szoftverkörnyezetemben pozitív tapasztalatokról tudok beszámolni. Aki Intel hardverrel rendelkezik, újabb disztrót használ és gyengébb videó teljesítménnyel találja magát szemben, érdemes egy tesztet végezni a "greedy" opció beállításával.)

( guska v | 2009. 04. 20., h – 08:55 )

+1

Előtte kipróbáltam már a Option "AccelMethod" "uxa" -t de nekem teljesen fagyott tőle a gép, viszont a "greedy" hatására a GM965/GL960 kártyám szinte újra hozza a régi teljesítményt.
Guska

Ugyanez itt is. UXA-val (ez még erősen kísérleti kód) nem volt stabil a suspend/resume. EXA-val stabil (50-ből 50-szer sikeres), de lassabb volt pl. a görgetés böngészőben mint Intrepid-del. EXA + greedy-vel minden ugyanolyan mint az Intrepid-ben, gyakorlatilag nem látok különbséget és a suspend/resume is atomstabil.

--
trey @ gépház

A múltkori próbálgatás után tegnap végül frissítettem a laptopomat, lesz-ami lesz alapon, de sajnos az xorg exa+greedy beállítás nem hozott javulást a telepített rendszeren az új intel driverrel. Feltettem PPA-ból a régi drivert, így érzésre kb olyan gyors/pattogós a compiz, mint 8.10 alatt volt, a glxgears viszont továbbra is jóval kevesebbet mutat (ez mondjuk nem izgat annyira, ha más gond nem lesz, akkor marad a jaunty, a következő kiadásban meg remélem lesz már egy stabil UXA).

( kikke | 2009. 04. 20., h – 10:06 )

Ha nem írtál volna róla a blogodban, nem is tudtam volna róla. Megerősítem, valóban pozitív hatása van: nem szaggat a görgetés Firefoxban. Big THX!

( tompos v | 2009. 04. 20., h – 10:27 )

Kicsit mas tema:

HP nc6120, egyszercsak elkussolt, es nem ad ki hangot semmi aron. Nem tudom mihez kotni, de lehet, hogy egy frissites, vagy vmi okozta.

Egy arva hibauzenetet nem talalok. Otlet, hogy mi lelte? Uptodate Jaunty van rajta. Mas nem tapasztalt hasonlot?

tompos

( enpassant v | 2009. 04. 20., h – 11:01 )

Nekem nem lett gyorsabb, nem is nagyon lehet a 690-es glxgears-t fokozni :-)
Viszont most stabilan működik a felfüggesztés és a hibernálás (EXA + greedy együtt).
Köszi az infót!

Oh yeah thx

EXA: stabil suspend/resume, jó dual beállítások, foslassú compiz
UXA: fagy suspendnél, nem lehet dual monitorra simán beállításokból átmenni, okés compiz
EXA+greedy: intrepid compiz sebesség és stabil suspend, jó dual beállítás

GMA950

ez a greedy megváltás a javából, még emlékszem az intrepid alpha6 xorg.conf-jába is manuál kellett berakni h (compiz nélkül is) ne szaggasson az FF scroll.

mégegyszer kösz

"UXA: fagy suspendnél, nem lehet dual monitorra simán beállításokból átmenni, okés compiz"

Nálam fagyni nem "fagy", mert működik alatta az OS suspend-ből visszaállításkor, de resume-kor blank képernyőt kapok. De a Magic SysRQ + REISUB működik akkor is tehát a kernel megy. Persze ez így használhatatlan.

--
trey @ gépház

"nem is nagyon lehet a 690-es glxgears-t fokozni"

Nem is nagyon kell, mivel SEMMI különbséget nem fogsz tapasztalni akkor sem ha 1000 fps-t kapsz glxgears-el. Már rengeteg helyen leírták, hogy a glxgears nem benchmark, de tessék, olvasd el te is: Problem: glxgears has low FPS

( barii | 2009. 04. 20., h – 11:58 )

hmm, rosszat senkinél nem csinál, jót sokaknál. miért nem default?

Szerintem azért, mert ez egy workaround. Bizonyos dolgokat kikapcsol/megkerül, nem megold. És főként azért, mert nem mindenkinek kell. Megfelelő állapotú driverrel nem lenne rá szükség. Szerintem a disztribútor feladata (nem az upstream projekté), hogy ezt bekapcsolja vagy sem, miután látja, hogy az általa összeállított disztribúcióban ennek helye van.

--
trey @ gépház

"Akinek nem kell, annál elront valamit?"

"The migration heuristics deal with how pixmaps move to video memory, but when operating under the greedy mode, some acceleration routines are avoided, where some of the current performance problems seem to be taking place."

Ebből nekem az jön le, hogy úgy kerüli meg a problémát, hogy bizonyos gyorsító rutinokat - amelyek jelenleg teljesítmény csökkentést okoznak - mellőz. Ebből következhet az, hogy ahol egyébként nincs probléma és letiltasz bizonyos gyorsító rutinokat, ott lassulás jelentkezik. De én csak találgatok, nyilván tesztelni kéne olyan vason amin nincs probléma.

--
trey @ gépház

Az RC ciklus is arra való, hogy a fennmaradó hibákat kijavítsák. Ha nem arra lenne való, akkor release-nek hívnák. Valószínűleg ez nem _direkt_ így van (hogy veled vagy velem kiszúrjanak). Mostanra találtak valami megoldást, leteszteltetik a felhasználókkal. Láttunk már olyat is a világtörténelemben, hogy RC2, sőt. Nyilván szerencsésebb lenne ezeket minél előbb kitalálni, de láttunk már olyan release-t is, ami mellé az errata jócskán hosszú volt és a hibákat csak a következő szerviz kiadásban javították.

--
trey @ gépház

( tomsolo | 2009. 04. 20., h – 12:57 )

elvbe a pageflip és a triplebuffer is javítja csak sűrűbben fagy vagy nem megy :)

No rainbow, no sugar

( hege | 2009. 04. 20., h – 13:01 )

elég rosszul jött ki ez a kiadási időpont, ha két hónapot vártak volna vele, akkor lenne egy stabil kernel + stabil xorg páros, a .30-rc3 -ba is be fog kerülni jópár drm/i915 patch.