Udzielone Odpowiedzi
- Posty
@azja – Doskonale rozumiem, co oznacza (i jak Ty to rozumiesz) „komercyjnie”. Po prostu wskazałem na to, że w Archu skończyła się chęć „dodawania do interesu” dla owych poniżej 2% użytkowników (z których też część może korzystać z rozwiązania 64bitowego, ale z różnych względów wybrało 32bitowe).
Jeśli chodzi o powstanie Manjaro (a byłem przy nim praktycznie od samego początku) – po prostu wzięli z Archa całość tego co mogli. Dodany wówczas został jedynie instalator oraz własne motywy (bo te jak pamiętam były od początku, ale tu głowy nie dam). Gdyby w Archu nie było wsparcia dla 32bitowego systemu – w Manjaro też by go nie było. Dopiero stosunkowo niedawno w Manjaro pojawiać zaczęły się paczki, których nie ma w Archu i które budowane są przez Manjaro (też najczęściej w oparciu o PKGBUILDy z AUR). Mniejsza o to i nie umniejszam Manjaro. Tak to po prostu jest z dystrybucjami opartymi o inne. Debian przeszedł na systemd, to i Ubuntu to zrobiło. Itd. itp.
Inna sprawa – nieszczęsne wsparcie 32bitowych maszyn. Powiedzmy sobie szerze – ostanie procesory 32bitowe (w architekturze x86) to końcówka pierwszej połowy lat 2000. Czy jeszcze istnieją, działają komputery na nich oparte? Pewnie tak. Niemniej jednak ich ograniczenia powodują, że ich zastosowanie do współczesnego oprogramowania jest… problematyczne. Mainstreamowe – bądź co bądź – dystrybucje jak Arch, czy Manjaro nie utrzymują specyficznych rozwiązań pod takie komputery (choć bez problemu Archa sobie pod niego skonfiguruję). Ograniczona moc, sprawność komputerów opartych o te rozwiązania powoduje, że prawdopodbnie zdecydowanie lepszym partnerem dla takich komputerów stają się dystrybucje, które są przeznaczone dla „ancient computers”. Jest takich całkiem sporo. Fakt – użytkownicy Archa (część tych niecałych 2%) i pochodnych będą musieli teraz na nie przejść (choć już dawno lepiej by im z nimi było). Rezygnacja ze wsparcia 32bitowych maszyn nie sprowadza się zatem do konieczności ich wyrzucenia przez właścicieli, ale do konieczności zmiany przyzwyczajeń. W przypadku tzw. ZU – nie powinno być problemów. Instytucje bardzo rzadko wykorzystują rozwiązania made in Arch i spółka. Znów zatem większego problemu nie powinno być.
Jeśli natomiast ktoś miał prawidłowo zainstalowanego Archa (lub Manjaro), to nawet przejście na inną dystrybucję (pomijam już przejście w Archu z 32 na 64bity) nie powinno być problemem.
Innymi słowy – wiele hałasu o nic, zwłaszcza, że informacja (przynajmniej w Archu) znana była od bardzo wielu miesięcy. Kiedyś – i to chyba drastyczniej – pożegnano się 16 bitami. Bardziej zaboli ostateczna rezygnacja z 32bitowego wsparcia w MS, czy nawet w Apple niż w Archu ;)Jeśli masz mlocate – co mówi:
locate sd_mod
Winien znaleźć plik sd_mod.ko.gz w katalogu /usr/lib/modules/TU_WERSJE_KERNELI/kernel/drivers/scsi/. Co ciekawe, linux-bede ma ów sd_mod ustawiony jako część samego kernela (nie moduł, a na „sztywno”).
Co mówi:
lsmod | grep sd
Swoją ścieżką… Ty masz komputer Apple’a? Ike swój linux-bede buduje przede wszystkim na tego typu komputery (choć oczywiście zwykli potomkowie PC również winni być obsługiwani). W przypadku „normalnych” PC sens korzystania z bede jest powiedzmy taki sobie. Więcej osiągnie się czy to korzystając z innych rozwiązań, czy to budując kernel (nawet w oparciu o config bede i dostosowując go) we własnym zakresie.rozwiązania niekomercyjne nie bazują na liczeniu centów
Cóż, ktoś jednak za to wszystko płacić musi. Nic nie dzieje się za darmo. Serwer, infrastruktura – to są wszystko wymierne kwoty. Do tego dochodzi jeszcze praca opiekunów paczek, która wprawdzie darmowa z punktu widzenia ZU, ale która taką nie jest z punktu widzenia opiekuna. On na tym, abyś Ty mógł korzystać z Manjaro po prostu traci (bowiem nie może tego czasu poświęcić na zarabianie).
W przypadku Archa taka decyzja kroiła się od dawna. Kiedy odsetek osób korzystających z 32 bitowej architektury spadł bodaj do 1,7% zapadła jedyna logiczna decyzja – dalsze rozwijanie Archa 32bit nie ma sensu. Nie oznacza to jednak pozbawienia użytkowników możliwości korzystania z aplikacji, które są wyłącznie 32bitowe (np. niektóre sterowniki do choćby skanerów, czy drukarek). W przeciwieństwie do np. KaOS w dalszym ciągu pozostaną biblioteki multilib oraz owe 32bitowe aplikacje, które nie mają 64bitowej alternatywy. Wszyscy zatem użytkownicy maszyn z architekturą x86-64 (AMD64) nie zostaną pozbawieni żadnej możliwości. Arch przestanie być natomiast dystrybucją dla użytkowników komputerów x86, chyba, że taki użytkownik zdecyduje się na kompilowanie wszystkiego we własnym zakresie (co wg mnie mija się z celem – w takim przypadku sensowniej sięgnąć choćby po Gentoo). Konsekwencją porzucenia architektury 32bitowej w Archu jest decyzja w Manjaro, albowiem nie mieliby już skąd brać jakich 80-90% paczek dla tej architektury, a na początku masz wytłumaczenie – utrzymywanie tego we własnym zakresie kosztuje.
Ze względu jednak na istniejące, gotowe rozwiązania z Archa (i innych, pochodnych) nie istnieje żaden powód, dla którego ktoś nie mógłby się zdecydować na stworzenie dystrybucji „likeArch32” :), która byłaby wyłącznie 32bitowa. Być może tak się stanie. Niemniej jednak wymaga to mniejszych lub większych nakładów tak finansowych, jak i samej pracy takiej osoby/osób.@azja – Dziękuję za jakże trafną diagnozę dotyczącą umiejętności czytania przeze mnie :D Nie, nie spieram się – staram się tłumaczyć coś, co często traktowane jest po łebkach i powoduje potem komplikacje. Sam niejednokrotnie pisałeś, że budowanie z AUR skutkuje dbaniem o system samemu. I masz w tym sporo racji. Niestety szczególnie osoby korzystające wcześniej z dystrybucji z niezależnymi repozytoriami (np. PPA) lub dla których np. Manjaro stanowi pierwszą dystrybucję podchodzą do AUR jakby to było „normalne” repozytorium, w dodatku tworzone przez jakichś „poważnych” deweloperów. Prawda jest taka, że pośród opiekunów paczek znajdują się zarówno devowie, jak i tzw. trusted user Archa. Są jednakże także osoby, które mają niewielkie pojęcie o tym jak winien zostać sporządzony PKGBUILD. Są też paczki opuszczone (orphaned). Niemniej jednak nawet do dyspozycji ZU zostało oddane takie narzędzie jak namcap – walidator PKGBUILDów i zbudowanych paczek. Jeśli PKGBUILD znajdujący się w AUR nie pochodzi od TU czy DEV Archa, jeśli nie pochodzi od osób, co do których mamy niemal bezkrytyczne zaufanie, to przepuśćmy taki PKGBUILD, a następnie zbudowaną paczkę przez namcap i doprowadźmy ją do prawidłowej postaci. Unikniemy wówczas (a przynajmniej zminimalizujemy) problemy w przyszłości. Zdecydowanie lepiej budować zatem paczki z AUR bez użycia AURhelperów (mamy zdecydowanie większą kontrolę, nadto możemy nie usuwać tworzonych wówczas katalogów src i pkg, nie musimy często ponownie budować, a jedynie – po korekcie PKGBUILD – przepakować już zbudowany kod). Ot, tyle. Jeśli ktoś sam nie wie jak to zrobić, to na pewno wskazując na wynik walidacji takiej paczki znajdzie się ktoś, kto pomoże. Tyle.
W przypadku PKGBUILD qnapi, do sekcji:
1. depends należy dodać hicolor-icon-theme
2. z tego samego ustawienia uzunąć p7zip
3. dopisać ustawienie optdepends o treści:
optdepends=('p7zip')
Z tak przebudowanym PKGBUILDem uruchomić kompilację. Tylko tyle. W podobny sposób należy postępować z praktycznie każdym PKGBUILDem w AUR. Nie wiem gdzie w tym wszystkim widzisz „osobiste traktowanie uwag”. Może jedynie w tym, że wolę unikać w przyszłości „problemów” na forach, które są pochodnymi niedbałości tak wywołanej przez opiekuna paczki w AUR, jak i przez samego użytkownika, albowiem mógł uniknąć tych problemów. Dochodzenie potem o co chodzi, dlaczego system się wali, choć nie powinien, jest często wręcz niewykonalne. Lansowane przez Ciebie twierdzenia o „nic się nie stało”, bo coś z Twojego punktu widzenia nie jest niezbędne, a jest zbędne tylko i wyłącznie z punktu widzenia paczki, że „nadmiarowe” zależności nic złego nie powodują jest po prostu wadliwe, a niekiedy wręcz szkodliwe zwłaszcza dla osób najmniej obeznanych z – ogólnie – pacmanem i sposobem zarządzania przez niego paczkami.
I w istocie – z takimi twierdzeniami będę polemizować. Zawsze.OT: @azja – Spierasz się ze standardami :) Otóż tworzenie paczek w Archu, w tym tworzenie PKGBUILDów jest zestandaryzowane od bardzo już wielu lat. Nie ma tu z czym polemizować. Nie istnieją „nadmiarowe”, czy „niedomiarowe” żadne zależności. Poczytaj o standardach paczkowania w Archu (tu od razu do tzw. etykiety) oraz o tworzeniu PKGBUILDów (tu o samych zależnościach).
Dlaczego nie ma „nadmiarowych” zależności? By niepotrzebnie nie ściągać ich z sieci. Wszak te serwery utrzymują najczęściej jacyś ludzie z własnych środków. Pomijam kwestię porządku w systemie. „Nadmiarowa” paczka powoduje też, że nie zostanie odinstalowana bez odinstalowania paczki, która ją niepotrzebnie trzyma. Np. w przypadku qnapi jako zależność zostanie zainstalowane p7zip. Jeśli nie chciałbym z niego korzystać, to nie mogę go spokojnie usunąć, albowiem pociągnie to odinstalowanie qnapi. Zerwanie zależności niemal nigdy nie jest dobrym pomysłem.
To, że coś jest „zbędne z punktu widzenia paczki” to jest właśnie to o co chodzi. Żadna paczka nie ma prawa instalować Ci przy okazji czegoś, czego sama nie wymaga do swojego działania. Ba nawet tzw. zależności opcjonalne winny zostać wyodrębnione i sam użytkownik winien mieć możliwość decyzji, czy potrzebne mu rozszerzenie funkcjonalności danej aplikacji, czy też nie.
Dlaczego nie ma „niedomiarowych” zależności? Bo na czystym systemie (np. takim bez żadnego środowiska) nie jesteś w stanie zbudować takiej paczki. Nie ma znaczenia „popularność” owej zależności. Jeśli na czystym systemie nie jesteś w stanie zbudować paczki z powodu braku jakichś zależności, to oznacza, że jej PKGBUILD jest wadliwy.
Nie istnieją też żadne „tradycje” w „nadmiarowości” czy też „potrzeby innych dystrybucji”. Pierwsze nie istnieje i nie istniało nigdy, drugie… Cóż AUR to Arch User Repository. Jest przeznaczone (choć nie jest wspierane) wyłącznie dla Archa. Nb. w żadnej dystrybucji opartej o pacmana (ba, nawet żadna inna) nie będzie istnieć potrzeba owej „nadmiarowości”. Skoro do działania paczki nie jest wymagana jakaś zależność, to nie jest to istotne czy będzie to zbudowane ze źródeł w tradycyjny sposób, czy też będzie to zbudowane dla jakiejkolwiek dystrybucji – zawsze bez owej „nadmiarowej” zależności paczka będzie działać.
I by nie było kompletnie OT – w przypadku qnapi prawidłowym miejscem dla p7zip jest sekcja „optdepends”.
Koniec OT z mojej strony i koniec rozwijania wątku (przeze mnie).
@mjedr – Skompiluj/zainstaluj sobie qnapi raz jeszcze, jednakże gdy to coś, z czego korzystasz zapyta o to czy instalować zależności masz odpowiedzieć twierdząco.Nie wiem w jaki sposób zachowa się, w takiej sytuacji (brak wymaganego pakietu), yaourt, czy inne narzędzie do instalacji z AUR
Tak jak każdy AURhelper. Nie ma to zresztą z nim absolutnie nic wspólnego, albowiem za budowę paczki odpowiada makepkg, który we wszelkich AURhelperach jest ustawiony z przełącznikiem „-s”, czyli ściąga zależności. W przypadku budowy „ręcznej” makepkg „widzi” tylko paczki w repozytoriach, czyli zależności z AUR trzeba również ręcznie zbudować i doinstalować. W przypadku owych AURhelperów zależności z AUR są również kompilowane i instalowane przed budową docelowej paczki.
@mjedr musiał odpowiedzieć przecząco na propozycję instalowania zależności i stąd błąd.
Walidacja paczki qnapi daje następujący wynik:qnapi E: Dependency hicolor-icon-theme detected and not included (needed for hicolor theme hierarchy) qnapi W: Dependency included and not needed ('p7zip')W zasadzie oznacza to, że powinniśmy wyedytować PKGBUILD przed kompilacją i w polu „depends” dodać hicolor-icon-theme i usunąć stamtąd p7zip.
Wobec braku wsparcia dla KDE4 także sekcja „package” mogłaby zostać lekko zmieniona, albowiem bez sensu w Archu tworzy wpisy dla tej wersji środowiska.Zawsze wtedy korzystałem z metody raz-na-raz, czyli po jednym pakiecie.
Niestety nie zawsze się da, chyba, że zrobisz największą głupotę – zerwiesz zależności. W ten sposób da się co do zasady odinstalować jedynie „ostatni” pakiet, który nie stanowi zależności dla innych. Vide:
sudo pacman -R kio [sudo] hasło użytkownika pb: sprawdzanie zależności… błąd: nie udało się przygotować transakcji (nie udało się rozwiązać zależności) :: akonadi: usuwanie kio zależność przerw 'kio' :: baloo: usuwanie kio zależność przerw 'kio' :: bluedevil: usuwanie kio zależność przerw 'kio' :: kactivitymanagerd: usuwanie kio zależność przerw 'kio' :: kcron: usuwanie kio zależność przerw 'kio' :: kdav: usuwanie kio zależność przerw 'kio' :: kde-syndication: usuwanie kio zależność przerw 'kio' :: kdeclarative: usuwanie kio zależność przerw 'kio' :: kdesdk-kioslaves: usuwanie kio zależność przerw 'kio' :: kdesignerplugin: usuwanie kio zależność przerw 'kio' :: kdesvn: usuwanie kio zależność przerw 'kio' :: kdialog: usuwanie kio zależność przerw 'kio' :: kimap: usuwanie kio zależność przerw 'kio' :: kinit: usuwanie kio zależność przerw 'kio' :: kio-extras: usuwanie kio zależność przerw 'kio' :: kipi-plugins: usuwanie kio zależność przerw 'kio' :: knewstuff: usuwanie kio zależność przerw 'kio' :: knotifyconfig: usuwanie kio zależność przerw 'kio' :: kooka-git: usuwanie kio zależność przerw 'kio' :: kparts: usuwanie kio zależność przerw 'kio' :: kpimtextedit: usuwanie kio zależność przerw 'kio' :: krita: usuwanie kio zależność przerw 'kio' :: krusader: usuwanie kio zależność przerw 'kio' :: ksystemlog: usuwanie kio zależność przerw 'kio' :: kuser-frameworks: usuwanie kio zależność przerw 'kio' :: kwalletmanager: usuwanie kio zależność przerw 'kio' :: kxmlrpcclient: usuwanie kio zależność przerw 'kio' :: libkcddb: usuwanie kio zależność przerw 'kio' :: libkomparediff2: usuwanie kio zależność przerw 'kio' :: plasma-integration: usuwanie kio zależność przerw 'kio' :: skanlite: usuwanie kio zależność przerw 'kio' :: tellico: usuwanie kio zależność przerw 'kio' :: user-manager: usuwanie kio zależność przerw 'kio'oraz dla porównania:
sudo pacman -R user-manager sprawdzanie zależności… Pakiety (1) user-manager-5.10.5-1 Odzyskane miejsce na dysku: 0,85 MiB :: Czy chcesz usunąć te pakiety? [T/n] nMasz wtedy pełną kontrolę nad całym procesem.
Racja o tyle, że próba odinstalowania kio jako jednej paczki pokazuje – nie jest to możliwe, bo są zależności. Odinstalowując wraz z zależnościami (za jednym zamachem) – robi to samo, tylko inaczej pokazuje. Odinstalowanie w pierwszy sposób ma jedną jednak zaletę – unika się machinalnego walnięcia y.
Ilość pakietów zależnych, które chcą się odinstalować (jeżeli takie są) jest dużo mniejsza.
Polecenie:
pacman -Rsn paczka
oraz polecenie
pacman -R paczka paczka1 paczka2
gdzie „paczka1” i „paczka2” są zależnościami paczki „paczka”, które po jej odinstalowaniu nie są potrzebne już w systemie dają ten sam efekt. Odmienne twierdzenie przeczy zależnościom wpisanym na sztywno w PKGBUILDach.
@loctor – W moim poradniku odinstalowania – choć w istocie ja zwykle używam przełącznika „Rcns” (i kontroluję co się dzieje), dla Ciebie bezpieczniej będzie użyć polecenia:
# pacman -Rsn jakaś-amgpu-pro
Po wykonaniu warto jeszcze sprawdzić, czy jakieś inne amdgpu-pro (np. lib32-*) nie są zainstalowane.No skupiliśmy się nad doprowadzeniem amdgpu(-pro) do działania.
Ok. Czując się wywołanym – kilka uwag. Po pierwsze nie jestem graczem. Gra, której mi brakuje w linuksie to… brydź. Niczego innego mieć nie muszę. Ok – mam na androidzie. Po drugie nie używam od lat WINE (preferuję postać płynną :)). A teraz już uporządkowanie kilku rzeczy. Moja wiedza o obu tych rozwiązaniach jest mocno sprzed lat.
1. O ile widzę, to – przynajmniej niektóre – gry windowsowe pod linuksem mogą wykorzystywać OpenGL. Dobrze sprawdzić wineDB, a uruchamia się to tak. Zerknij sobie jeszcze na ten tekst – może akurat w interesującej Cię grze po pierwsze da się z tego rozwiązania skorzystać, po drugie może będzie działać lepiej.
2. „Panelu sterowania” dla zarządzania ustawieniami sterownika karty graficznej dla amdgpu (i nie tylko) nie ma, nie było i pewnie nie będzie (chyba, że ktoś napisze). Masz natomiast dość szczegółowy opis w dwu tekstach na wiki Archa: ATI i AMDGPU. Teoretycznie Xy są tak obecnie skonstruowane, że wszystko dzieje się automatycznie. Niemniej jednak masz jeszcze tekst dotyczący samych Xorg.
W Plasma część rzeczy możesz ustawić poprzez „Ustawienia systemowe”. OpenGL wybierasz w „Wyświetlanie i monitor” -> „Kompozytor”. Teoretycznie przy Twojej karcie lepszym ustawieniem winno być OpenGL 3.1, ale niekiedy okazuje się, że OpenGL 2 jest mimo wszystko sprawniejsze. Musisz sobie to sprawdzić we własnym zakresie.
Dodatkowo w innych miejscach jesteś w stanie sprawić, że wyświetlanie dostosujesz do poziomu, który Ci będzie odpowiadać.
Podobnie WINE ma swoje własne ustawienia. Istnieje programik pn. Q4Wine (bodaj w AUR), który pozwala na ustawianie WINE w dość łatwy sposób (z zastrzeżeniem: o ile pamiętam).
3. Niezależnie od tego, że można sobie instalować WINE itd. itp., to mając 2 systemy sensowniej jest – tam gdzie tylko można – korzystać mimo wszystko z aplikacji natywnie. Skoro są one dla Windows to nie ma cudów – żadne WINE (wszak to swoisty emulator-nie emulator) nie spowoduje, by to działało tak samo jak natywnie.
4. To są bzdurki. Ważniejsze to uporządkować system. Skoro z owym amdgpu-pro masz jakoś pod górkę, a część się zainstalowała, to najsensowniej wywalić to co się poinstalowało. Zacznij od zlokalizowania jakie sterowniki amdgpu-pro masz. Spróbuj:
pacman -Qs amdgpu-pro
Nie pamiętam już czy wszystkie paczki budowane z AUR mają w nazwie amdgpu-pro, ale chyba tak. Potem możesz przystąpić do ich usunięcia:
# pacman -Rcns nazwa_którejkolwiek_paczki_zwróconej_przez_poprzednią_komendę
Sprawdź co chce Ci się odinstalować. Teoretycznie polecenie to powinno pociągnąć za sobą odinstalowanie wyłącznie, ale też i wszystkiego, co z amdgpu-pro związane. Jeśli widzisz tu „pół systemu” do usunięcia, to oczywiście odpowiedz „n” i zamiast przełącznika „Rcns” daj samo „R”, a potem co najwyżej dodawaj paczki zależne na piechotę.
Wszystkie te czynności powinny doprowadzić do sytuacji, w której będziesz miał jedynie sterownik amdgpu, z którego powinieneś korzystać (nawiasem mówiąc możesz sobie nawet sterownik vesa usunąć /ja np. jego nie mam/, chyba, że chcesz go trzymać dla sytuacji naprawdę awaryjnych oraz potrafisz zmusić system do startu na vesie a nie dedykowanym systemie i jednocześnie nie potrafisz naprawić systemu w sposób najbardziej optymalny, czyli w konsoli).
5. UWAGA: Budowałeś jakiś sterownik dkms. Sprawdź zatem sobie czy jakieś moduły amdgpu-pro masz załadowane przez dkms:
# dkms status
Jeśli tak – to usuń:
# dkms remove nazwa/wersja --all
Zobacz tu i zrób analogicznie. Wykonaj zanim odinstalujesz paczkę amdgpu-pro-dkms.
6. Przed usuwaniem czegokolwiek sprawdź, czy na pewno sterownikiem w użyciu jest amdgpu.
7. Z owej akceleracji sprzętowej potrafią korzystać niektóre programy (jak wspomniałem – nie jestem graczem, czyli nie wiem, czy one również, czy też nie) przy odpowiednich ustawieniach tych programów (np. SMPlayer, czy VLC – wiem, podaję otwarzacze multimedialne, ale nie dlatego, że tylko one korzystają, ale dlatego, że tu wiem /bo mam skonfigurowane/, że te dwa programy na pewno potrafią wykorzystać dobrodziejstwa akceleracji sprzętowej).To już tak na koniec jeszcze jedna informacja nt. GPU AMD i sterowników. Może się komuś przyda.
Wiedziałem, że AMD mocno się wdrożyła w otwarte sterowniki dla swoich GPU. Nie wiedziałem jednak, że tak to ma obecnie wyglądać. Swoją drogą, to ciąży gdzieś w nas postwindowsowa ciągota instalowania sterowników odproducenckich. Podsumowanie obecnego stanu ze sterownikami AMD wygląda tak (wpierw zbiorczo, potem kilka moich uwag):
1. Dla kart X1000 i starszych – rozwiązanie jest jedno: tylko i wyłącznie sterownik otwarty ati (tj.: xf86-video-ati w nomenklaturze Archa i pochodnych).
2. Dla kart HD2000-HD4000 – zasadniczo (i łatwiej) xf86-video-ati, jednakże jest możliwe korzystanie z tzw. Catalyst legacy. Z tego ostatniego rozwiązania jednakże na wszystkich dystrybucjach rolling release nie będzie łatwo skorzystać, albowiem wymaga ono starszych rozwiązań typu xorg-server itp. Jeśli Manjaro jest systemem dla osób raczej o niewielkiej wiedzy, to w przypadku tej dystrybucji należy o tym rozwiązaniu raczej zapomnieć. W Archu też pewnie nie będzie polecane i nie ma żadnego wsparcia.
3. Dla kart HD5000-HD6000 – są dwie możliwości: otwarte xf86-video-ati oraz porzucony już ze dwa lata temu Catalyst. Ten ostatni ma jeszcze wsparcie w Manjaro, choć pewnie i stąd wyleci. Tak w Archu, jak i w Manjaro potrzebuje jednak starszej wersji Xów. W Archu rozwiązanie z Catalyst (mimo istnienia specjalnego, „niezależnego” repozytorium) – od dawna sterowniki te nie mają wsparcia.
4. Dla GCN1 i GCN2 – aż trzy możliwe rozwiązania: dwa sterowniki otwarte, czyli xf86-video-ati oraz eksperymentalna implementacja amdgpu, która wymaga odpowiednio skompilowanego kernela (ale jak się okazuje obecnie chyba każdy to ma w wersji minimum 4.9) oraz – w przypadku Manjaro – instalacji mhwd-addon-amdgfx-hwe (dającej możliwość obsługi przez mhwd). Nadto Catalyst.zastrzeżeniami jak poprzednio.
5. Dla GCN3 również istnieją trzy możliwe rozwiązania: amdgpu, amdgpu-pro oraz… Catalyst.
6. Dla GCN4 i nowsze – amdgpu oraz amdgpu-pro.Teraz już uwagi. Miałem możliwość korzystania z kilku kart AMD i używałem na nich ati, amdgpu oraz catalyst (tego ostatniego tak w Manjaro, jak i na Archu).
Uwaga ogólna – sensownie jest uruchomić tzw. akcelerację sprzętową, albowiem programy, które mogą ją wykorzystać umożliwiają lepszą pracę komputera.
Sens używania sterowników takich jak Catalyst jest raczej mizerny. Lepiej używać nowszych kerneli i nowszych sterowników otwartych, w tym mesa. Wydajność współczesnych X.Org, Mesa i sterownikach otwartych sensowniej używać te właśnie sterowniki. Mniej problemów. Zwróciłbym również uwagę, że sterownik Catalyst został porzucony przez AMD – żadnych poprawek, w tym bezpieczeństwa, raczej już nie będzie. Xy przez swoją konstrukcję są natomiast dość czułe na kwestie bezpieczeństwa związane ze sterownikami. Używać nikomu nie zabronię, jednak pod rozwagę daję.
Owe eksperymentalne wsparcie dla amdgpu w przypadku GCN1 i GCN2 istnieje w kernelu i niemal każde nowe jego wydanie przynosi tu jakieś zmiany i ulepszenia. Istnieje prawdopodobieństwo, że korzystając z jak najnowszej wersji kernela winno przynieść polepszenie działania amdgpu na tego typu GPU. Moje doświadczenie jest takie, że w tych sytuacjach sterownik ati radzi sobie lepiej od amdgpu, jednakże może to być zależne od poszczególnego typu GPU i używanego kernela. Sensu używania kernela starszego od 4.9 nie ma.
W przypadku nowszych procesorów (>=GCN3) – AMD wymyśliło to tak, że dla zwykłego użytkownika winien wystarczyć sterownik amdgpu (otwarty). Jego wydajność w „typowych” zastosowaniach, w tym w grach, winna być taka sama jak amdgpu-pro. Różnice mogą dotyczyć ustawień jednego i drugiego sterownika, ale nie technologii używanej w tym zakresie. Sterownik amdgpu-pro jest przeznaczony wyłącznie dla profesjonalistów, którzy zawodowo wykorzystują GPU w jakichś celach i wymagają np. dodatkowego wsparcia ze strony producenta GPU. M.in. dlatego sterownik ten przez AMD jest robiony wyłącznie dla dystrybucji klasy enterprise (RHEL, SLES) i dodatkowo (pewnie ze względu na popularność i również wykorzystywanie w takich zastosowaniach) ostatniego Ubuntu LTS (obecnie to 16.04).
Sterowniki amdgpu (w tym pro) nie będą obsługiwać starszych GPU niż GCN1 nigdy (przynajmniej wg obecnej wiedzy). Sterowniki amdgpu-pro raczej nie trafią do dystrybucji innych niż klasa enterprise (czyli Red Hat i komercyjne SUSE) i Ubuntu (chyba, że jego miejsce – pod względem popularności i długości wsparcia – zajmie powszechnie inna jakaś dystrybucja).
Używanie sterowników amdgpu-pro na innych dystrybucjach odbywa się bez wsparcia producenta. Sterowniki te są tworzone przez przebudowanie udostępnianych przez AMD pakietów rpm lub deb do formatu binarnego stosowanego w danej dystrybucji. Ze względu na to, że oryginalnie sterowniki te są dostosowane do dystrybucji, w których raczej trudno o „nowinki”, wymagają one określonych wersji oprogramowania „towarzyszącego”, z których korzystają. Podobnie jak ma to miejsce w przypadku Catalyst – sterownik taki będzie wymagał określonej wersji np. Xów, czy Mesa, które należy wówczas „zastabilizować” na tej właśnie wersji i nie dopuszczać do ich aktualizacji. Podobnie wymagają określonej wersji kernela (min. to 4.8) i z nowszymi od 4.9 mogą nie pracować prawidłowo. O ile sterownik ten istnieje dla Archa, to nie istnieje sterownik dla Manjaro (nikt się tym nie zajmuje). Budowa tych sterowników dla Manjaro, aczkolwiek niewykluczona, wymaga naniesienia poprawek na dostępne w AUR źródła (patche). Ten, kto chce mimo wszystko skorzystać musi się zainteresować tym we własnym zakresie bądź skorzystać z wiedzy osób potrafiących przeanalizować zarówno rozwiązania dostępne w Manjaro jak i kod dostępnych patchy i je dostosować (bądź wprowadzić nowe). Rozwiązanie drugie odpowiada jednakże w chwili swego utworzenia czemuś, co w AUR nazywa się „orphaned” – porzuconym pakietem. Jak wspomniałem – nie istnieje jak na razie – rozwiązanie dla Manjaro, o które ktoś by dbał. Stąd np. może się okazać, że po pojawieniu się nowej wersji amdgpu-pro w AUR, albo wersja taka się nie zainstaluje (nawet z posiadanymi patchami dla Manjaro), albo będzie wymagać zupełnie nowych. Innymi słowy jest to rozwiązanie wyłącznie dla bardzo świadomej osoby, która potrafi sobie radzić z takimi sprawami. Wówczas jednak prawdopodobieństwo, że korzysta z Manjaro, a nie z Archa jest znikome.
W przypadku WINE zwracam uwagę na wpis na wiki Archa.
Koniec przynudzania.
Przeszperałem jeszcze forum Manjaro. Wnioski:
1. AMDGPU-PRO nie jest w Manjaro wspierane i szybko nie będzie.
2. Czy można je zainstalować? Po pewnych zmianach wprowadzonych w patche do wersji dostępnej w AUR, oraz stosując się do instrukcji tam istniejących – prawdopodobnie tak.
3. Niemal w żadnej grze nie osiągniesz lepszej jakości od sterownika amdgpu. „Nakładka”, jaką jest amdgpu-pro np. w zakresie wykorzystywania OpenGL stosuje to samo rozwiązanie co amdgpu. Ponoć sens korzystania z *-pro istnieje wyłącznie w zakresie konieczności korzystania z HDMI 2.0/Freesync/HDMI-Audio.
4. Istnieje w Manjaro jakaś paczka mhwd-addon-amdgfx-hwe związana z GPU serii GCN. Możesz sobie sprawdzić co daje, ale jeśli się nie mylę, to wyłącznie włącza możliwość stosowania amdgpu dla kart CI i SI (czyli Ciebie chyba nie dotyczy).
5. W tym wątku piszą o Twojej karcie w Manjaro i możliwych rozwiązaniach.
6. Pomijając oczywisty fakt, że programy dla Windows w sposób naturalny lepiej uruchamiać w tym systemie, to jedyne co możesz sensownie zrobić, to pobawić się parametrami takimi jak np.: używanie określonej OpenGL (2 lub 3, teoertycznie ta druga winna być „lepsza” podczas, gdy większość środowisk uruchamianych jest z 2.0), włączyć akcelerację sprzętową (zwykle wyłączona po instalacji), spróbować zmieniać DRI itp. itd. Na amdgpu-pro – jak się wydaje szkoda czasu i generalnie zamiarem AMD nie jest to sterownik dla ZU a dla profesjonalisty, który wymaga określonych rozwiązań tam zawartych. Dla ZU jest wspierany i – co najmniej – współtworzony przez AMD otwarty sterownik amdgpu.@loctor – Kilka uwag:
1. Czy próbowałeś uruchomić akcelerację sprzętową dla amdgpu (bez pro)? Jak to działa pod WINE?
2. Czy przeczytałeś co najmniej przypiętą informację pod wszystkimi „paczkami” amdgpu-pro w AUR? Zastosowałeś się do tej porady i:
– masz wersję xorg-server 1.18 oraz
– masz zbudowaną z AUR mesa-noglvnd?
Bez nich (oraz bez kernela 4.9, ale to akurat masz) – ten sterowniki nie działa.
Mogę jedynie napisać, że wersja xorg-server, jaka jest w Archu to 1.19. Jeśli w Manjaro jest taka sama, to albo ryzykujesz i instalujesz z Archa wersję 1.18 korzystając z asp (o ile ono w ogóle w Manjaro jest), albo z repozytorium seblu.net lub korzystając z downgrade (o ile repozytorium Manjaro przechowuje obecnie starsze wersje paczek). Obecnie preferuję dwa ostatnie rozwiązania, albowiem prościej – instalują binarki. Są to jednak rozwiązania z Archa, a nie z Manjaro (tzn. repozytorium seblu jest na pewno archiwum paczek archowych; nie mam pojęcia natomiast, czy downgrade działa – kiedyś nie działąło).
Drugą paczkę musisz samodzielnie zbudować z AUR, albowiem choć jest wymagana przez amdgpu-pro nie jest jego zależnością.
Nie ma możliwości by amdgpu-pro-dkms (czy jakikolwiek inny) działał prawidłowo bez tych paczek oraz w sytuacji, gdy jego budowa została zakończona z błędami. Jakakolwiek próba zmuszenia jej do działania (oj źle doradzasz @azja) może doprowadzić w ogóle do braku możliwości uruchomienia systemu.
Nadto… ten sam błąd jest zgłoszony na gicie i to dwukrotnie: 1 i 2. Skoro dla tak zbliżonej dystrybucji do Archa jaką jest Antergos jeden z plików wymaga naniesienia zmian to i w przypadku Manjaro musi zostać przeprowadzona podobna operacja i przygotowany musi być odpowiednio zmieniony patch.PS: Z AUR nie jest instalowana żadna paczka! AUR zawiera jedynie „przepisy” umożliwiające kompilację paczki w systemie Arch Linux (Twórcy Manjaro gdyby byli choć odrobinę odpowiedzialni, to zamiast wypisywać brednie o „wspieraniu” AUR, czego nawet Arch nie robi, winni założyć swoje, dostosowane do tej dystrybucji podobne repozytorium, jak to zrobili np. twórcy Chakry, czy KaOSa). Z tego powodu „instalując” paczkę z AUR jest niezbędnym przeczytanie informacji, jakie podawane są w komentarzach do budowanego pliku. Inaczej – zwłaszcza, gdy próbuje się w ten sposób zainstalować tak podstawowe elementy systemu jak np. sterownik grafiki – można łatwo doprowadzić do destabilizacji całego systemu.
Bez owego „make.log” nic nikt nie jest w stanie powiedzieć o co chodzi. Z błędem powinieneś (jego zawartością) zasygnalizować na AUR.
Przecież masz wszystko napisane: zainstaluj pliki nagłówkowe kernela. Mają one taką postać linuxXX-headers. W Twoim przypadku owe XX to 49. Potem zainstaluj raz jeszcze sterownik (bo najprościej).
Jeśli się nie mylę, to WINE działa jako 32bitowe, potrzebny Ci będzie też lib32-amdgpu-pro by korzystać z niego pod WINE. Sprawdź, czy masz taki zainstalowany.
Sterownik winien się uruchamiać automatycznie, ale sprawdź wpisy, o których mowa w wiki. Ów „early KMS” jest alternatywą (po prostu sterownik startuje wówczas wcześniej).
Uruchom sobie akcelerację sprzętową, bo bez niej w programach, które ją potrafią wykorzystać nadal będziesz miał słabą wydajność.Gwoli wyjaśnienia: pamac zbudował po prostu wyłącznie paczkę *-dkms, która nie ma zależności od ncurses-compat-libs.
@azja: Raz jeszcze:
1. Wszystkie paczki amdgpu są tworzone z jednego PKGBUILDu. Nie ma odrębnych dla amggpu-pro, *-dkms, czy xf86-*. To jest ten sam PKGBUILD, który tworzy je wszystkie. Nie ma zatem znaczenia, czy budujesz *-dkms, czy cokolwiek innego. Paczki (jest ich od groma) są te same. Taka struktura tzw. *base i splitted paczek.
2. Zobacz co instaluje ncurses5-compat-libs i znajdziesz odpowiedź na zadawane mi pytanie. Ncurses a ncurses5-compat-libs to dwie różne rzeczy, co łatwo sprawdzisz gdy zbudujesz paczki i zobaczysz co dostarczają. Tak, czy inaczej – amdgpu-pro wymaga ncurses5-compat-libs bez czego nie zainstalujesz w systemie amdgpu-pro (sterowników).Jak na razie – jeśli @loctor chce mieć amgpgu-pro to albo musi dokonać proponowanych zmian, albo poczekać na aktualizację. Pierwsze nie jest absolutnie żadnym problemem :)
Budując z AUR czytajcie komentarze…
Nie masz w systemie zainstalowanego ncurses5-compat-libs z uwagi na to, że PKGBUILD w AUR jest już zbyt stary i nie są już dostępne źródła, z których korzysta. Bez tej paczki nie będzie możliwości zainstalowania jednej z paczek budowanych w ramach amdgpu-pro.
Skoro masz Manjaro KDE, to powinien tu być yaourt – jeśli nie – doinstaluj. Wykonaj kolejno:
yaourt -G ncurses5-compat-libs && cd ncurses5-compat-libs
W katalogu znajdziesz plik PKGBUILD – otwórz go do edycji i zmień wszystkie wystąpienia daty 20170527 na 20170819.
Będąc w ww. katalogu, wpisz w konsoli:
updpkgsums && makepkg -sirc
Przebuduj (dla pewności, bowiem nie jest to absolutnie konieczne) paczkę xf85-video-amdgpu-pro i zainstaluj paczki, które otrzymasz (nie będzie to jedna paczka). Sprawdź wcześniej co dostarczyło Ci lib32-amdgpu-pro-17.10.401251-2 bo jest to paczka budowana i instalowana „w ramach” tego sterownika. Ze względu na to, że sterowniki nie zainstalowały Ci się, to nie powinieneś mieć jej w systemie.
Przy okazji – nie istnieją 3 różne sterowniki amdgpu-pro (sorki, nie zauważyłem tego wcześniej). Jest jeden, który buduje cały zespół paczek (podobnie jak np. PKGBUILD dla dowolnego kernela buduje sam kernel, jego pliki nagłówkowe i dokumentację). Paczki amdgpu-pro czy amdgpu-pro-dkms (i kilka innych) są budowane wraz z xf86-video-amdgpu-pro. Jeśli zechcesz zbudować np. amdgpu-pro-dkms to w efekcie otrzymasz dokładnie te same paczki, jakie zbudujesz budując amdgpu-pro czy xf86-video-amdgpu-pro.
Paczka lib32-amdgpu-pro-17.10.401251-2 powinna zostać przeinstalowana przy instalacji sterowników. Możesz jednak ją wcześniej spróbować odinstalować, by nie mieć jakichś problemów w systemie.
