OpenGL-es 3D gyorsitott WM-ek

 ( carlcolt | 2018. október 17., szerda - 18:36 )

Szeretnem, ha felsorolnank, hogy igy 2018 vegere mely X (Wayland, Mir, etc.) alatti Linux wm-ek es desktop envek dolgoznak GPU-bol OpenGL-lel (nem XRender, nem CPU-s render).

(szemelyes indoklas: lassan megint kell egy gep amin Linux van nekem. Es nem akarok se Unity-t, se GNOME-ot hasznalni.)

Amirol en tudok:

GNOME3
KDE - kwin
Compiz (ez amugy van meg, vagy deprecated? a 0.8 vagy a 0.9-et kell nezni?)
Unity (compiz?)
XFCE - xfwm (?? ez legutobb mintha csak XRenderes composite-ot tudott volna)
openbox/fluxbox/etc. (???) + compton? (meg ez amugy stabil vagy ilyen alapdolgok hianyoznak belole meg, mint a vsync pl.?)

Ki mit tudna hozzatenni, ahol biztos megy a latest-en, es ki tudna megerositeni, hogy hol nem megy? Minden info segit. Koszi

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

AFAIK mindegyik említett megoldásnál a Compiz van a háttérben.

DE:
Nem tudom miért kell neked hogy konkrétan GPU-val csinálja a dolgait, mindenesetre a több monitoros felállásnál már nem lesz olyan gördülékeny (értsd: nem fog működni) a dolog, az tuti.

--
zrubi.hu

Lol, tobb pelda sem compizos

Es tobb pelda is megy tobb monitorral, melyikre gondolsz, hogy elverezne?

Oké, valóban van amiben saját compositor is van, azonban ezek fícsörei elég "változatosak". Pl az általam jelenleg használt XFCE-ben is van, nagyjából árnyékot tud vetni, meg átlátszóságot.
De ezekkel legalább nincs gond :)

KDE saját effektjei kb amik fícsörökben felérnek a Compiz-hoz, ám tapasztalataim szerint csinján kell bánni az effektekkel, van ami egyből crash, van ami csak random összeomlást, X restartot okoz. Nyilván sok összetevős (WM, X, OpenGL, VGA driver, Kernel, Hardver) a dolog, éppen ezért is halad döcögősen gondolom.

Több monitoros setup esetén Compiz, Kwin, effektje közül igen kevés volt, ami ne okozott volna valamilyen problémát, így aztán jó ideje nem is kísérletezek ezzel, mivel a több monitor nagyobb igény mint az eye-candy.
Szóval marad a "default" - és problémamentes - árnyék és az átlátszóság ami pl XFCE-ben is van gyárilag. De ezeknek meg tökmindegy, hogy GPU vagy CPU csinálja.

--
zrubi.hu

