Unity 5.12 opravilo problém s výkonem OpenGL

K čemu hry, potřebují Unity? Myslel jsem, že výkon her ovlivňuju ovladače a X.org server...

No a vykreslovat plochu za tou aplikaci bude co?

a jde treba u starsich pocitacu shodit Xka a pustit si hru pomoci prikazu? treba 0.a.d. se mi trochu seka, tak jestli by to nepomohlo setrit vykon... driv to slo shazovat snad pomoci ctrl+alt+backspace, ale spoustet hru jsem nezkousel, a navic uz ten prikaz v ubuntu nefunguje

to nebude tim, 0ad se mi seka na Phenomu 3,4GHz a geforce 560ti (s blobem od nvidie) a to i prestoze bezi z SSD!!! :D

uz me opravdu nenapada co by mohlo limitovat vykon, takze to asi bude v samotne hre...

Asi nějaký bug, mám slabší PC a jede mi to hezky plynule. Možná nahlásit, nebo se podívat, jestli někdo nemá podobný problém.

Dá se spustit další X+podpora zvuku atd.

NO ale ve zprávičce byly uvedené hry typu DOOM3 atd. a tam se žádná procha vykresovat nemusí a jestli se vykresluje, tak si myslím, že to je nějaký engineersky bug, protože to musí hrozně zatěžovat procesor a grafiku a zbytečně, protože stejně když vám hra běží ve Fullscreenu tak tu prochu nevidíte.

Taky to nechápu, Unity je přeci jen jakýsi plug-in pro GNOME, ne?

Unity (3D) je řešen jako plugin pro Compiz, Unity 2D je pak řešeno jako aplikace (unity-2d-panel a unity-2d-shell), které lze spustit s víceméně libovolným WM (ale pro jeden - na název si nevzpomenu - je přichystaná integrace). Obě varianty Unity používají aplikace Gnome (například gnome-control-center).

Kompozitní manažer plochy žere 3D výkon, protože veškeré renderování beží ještě přes něj (aby mohl provádět různé efekty). Proto pod Compizem, Unity, Gnome Shell and Windows Aero máte většinou znatelně nižší 3D výkon. Některé manažery vypínají compositing u fullscreen aplikací (ono to ale zase má jiné problémy, takže úplná výhra to není), takže tam se potom ztráta výkonu neprojeví, pouze u běhu v okně.

Já osobně pracuju pod Gnome Shell, ale na hraní mám vytvořený další uživatelský účet ve kterém mám nastavený prostředí Gnome Fallback (v podstatě staré Gnome 2). Rozdíl ve výkonu je poměrně propastný. V testech na Phoronixu jim ale takové rozdíly (jako pozoruju já) moc často nevycházejí, takže se to zřejmě liší na různých kartách, různých driverech, různých hrách, atd.

Ty jo to jsem nevěděl, daj jste mi fajn tip na zvýšení výkonu. Děkuji.

Spíš se podívejte na QGameX

Díky za dobrý tip

Ve Windows se Aero nepoužívá, když běží 3D fullscreen aplikace. Jaké by to mělo mít problémy?

To záleží na nastavení aplikace/hry, může vám umožnit provozování oběma způsoby. Pokud se Aero nevypne, tak se mnohem lépe přepíná mezi programy (méně přeblíkávání, hra se nemusí minimalizovat ale může běžet jakoby "za" jiným aktivním oknem), ale zase je nižší výkon. Co jsem viděl tak to umožňoval nastavit třeba Heroes of Newerth. Standardně se Aero asi vypíná, jak uvádíte, ale není to jediný možný způsob. Nuceně se dá vypnout v nastavení aplikace pod "Disable compositing" nebo tak nějak podobně.

Pro hry tam většinou problémy nejsou, ale pokud byste chtěl vypnout compositing i třeba pro přehrávání videa ve fullscreenu (kvůli vyššímu výkonu), tak narazíte, pokud si při tom zkusíte zobrazit nějaké menu. Teď už se musí manažer rozhodnout, jestli znovu zapnout compositing nebo ne. Při zapínání většinou věci různě problikávají a není to příjemný. To byl třeba problém v Compizu, pokud jste si zapnuli "unredirect fullscreen windows".

Ve Windows běžící fullscreen 3D aplikace přebírá kontrolu, Aero se nepoužije. Přepínání mezi fullscreen 3D aplikací a čímkoliv běžícím na desktopu chvilku trvá. V případě přepnutí na desktopovou aplikaci musí WDM naládovat do karty shadery a pár bitmap. V případě přepnutí na 3D aplikaci se těch zdrojů přesouvá z RAM do video RAM ještě daleko víc.

Fullscreen playback videa nepotřebuje vypínat Aero, nijak by to nezlepšilo výkon. WDM nemá problém provést resize nějaké bitmapy na fullscreen, je na to velmi dobře stavěný.

Některé manažery jako právě Aero jej vypínají u fullscreen aplikací. Jaké jiné problémy to má ale nevím, něco konkrétního?

Že je výkon bez kompozite atd vždy vyšší, nemusí být vždy pravda. I když tomu tak většinou je. Zpravidla je to kvůli chybnému návrhu managera nebo jeho chybám.

Unity(plugin do Compizu) má určité problémy. Ví se o nich. Pracuje se na nich. Článek popisuje jen hotové řešení jednoho z mnoha problémů.

Řešení některých problémů není už vůbec triviální a a vyžaduje kooperaci s ostatními subjekty. (pomyslný strop open source řešení versus komerční subjekty)

Musím říci, že po nakouknutí pod pokličku testerům a vývojářům jsem byl příjemně překvapen. Nezbývá než čekat.

Snad čas, který stráví nad řešeními nebude tak dlouhý, aby jej překryl Wayland. Ale i tak, alespoň se někde zefektivní kód.

Podle mně začíná mít Ubuntu docela dost velké problémy kvůli tomu, že se tak moc vzdálilo upstreamu. Třeba v GTK už mají tak velké množství vlastních patchů, že vývojáři v upstreamu automaticky uzavírají bugy nahlášené z Ubuntu, protože už to nejde dál rozumně řešit.
Jakýkoliv patch navíc znamená hromadu problémů při rebuildech, backportech atd.
U Compizu to samé. Je to věc, kterou už kromě Ubuntu prakticky nikdo nepoužívá. Nelze se tedy divit tomu, že na něj ostatní projekty už neberou příliš ohled.
Kéž by Canonical raději dal ty vývojáře, kteří řeší tyto rozdíly oproti upstreamu (a že to sežere opravdu hodně workforce), na vývoj přímo v upstreamu. Osobně si myslím, že k přiblížení musí dřív nebo později dojít.

Vyvoj musite mit pod kontrolou. Upstream pod kontrolou nemate. Tam poslete patche a oni to "nekdy" zaradi nebo taky nezaradi pokud zarazeni komunita neodhlasuje. Vynalozite svoji energii a mate "mozna" vysledek. Kdyz si to forknete tak vysledek mate "jisty".

Kazdy projekt musi mit kvalitni vedeni. Opensource funguje na principu komunity - kazdy tam ma stejny hlas. Zkuste stavet barak tak ze nechate rozhodovat zedniky jak se to postavi.

Je zase zavádějící. Opravi se jeden z více problémů. Ale nikoliv celý výkon!