GNOME Shell i bez 3D akcelerace

Phoronix uvádí, že GNOME Shell už lze používat se softwarovým renderováním. Je to díky vylepšením LLVMpipe v Gallium3D. Funkčnost je zásluhou Red Hatu, ale také Googlu a dalších.

4.11.2011 11:01 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[R]

Spustit alebo pouzivat?

Som sam, komu pride chore najprv urobit GUI, ktore potrebuje 3D akceleraciu a tu potom emulovat softwarovo?

[JoHnY2]

Neprijde mi to jako z principu spatny reseni. SW se prizpusobuje HW a 3D akcelerace je dneska bezna. U Gnome, ktery je zamereny na Linux je to mozna trochu nelogicky, protoze mame s 3Dckem dlouhodobe trable, rozhovne v porovnani s Win a Mac.

Podobnej krok jako Gnome dela i Qt 5, proste bez OpenGL/OpenGL ES nebude chodit GUI. Nakonec by me vubec neprekvapilo, kdyby se i Qt5 dockalo fallback reseni pomoci LLVMpipe, dost mozna i pod windows.

[JanM]

Tak tak, a bude to mít i pozitivní dopad na remote desktop, vrátíme se pěkně ke kořenům, tedy příkazové řádce. A ta frčí i po pomalé lince!

Tedy pokud mezitím někdo nedá do kupy VNC/nx/.. klienta s hw akcelerací.

[luky]

OpenGL akcelerace funguje i na vzdalenem Xserveru, nefunguje pouze direct rendering.

[pavlix]

To by OpenGL jako docela mělo fungovat i na dálku :).

[vencas]

Taky že funguje, a to potvrzuju z vlastní zkušenosti když jsem dokonce už před 5 lety úspěšně používal 3d program přes ssh+X11 (lokální 100MBit síť).

[Šangala]

OpenGL na to bylo od počátku navržené a i tak, že každý krok mohl být počítán jinde (rozumějme nejen na různých jádrech, ale na různých strojích).
Navrženým myslím, že se s tím počítalo, ne že to bylo automaticky podporováno.
To byl/možná je i jeden z důvodů, že sem tam nějaký program fungoval na obyčejné grafice za pár stovek, ale nefungoval na profi zařízení, a to často jen proto, že programátor neuměl používat vůbec nebo nesprávně (gl)Finish() a (gl)Flush(); a neměl možnost si to otestovat.

[Rezza]

No s Qt 5 slibuji, ze i pres LLVMpipe ma byt QML rychlejsi nez dnesni nepouzivajici OpenGL... Samozrejme zalezi, kolik se tam nahazi efektu, shaderu atd. :)

[R]

A pocita sa tam aj s tym, ze na pocitaci budu bezat nejake aplikacie? Alebo len desktop, ktory si zoberie 100% vykonu?

[D.A.Tiger]

mě spíš udivuje, že Gallium neumělo Software rendering už dřív. měl jsem za to, že když to zvládá MESA, tak ostatní konkurenční projekty si netroufnou zůstat moc pozadu....

[Yontalcar]

Gallium software rendering samozřejmě umělo, ale LLVMpipe neumělo OpenGL rozšíření GLX_EXT_texture_from_pixmap

[xm]

A nevytíží pak GNOME Shell naplno všechna jádra procesoru? LLVMpipe je úžasné, ale to právě díky tomu, že je schopné naplno využít pro renderování OpenGL všechna dostupná jádra.

[Sešívaný]

Člověk s dvoujádrovým procesorem by to prý na běhu systému neměl poznat. Nicméně na spotřebě se to IMHO projevit může.

[pepe_]

A jak toho docílit ?

[michich]

Nainstaluješ si nejnovější Fedora Rawhide. Nebo si prostě počkáš, až to probublá dále.

[pepe_]

Děkuji ale já raději DEB based ...  bordelu co umí RPM sem si užil před lety mnoho (možná se neřešitelní konflikty už v RPM nedějí) ale k tomu mi někdo kdo používá RPM based  RedHat Fedora Suse a podobné musí říci svůj názor na RPM s desktopem se 40000 balíčky z různých zdrojů děje.

[little.owl]

Co je to za pitomost? V cem konkretne je RPM horsi nez DEB, nehlede k tomu ze dnes je rozhodujici jejich nadstavba - yum ci apt.

Kombinace rpm + yum funguje jiz roky vyborne.

Pokud mate jen mnoho let starou zkusenost, tak radsi mlcte a nedelejte tady ze sebe blbce.

[Jiří J.]

Mě osobně by také zajímalo, zda existuje něco jako aptitude pro RPM balíčky na RPM-based distribucích. Mám víceméně jen staré a nepříjemné zkušenosti z Mandrake, Fedora Core 3/4 a CentOSu. Je pravda, že apt není o moc (pokud vůbec) přívětivější, než yum, ale aptitude už umožňuje alespoň částečný "fine tuning" závislostí, takže se neinstaluje všech 150 recommended balíků (včetně Xorg), pokud chci nainstalovat "kvm", ale třeba jen 20 nutných ("depends").

Také možnost výběru mezi závislostmi je v aptitude řešená vcelku přehledně - např. balíček "debconf" závisí na "debconf-i18n NEBO debconf-english", takže si můžu odinstalovat ten první, nahradit ho druhým a ušetřit další místo na disku. Ještě viditelnější je to v případě virtuálního balíku "mail-transport-agent", na kterém závisí spousta balíků a který sám "obsahuje" několik dalších balíků (sendmail, postfix, exim4, ...), takže si uživatel může vybrat, jakého MTA chce, a z hlediska závislostí balíčků je to čisté, jednoduché a hlavně a především přehledné.

Pokud existuje něco jako aptitude (ncurses) pro RPM distribuce, sem s tím. Prosím.

Ale už vážně, dost offtopicu

[little.owl]

Jsme oba vice nez off-topic.

O ncurses nadstavbe yum-u nic nevim a za mnoho let pouzivani yum-u mi nechybela. V Debianu aptituce v ncurses modu take nepouzivam.

Fedora based distribuce nepouzivaji velke metapackage ci soft dependencies a jejich balicky nejsou tak fragmentovane. Jsou pak vetsi (a jejich pocet mensi), ale je jednoduzsi se v tom orientovat. Yum nabizi plugin, jak dependencies zobrazit (yum-utils: repo-graph).