A KWin szerencsére jó ideje elég stabil, az egykori karbantartójának a blogja (https://blog.martin-graesslin.com/blog/) pedig az egyik kedvenc forrásom.

Nem stabil. https://bugs.freedesktop.org/show_bug.cgi?id=103234 "KWin crashed when Alt+Tab-ing through open windows" -- oke, ez csak 2017 vegetol 2018 kozepeig volt nyitott bug, de egyreszt ez meg mindig benne van az LTS Kubuntu-ban es tarsaiban, masreszt egy ha par honappal ezelottig Alt-Tab-ra osszeomlik az ablakkezelo, akkor az nem "jó ideje elég stabil".

----------------------
while (!sleep) sheep++;

Ha jól látom, itt azért nem a KWin a hunyó, hanem a Mesa, illetve a disztribúciók, akik régi verziót szállítanak belőle (FYI Mesa 17.2.x is EOL, so it might be better to check if 17.3.3 and master still have the issue).

KDE. Esetleg Sway, ha AMD-d van vagy Inteled.

A fő gond(om) az Openboxszal meg a többivel az, hogy a toolkitek nem tudnak hidpi scaling-et. Qt meg GTK alkalmazások skalazodnak így-ugy (Qt jól, GTK szarul), de ha nem a teljes DE-t használod, akkor fájdalmas konfigurálhlni. Vsync sehol működik rendesen, elsősorban akkor, ha pl. videót játszol le (olyan tearing van legfrissebb KDE esetén is, hogy rossz nézni). A KDE kompozitor eleg rendszeresen összeomlik, ha alt-tabbal full screen opengl appokra valtasz oda-vissza (known bug). Ettől néha az egész felület meghal, és csak a reboot vagy X restart a megoldás.

Én összességében a KDE-t javaslom, ha Gnomeot nem akarsz. Főleg ha kell hidpi.

De kérdezz konkrétat, van itthon minden (nagy 4K monitor 125%-os optimális skalazassal 1080 Ti-vel, kicsi 4K touchscreen Intellel.. igazából most, 2018-ban az éppen optimális választás egy nagy 4K kijelző lenne AMD GPU-val. De persze ez kétévente változik, annyi időnként meg nem veszek gépet.)

----------------------
while (!sleep) sheep++;

Legjobb tudomásom szerint ez nem a WM, hanem a mellékelt kompozitor függvénye (amiből vagy szállít sajátot a WM, vagy nem). Én pl. a compton-t használom és OpenGL gyorsított az asztalom.

detto. bar be van kapcsolva mindenfele nvidia vsync workaround az openbox+compton wm-emben :D

Mik? Én csak a ForceFullCompositionPipeline opciót kapcsoltam be a metamodes-ben, meg az AllowIndirectGLXProtocol-ot tiltottam le. Van még, amit érdemes átállítani?

ezeket :D

Illetve nalam meg annyi, hogy a zart nvidia driver meg a compton valamiert osszeveszik a lightdm-el (ha nem lightdm-et hasznalok, akkor nem jelentkezik a problema), ha mar egy masik felhasznalo be van jelentkezve. Az elso belepeskor a kurzor korul mindig fekete negyzet van. Ha kilepek meg belepek ujra, akkor megjavul. Isten tudja mi a baja. De a kilep-belep megoldja igy nem nagyon forszirozom. Pedig az openbox autostart inditja a comptont. Lehet az a baj, hogy az uj felhasznalo session-je is elinditja a comptont, de akkor minden belepeskor jelentkezne, meg nem csak lightdm hanem minden dm eseten. De csak lightdm-nel van.

Szoval passz :D

Melyik greetert használod a LightDM-hez? Mert, ha a GTK3-ast, akkor nem vagyok meglepve.

Amúgy próbáld meg XDM-mel, annak nincsenek ilyen rigolyái.

Hat ezt mondtam, hogy massal nem jon elo. Amugy gtk3-as greeter igen. Es en sem lepodtem meg. :D
De mivel asszonnyal kozosen hasznaljuk a gepet es szereti ha szep kepek vannak, meg olyan kis csicsas minden, hat marad a lightdm. Ne viccelj az openbox-ba is fel kellett nyomnom a planket meg minden csicsa dolgot, tiszta mecos az egesz (skippy-xd meg minden szar) :D

GTK3-mal nem az a baj, hogy csicsás, hanem, hogy bugos és lassú. Meg az, hogy az API amit megálmodtak hozzá az egy konvulens szarhegy... (Mondjuk ez a kettesre is igaz volt, ha nem is ennyire, de az legalább gyors.) A GOM-ot aki kitalálta, nem volt normális. :/

Így van. Alapból egyik WM sem használ ilyen OpenGL gyorsítást, amelyik látszólag tudja, ott sem a WM funkciója, hanem a beépített kompozitoré. Compton vagy hasonló megoldás használatával bármelyik WM alkalmassá tehető erre.

Kivéve ha waylandes, mert akkor alapból kéne tudnia, a waylandes megoldások egyben kompozitorok is. Persze nagyban függ a drivertől is, ha pl. nincs DDR driver, akkor az OpenGL-ből szoftverrender lesz.


No keyboard detected... Press F1 to run the SETUP

A Waylandet mar leginkabb emiatt is kerulnem:

https://bugzilla.redhat.com/show_bug.cgi?id=1274451

Elegge kiderul belole, hogy hogy fejlesztik.

Idézet:
We've already made it very clear how to implement GUI applications that edit files as root by running the GUI as non-root, and using polkit to perform privileged operations.

Ööö...azt a polkitet kéne használni a privilege escalation-hoz, ami dzsuvaszkriptet használ a hitelesítési szabályokhoz? Asszem eztán sem próbálom ki a Waylandet...

LOL

ja, wayland -> kuka :(

Őőő, azért ennyire gyorsan ne írd le. Nem azt mondtam, hogy hibátlan, de ez is egy lehetőség. Ha nem futsz bele olyan igényekbe, amit nem tud kiszolgálni, hanem csak egyszeri felhasználó vagy, akkor bepróbálhatod, nekem pl. bejött. Nyilván, ha sudo-ként futtatott virt-managert használsz, akkor nem a te asztalod lesz.


No keyboard detected... Press F1 to run the SETUP

Megcsak nem is sudoerkent, hanem konkretan tobb kulon userkent tobb kulonbozo homedirrel (mikor Linuxoztam, tobb userkent futtattam bongeszot kdesu-val pl. vagy gksu-val).

Es erre jonnek waylandek, akik ugy csinalnak, mintha csak a logged in user meg a polkit altal kontrollalt uid=0 (sudoer/root) privilegium eszkalacio letezne, es meg ez utobbit is ilyan butan korlatoztak ilyen sokaig, ilyen hozzaallassal.

Meg eleve mi az a hozzaallas, hogy "majd mindenki atirja a rootkent futtatando programjat polkitesre"? Es ha a kedvenc particiokezelomet vagy portnyitogato guimat vagy http szerver guis valtogatomat 5 eve nem fejlesztik?

Ennel meg az X + compton is jobb, vagy X + kwin.

> Ennel meg az X + compton is jobb, vagy X + kwin.

A KWin X11 backendjét fagyasztották, az már nem kap sajnos új fícsőröket, legfeljebb hibajavításokat.

:((((

Annyira azért nem rossz a helyzet, csak sarkítottam. Az X11 backendet nem fejlesztik már elvileg, de a KWin jó része független a backendtől állítólag:

https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/

Próbáld ki a Trinityt. Aktívan fejlesztik, most már van saját kompozitora is (de nyilván megy comptonnal is), rengeteget tud és a Qt3-as toolkit egy mai gépnek meg sem kottyan, főleg, hogy még annak idején sem minősült annyira nehézsúlyúnak, kicsit többet evett, mint a Motif, viszont gyorsabb volt, még egy P3-ason is elment.

+1