Programista Red Hata – Adam Jackson, który pracuje obecnie dla projektów Fedora i X.Org, dokonał kilku zmian w kodzie rozwojowym, pozwalających na uruchomienie GNOME Shell z efektami graficznymi bez akceleracji 3D. Jak zapewne jest nam wiadome, GNOME Shell do swojego działania wykorzystuje menedżera okien Metacity, i narzędzie Clutter zapewniające efekty graficzne, który wymaga aby sterowniki graficzne posiadały wsparcie akceleracji 3D. Jeżeli takowej nie ma, to środowiska przełącza się automatycznie w tryb 2D. Dużym plusem jest również uniwersalność tego rozwiązania, ponieważ powinno ono działać bez problemów z innymi środowiskami graficznymi, czy menedżerami okien.
Całość polega na użyciu sterownika llvmpipe, części Mesa 3D który wykonuje zadania głównego procesora, zapewniając odpowiednie obliczenia, które normalnie powinien wykonywać procesor graficzny. Dla gier 3D jest to oczywiście za wolne, nawet przy użyciu wielordzeniowości, wielozadaniowości, czy instrukcji SSE2, SSE3, czy SSE4. Jednakże GNOME Shell jest znacznie bardziej oszczędny w wykorzystaniu efektów graficznych. Na wielu komputerach i systemach zwirtualizowanych za pomocą KVM, wydajność llvmpipe jest odpowiednia dla GNOME Shell, co pozwala pracować płynnie. Technologia jest jeszcze w początkowej fazie rozwoju i nie została zoptymalizowana pod jądro Linux, Mesa 3D, X.Org i Gnome.
Dzięki takiej technologii możliwe stanie się uruchamianie na maszynach wirtualnych, czy przy pomocy sterowników graficznych VESA prostych efektów graficznych, które aktualnie potrzebują akceleracji 3D. Na stronie dla Fedory 17, która ma zostać wydana w maju przyszłego roku, możemy zobaczyć wstępny szkic, dotyczący implementacji owej technologii.
Od wczoraj testuję sobie Gnome Shell i jest on całkiem używalny. Zaczynam się do tego typu rozwiązań przyzwyczajać.
I działa zdecydowanie lepiej i szybciej niż Unity! Ubuntu powinno zarzucić rozwój Unity.
"GNOME Shell do swojego działania wykorzystuje zmodyfikowaną wersję menedżera okien Compiz"
Ktoś tu popełnił sporego babola, tak srogiego, że szkoda gadać, ale rozumiem. Unity i gnome-shell wiele nie różni.
Faktycznie, mój błąd. Już poprawione :)
w takim razie moje komentarze w tym wątku są do usunięcia, bo tylko śmiecą
[…] zaimplementowali Gnome Shell, które można uruchomić z efektami graficznymi, bez wsparcia akceleracji 3D. Szczególnie ma to być przydatne przy wirtualizacji KVM oraz dla tych, co nie posiadają kart […]
[…] wymaga akceleracji 3D, postanowiono zrobić akcelerację ze sterownikiem LLVMpipe dla Gallium3D (GNOME Shell może działać bez akceleracji 3D). Problemem mogą być urządzenia z AMR, na których owa akceleracji będzie działała zbyt wolno […]
[…] świecie Linuksa istnieje wiele środowisk graficznych, ale najbardziej popularne to Unity, GNOME Shell, KDE, Xfce oraz przerobiony pulpit w Elementary OS. Ich użyteczność bywa kwestionowana przez […]
[…] opcje modesetting i fbdev były bardziej priorytetowe od sterowników Intela. Powodowało to wykorzystywanie renderowania pulpitu z użyciem llvmpipe, które jest zależne od procesora i objawiało się poważną stratą wydajności. MDM 1.0.8 […]
[…] Z wydaniem Fedora 17 planowane jest usunięcie ConsoleKit i dodanie wsparcia dla wielu stanowisk. Planuje się, że wszystkie usługi będą startować poprzez jednostki usług systemd oraz GNOME Shell będzie działał bez wsparcia akceleracji 3D. […]
[…] GNOME Shell może działać bez akceleracji 3D Programista Red Hata – Adam Jackson, który pracuje obecnie dla projektów Fedora i X.Org, dokonał kilku zmian w kodzie rozwojowym, pozwalających na uruchomienie GNOME Shell z efektami graficznymi bez akceleracji 3D. Jak zapewne jest nam wiadome, GNOME Shell do swojego działania wykorzystuje menedżera okien Metacity, i narzędzie Clutter zapewniające efekty graficzne, który wymaga aby sterowniki graficzne posiadały wsparcie akceleracji 3D. Jeżeli takowej nie ma, to środowiska przełącza się automatycznie w tryb 2D. Dużym plusem jest również uniwersalność tego rozwiązania, ponieważ powinno ono działać bez problemów z innymi środowiskami graficznymi, czy menedżerami okien. […]