Wyniki wyszukiwania dla 'sterowniki amd'

[JaOrazInni]

AMDGPU to sterowniki od amd(otwartoźródłwe). Posiadają oni też sterowniki AMDGPU PRO jednak nie są one oficjalnie wspierane przez arch-a. Wydajnościowo jest tak samo/gorzej/lepiej(zależne od strony, którą odwiedziłem). Tak więc jedyny mój pomysł to aktualizacja kernela do najwyższej możliwej wersji gdyż otwarte sterowniki amdgpu praktycznie z każdą aktualką są coraz lepsze ewentualnie przełączenie się na ich eksperymentalną wersje.

Tak czy inaczej fajnie gdyby jakiś pro się wypowiedział jeszcze.

[loctor]

Zadziałałem w Grubie jak pisałeś jednak nic to nie dało. Próbowałem czytać podlinkowany temat ale byłem tak zmęczony, że trafiało do mnie co drugie słowo. Ponieważ nie miałem w systemie nic niezbędnego postanowiłem go jednak przeinstalować.
Teraz jest pytanie: Jak zainstalować zamknięty sterownik AMD dla mojej karty? Czy w ogóle istnieje taki?
Mhwd podaje dwa sterowniki
amdgpu (zainstalowany)
video-vesa
Oba są otwartoźródłowe.

[JaOrazInni]

Trzeba brać pod uwagę, że POE nie jest napisane pod Linuxa i samo wine oraz playonlinux nie sprawi, że gra będzie działała idealnie.

Mimo, że gram na windowsie to potestowałem POE około 30 minut i żadnych spadków nie uświadczyłem. Jeżeli nadal masz grę zainstalowaną upewnij się, że w opcjach masz ustawione DX9 (jest jeszcze jedna wersja dx9 tam) oraz, że sama gra jest ustawiona na pełny ekran a nie na pełny ekran w ramce (czy jakoś tak) W najnowszej wersji POE na windowsa doszedł tryb zmiany ustawień w locie by gra była jak najpłynniejsza. Sprawdź czy ją posiadasz.

Co do GPU. gdy składałem nowego kompa to kupiłem kartę AMD (moja pierwsza w życiu) gdyż sprawdzając fora linuksowe zdecydowana większość mówiła, że amd ma najlepsze wsparcie na linuksa oraz, że sterowniki są świetne. Po 2 miesiącach karte wymieniłem na nvidie.

Nie wiem czy grasz w inne gry na linuksie ale sprawdź czy w ustawieniach amd działa poprawnie tryb oszczędzania energii. By nie było świetnie z nvidią to jakaś starsza wersja sterowników nie potrafiła przeskoczyć z power save na performance.
No i zapewne sterowniki od amd będą lepsze niż otwarte.

[pavbaranov]

Nie, to nie to. Kernele > 4.4 mają lepsze wsparcie dla amdgpu. Zatem coś jest skopane w kernelach i/lub (co najbardziej prawdopodobne) konfiguracji. Niestety Manjaro próbuje być milusińskie i nie zawsze to pomaga. Pomyślę i wrzucę coś.
Jak na razie mam pomysł taki, abyś zainstalował sterowniki xf86-video-ati. System winien powstać a jedynie gorzej wspierana będzie karta.
Swoją drogą, to masz przedziwny układ z podwójnym GPU AMD (zintegrowana i dedykowana).

[pavbaranov]

No to jeszcze gwoli wyjaśnienia:
1. Polecenie:
pacman -Syyuu
dokonuje:
– wymuszonej synchronizacji lokalnej bazy danych pacmana z bazą zdalną (na serwerze), która dokonywana jest nawet, gdy lokalne repozytoria są aktualne (to jest to yy); nie ma to większego sensu w normalnych warunkach,
– aktualizacji systemu, przy czym jeśli lokalnie zainstalowany pakiet jest w wersji świeższej niż na serwerze, to zostanie dokonana jego aktualizacja do wersji na serwerze (czyli tzw. downgrade); ma to sens w przypadku np. przejścia z testing na stable; tak, czy inaczej należy być absolutnie świadomym konsekwencji jego wykonywania.
2. Błąd „Error filesystem, Entering rescue mode” jest generowany przez GRUB, który napotyka jakieś trudności w wystartowaniu systemu. Jest to poważny błąd GRUBa, uniemożliwiający mu nawet wystartowanie kernela, a zatem jako taki z jego wersją raczej niewiele ma wspólnego. Przyczyny mogą być różne od wadliwego wygenerowania pliku konfigurującego GRUB, po skopanie czegoś w systemie. Wobec faktu, że kernele Manjaro (niestety) automatycznie wywołują przeładowanie GRUB być może coś w istocie jest skopane w kernel49, choć wątpię, albowiem wywoływane polecenie post-install jest poleceniem GRUBa i nie powinno zawierać żadnych instrukcji ingerujących w jego plik konfiguracyjny.
3. W przypadku takiej, zdalnej pomocy jak ma miejsce na forum, nie interpretuję, nie domyślam się, bo wyniknąć mogą z tego wyłącznie złe rzeczy. To ktoś pragnący pomocy musi dokładnie i precyzyjnie opisać co robi.
4. @iggys udzielił nam odpowiedzi na pytanie o sterowniki. Jeśli jest ona prawidłowa, to jest to amdgpu, czyli otwarty sterownik dla kart AMD GCN w wersjach 3 i 4. Wsparcie dla GCN 1 i 2 jest tu eksperymentalne, wymaga odpowiedniej wersji kernela (w 4.4 i nawet bodaj w 4.9 nie jest dostępne) oraz jego odpowiedniej kompiacji (nie wiem, czy kernel Manjaro jest kompilowany z uruchomieniem wsparcia dla tej eksperymentalnej funkcji, ale jeśli tak, to jest to proszenie się o kłopoty).

A teraz już do @iggys:
Rozumiem, że masz obecnie zainstalowane, działające Manjaro; wersja kernela to 4.4. Wykonaj w nim:
sudo pacman -Syu
Nie dokonuj instalacji żadnego innego kernela. Restart – działa?
Jeśli działa – zainstaluj inny kernel, ale nie 4.9. W Manjaro (niestety) wersji kernela pod dostatkiem – zainstaluj np. najnowszy, stabilny kernel 4.11 (przez mhwd). W tym momencie powinieneś mieć 2 kernele w systemie: 4.4 oraz 4.11, które winny być dostępne do wyboru podczas startu GRUBa. Zanim dokonasz restartu dokonaj edycji pliku /etc/default/grub, odnajdź w nim linijkę gdzie w treści znajdziesz:
GRUB_DISABLE_RECOVERY=
i doprowadź ją do postaci:
GRUB_DISABLE_RECOVERY=false
Linijka ta nie może być poprzedzona znakiem #.
Nadto usuń słowo „quiet”, które występuje w linii:
GRUB_CMDLINE_LINUX_DEFAULT=
Przeładuj GRUBego:
sudo update-grub
lub jeśli nie masz
sudo grub-mkconfig -o /boot/grub/grub.cfg
Restart i spróbuj wystartować komputer za pierwszym razem z kernela 4.4, za drugim z 4.11.
Jeśli wszystko pójdzie prawidłowo i w obu przypadkach system wstanie, zainstaluj kernel 4.9 i restart – teraz już tylko na 4.9 i bez wykonywania zmian w grub (bo wcześniej je dokonałeś). Jeśli system nie wstanie i nie będziesz miał możliwości przełączenia się do konsoli (alt+ctrl+Fx ew. jeśli jeszcze system graficzny nie wstał: alt+Fx) – twardy reset i przełącz się na działający kernel.
Opisz.

[azja]

… najpierw w kwestii formalnej. Manjaro (jako dystrybucja archo-pochodna) jest typu rolling release, czyli niekończące się wydanie (w wolnym tłumaczeniu, ma to swoje oficjalne, polskie? Muszę sprawdzić). A to znaczy tyle, że numer wersji jest jedynie znacznikiem czasowym, próbą umiejscowienia aktualnego stanu w historii rozwoju systemu, który jest jednym wielkim upgrade’m. Raz instalujesz, a potem tylko upgrade, upgrade … Zmieniając wersję (która, z punktu widzenia user’a jest istotna wyłącznie wtedy, gdy dokonuje instalacji systemu – ta wersja powinna być najnowsza, jeżeli to możliwe), zmieniasz wersje zestawu różnych pakietów (czasem kilkadziesiąt sztuk, czasem kilkaset – zależy co masz u siebie). Ciebie interesuje, nie to jaką masz wersję, tylko czy masz aktualny system, który powinien być ZAWSZE aktualny.
Jeżeli masz 4.4 i aktualizujesz system, to nadal masz 4.4 (jeżeli nadal jest wspierany przez Manjaro – nie wiem co wtedy, gdy nie jest, ale 4.4 jest LTS, więc póki co problemu nie ma). Co innego nowa instalacja – ta zapewne zainstaluje 4.11, co nie znaczy, że nie możesz potem zmienić na dowolną inną wersję, wspieraną przez system.

… teraz kernel. Z tego, co mówisz wynika, że zainstalowałeś inny kernel niż 4.4 – jeżeli wszystko poszło dobrze, z punktu widzenia instalacji samego kernel’a (roboczo tak załóżmy), to zasadnym jest pójść dalej. Czytając o objawach, jakie opisujesz i o tym, że masz AMD (z kontekstu wynika, że chodzi o kartę graficzną), to nie pozostaje mi nic innego, jak powtórzyć pytanie pavbaranov: Się tak spytam: jakie sterowniki masz do tego AMD?
Wyraźny trop prowadzi do karty graficznej, która nie chce się uruchomić (cokolwiek się za tym kryje). Musisz nam powiedzieć, jakie sterowniki wybrałeś: wolne czy własnościowe. Jeżeli nie wiesz i nie wiesz jak, to sprawdzić, to nie kombinuj, tylko napisz, że nie masz pojęcia o co chodzi. Chętni do pomocy znajdą się, muszą tylko mieć rzetelne informacje.
————-
EDIT: pytanie pomocnicze, jakie się nasuwa: dlaczego poprzednio działało, a teraz nie (zakładam, że stery do karty nie były zmieniane, tylko dołożony kernel – jeżeli było inaczej, to proszę o szczegółowe informacje nt. innych zmian w systemie)? Wygląda na to, że z 4.4 AMD gadało, a z 4.9/4.11 nie chce. iggys, jeżeli zostawiłeś kernel 4.4, to po pojawieniu się menu GRUB’a, powinieneś mieć (druga pozycja od góry) coś jak: 'Opcje zaawansowane systemu Manjaro’ (cytuję z pamięci). wejdź tam i wybiesz kernel 4.4 – sprawdźmy, czy nadal uruchamia się z 4.4.
————-

Nie zadawaj pytania, jeżeli nie jesteś gotów usłyszeć odpowiedzi

[pavbaranov]

iggys napisał(a):

AMD nie startuje.

Się tak spytam: jakie sterowniki masz do tego AMD?

[pavbaranov]

Ok, to spróbujmy, ale… Jak pewnie wiesz, nie mam Manjaro i nie mam NVidii. To co podrzucę jest tylko i wyłącznie efektem rozprawienia się kiedyś z Catalystem. Zasadniczo wybór sterownika w Manjaro winien się odbyć przez mhwd, który jakoś nie widzę, by działał, stąd też proponowane brute force.

Sterowniki (zamknięte) nvidia, w Twoim systemie to:

[robson@amd ~]$ pacman -Qs nvidia
local/lib32-nvidia-304xx-utils 1:304.134-6
local/linux49-nvidia-304xx 1:304.134-26 (linux49-extramodules)
local/nvidia-304xx-utils 1:304.134-8

Dodatkowo masz jeszcze sterownik otwarty:
local/xf86-video-nouveau 1.0.15-1 (xorg-drivers)
Nie mam natomiast pewności co do:
local/libxnvctrl 381.22-1
czy nie jest to jakiś element związany z nvidia.
Zacząłbym zatem po prostu od odinstalowania tych sterowników zamkniętych najnormalniej pacmanem. Mam nadzieję, że mhwd to puści. Odinstaluj z plikami konfiguracyjnymi, czyli co najmniej:
pacman -Rn
Zastanowiłbym się nad paczkami zależnymi, ale tu nie polecam, ani nie odradzam. Sam musisz ocenić w tym przypadku, czy pacman nie będzie chciał Ci odinstalować połowy systemu. Jeśli jednak będą to paczki jak ów libxnvctrl, to odinstaluj, albowiem to jest chyba wyłącznie paczka umożliwiająca sterowanie sterownikiem nvidia (przynajmniej na tyle, na ile rozumiem jej opis).
Następnie w tej samej sesji musisz jeszcze wyczyścić konfig XOrg, albowiem sterowniki własnościowe lubią sobie je ustawić wg własnych reguł. Normalnie, konfiguracja NVidii ląduje w /etc/X11/xorg.conf.d/ i/lub w /usr/share/X11/xorg.conf.d/. W którymś z tych katalogów, normalnie winien być plik 20-nvidia.conf, ale u Ciebie takiego nie widzę. Jest natomiast plik: /usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf. Na 99% to jest plik konfigurujący sterownik własnościowy nvidia.
Sprawdź też, czy w pliku: /etc/X11/xorg.conf nie masz zakomentowanego:
Load "dri"
Jeśli tak, to odkomentuj go, bowiem nouveau o ile się nie mylę korzysta z dri.
Generalnie dobrze przeglądnij ten plik i ewentualnie usuń to co z nvidia i wprowadź to co powinno być z nouveau.
Jeśli po usunięciu (-Rn) nadal pozostanie, to trzeba go będzie prawdopodobnie usunąć ręcznie (lub po prostu nadać mu nazwę bez conf).
Teraz przeszukaj system pod kątem blacklist i sprawdź, czy nie masz tam wrzuconego modułu nouveau (lub nv, bo nie pamiętam jak on się nazywa obecnie). Sprawdzić powinieneś zawartość plików w katalogach: /etc/modprobe.d/ i/lub /usr/lib/modprobe.d/. W tych katalogach szukasz wystąpienia słowa nouveau bądź to w nazwach plików, bądź w nich samych.
Teraz upewnij się, że GRUB nie zawiera w linii kernela parametrów nomodeset i/lub vga= lub też jakichś z nvidia w nazwie (np. wygląda na to, że masz DRM nvidia, zatem jest prawdopodobne, że w Grubym masz coś takiego: nvidia-drm.modeset=1. Jeśli takie ma – usuń i przeładuj Grubego.
Możesz też rozważyć dodanie w Grubym dla kernela parametru: nouveau.config=NvBios=PRAMIN. Powinien on zapobiec wywaleniu modułu nouveau.
Ostatnie co musisz dokonać, to uruchomienie KMS, które o ile wiem, NVidia „usuwa”. Przeglądnij plik /etc/mkinitcpio.conf, zobacz, czy nie ma w nim jakichś „nvidia” i rozważ dodanie „nouveau” do linii MODULES=. Jeśli zdecydujesz się na zmianę (a wg mnie powinieneś), to przebuduj obraz kernela przez:
# mkinitcpio -p jakiś_preset_kernela
U Ciebie jest w systemie chyba jeden kernel (linux49), zatem wywołanie powyższego bez podania presetu i tak winno tej jedyny kernel przebudować, możesz jednak dać mu ten parametr. Dostępne presety znajdziesz w: /etc/mkinitcpio.d/, dla linux49 najczęściej będzie zawierał podobną nazwę (u mnie np., preset dla mojego kernela /budowany przeze mnie/ nazywa się linux-pb.preset).

Jeśli o czymś nie zapomniałem, to po ponownym uruchomieniu komputera, system winien wykorzystać dostępny mu sterownik xf86-video-nouveau, a automatyka Xów winna go sobie skonfigurować sama. Przynajmniej tak winno się stać w systemach, które nie mają takich automatów jak mhwd, albowiem nie wiem jak dalece on ingeruje w system.

Jeśli nie wstaną Xy, to tutaj masz opisane jak uruchomić system w „czystej” sesji konsoli. Po dobraniu się do niego, możesz spróbować użyć mhwd i spróbować zainstalować raz jeszcze sterowniki otwarte, a przede wszystkim przeglądnąć, czy gdzieś nie pozostały jakieś jeszcze pliki po nvidia. Różnica jedynie taka, że wyjście nie przez exit, jak w moim poradniku, a będziesz musiał zrestartować system.
W takim przypadku możesz też spróbować wymusić ręcznie konfigurację Xów (tip.: X –settings

APPENDIX:
Zobacz sobie na konfigurację Nouveau w Archu – są tam jeszcze różne „tricki” na wypadek problemów z nouveau.

PS: Jeśli się na to zdecydujesz, to trzymam kciuki. Jak napisałem – teoretycznie winno zadziałać, albowiem powinieneś doprowadzić system do sytuacji, w której:
– system będzie wolny od sterownika nvidia oraz jego plików konfiguracyjnych,
– będzie miał sterownik nouveau bez żadnych plików konfiguracyjnych,
– XOrg winien sobie poradzić z załadowaniem i skonfigurowaniem nouveau.
PS2: Może się okazać, że nie wszystkie pliki, o których wspomniałem masz. Np. u mnie w systemie w ogóle nie ma pliku /etc/X11/xorg.conf, zaś Xy dla otwartego ati korzystają z /etc/X11/xorg.conf.d/10-radeon.conf (amdgpu z 10-amdgpu.conf itp.).
PS3: Co złego to nie ja :)

[pavbaranov]

macieslaw napisał(a):

A co daje kernel linux-pf czy lepszy od linux-ck?

Nie istnieje odpowiedź na pytanie „czy lepszy” jest jakiś kernel, czy gorszy. Kernel jest/może być lepiej dostosowany do danej konfiguracji sprzętowej. Od lat kompiluję własny, który stara się być w jak największym stopniu dostosowany/uwzględniający moją konfigurację. Niestety taki kernel nie jest przenośny. Na Twoim komputerze może się okazać, że w ogóle nie zadziała.
Wracając do pytania. Linux-pf to jest autorskie rozwiązanie Oleksandra Natalenki, które charakteryzuje się następującymi cechami (obecnie, bowiem to się zmieniało):
– patche poprawkowe na wersję „mainline” (choć nie dam głowy, że obecnie stosowana jest ta sama numeracja – niegdyś tak nie było, czyli np. kernel-pf 4.x.y-pf niekoniecznie odpowiadał kernelowi 4.x.y, gdzie x i y miały ten sam numer),
– cały patch CK (wraz z MuQSS i – obecnie jak sądzę – również z BFQ; to ostatnie od wersji 4.12 się zmieni o tyle, że na pewno będzie BFQ, albowiem wejdzie ono w mainline),
– (Natalenko twierdzi), że „oprócz” owego CK zawiera niezależnie BFQ; to jest o tyle dziwne, że obecny patch CK zawiera BFQ – być może to po prostu dla podkreślenia,
– patch „graysky’ego”.
Porównanie tych twierdzeń powoduje, że… obecnie należy stwierdzić, że kod źródłowy linux-ck od graysky’ego oraz kod źródłowy od Natalenki winny być… takie same :) Linux-ck zawiera bowiem dokładnie te same patche, co obecny linux-pf. W przeciwieństwie natomiast do linux-pf, w wersji binarnej, oferuje znacznie więcej rodzajów kerneli dostosowanych do poszczególnych procesorów (o ile pamiętam, to linux-pf występuje w 2, czy 3 wersjach i to praktycznie wyłącznie na procesory Intela).
Różnica, jaką widzę, jest wyłącznie taka, że w przypadku kerneli ck, kolejne patche są nakładane na siebie i dokładnie wiadomo jaki patch jest nakładany (czyli „upstreamowe” poprawki, ck i „graysky”), natomiast w przypadku pf mamy jeden, wielki patch, w którym wg zapewnień Natalenki jest dokładnie to samo. Nie wiem i nie bardzo chce mi się w to wnikać, albowiem nie jest mi to potrzebne. Jedyne, co mogę – i to jedynie historycznie stwierdzić – to, że patch graysky’ego miał lekko inną postać w pf niż w ck, albowiem oprócz kilku podstawowych procesorów oferował jedynie wersję „native”; nie wiem jednak, czy tak jest w dalszym ciągu).
Kiedyś różnice były dużo większe albowiem pf:
– nie oferował wszystkich patchy „upstreamowych” rządząc się tu własnymi i nie mam pojęcia jakimi regułami,
– zawierał patch UKSM,
– zawierał CK oraz BFQ, gdzie BFQ było domyślne (w CK nie było domyślnym),
– zawierał AUFS3,
– zawierał TuxOnIce.
W stosunku do „stockowego” kernela w Manjaro, główne 2 różnice są takie, że oba (ck i pf) zawierają patche CK oraz „graysky’ego” (ale ten ostatni ma sens wyłącznie przy kompilacji kernela, chyba, że ktoś – jak graysky – udostępnia wszystkie możliwości) oraz nie zawierają np. AUFS3, które są w kernelu Manjaro (podobnie jak kilku innych patchy). Są one też – w configu – nieco mniej przeładowane od kernela Manjaro.
Obecnie – gdybym miał używać któryś z tych kerneli, to używałbym ck, aczkolwiek z uwagi na błędną współpracę obecnego BFS (MuQSS) z Plasmą robić tego nie mam zamiaru.
IMO – jeśli chcesz się bawić z kernelami, to przede wszystkim warto wziąć się za budowę własnego. W pierwszej kolejności należy zacząć od poznania własnego komputera (inxi/i-nex tu są dobrymi podpowiadaczami). W drugiej kolejności dostosować odpowiednie patche do tych podzespołów (np. jeśli masz SSD, to warto zastanowić się nad zmianą na no-op lub na deadline, choć to wykonać można na „stockowym” bez kompilacji). Po trzecie posiąść wiedzę, czego nie używasz i co z kernela można wyrzucić (np. jeśli masz Intela, to na nic Ci nie są potrzebne rzeczy związane z AMD; na nic Ci też nie są potrzebne wszystkie, możliwe sterowniki np. do wifi, skoro i tak masz jeden układ, itd. itp.). Ta „tajemna” ;) wiedza jest do osiągnięcia, a co najmniej kilka osób obecnych na tym, czy na archowym, forum – buduje sobie kernele we własnym zakresie. Możemy pomóc, choć – na pewno – nikt za Ciebie nie podejmie decyzji.
I na koniec mój „tip” – zainstaluj sobie jakiś kernel np. ck. Następnie spróbuj się nim pobawić i pozmieniać jego ustawienia (inne schedulery itp.). Sprawdź co to daje u Ciebie, albowiem może się okazać, że cała zabawa nie jest warta czasu, jaki nad „dopieszczeniem” swego kernela spędzisz.
PS: Mój obecny kernel ma nakładane następujące patche:
– graysky’ego,
– UKSM,
– BFQ od Toma X Nguyena (bfq-mq),
– upstreamowy (czyli poprawkowy dla danej wersji).
Jednocześnie kernel jest odchodzony od rzeczy, które nie są mi potrzebne.
Fakt – zawsze mam też zainstalowany dodatkowy, ratunkowy kernel; od dłuższego czasu jest to linux-zen, który jest dostępny w repozytorium Archa.

Sorry, za rozpisanie się. Odpowiadając krótko na pytanie: w podstawowej wersji (generic) kernel ck i pf niczym (obecnie) nie powinny się różnić od siebie. Podobnie w wersji na dany procesor.

[pavbaranov]

No to mam strita – Manjaro zainstalowało Ci bóg jeden raczy wiedzieć po co i sterowniki do NVidii i do AMD. Ok, to jeszcze to inxi poproszę.

Tak jak pisał Robert75 – prawdopodobnie na NVidii ustawienie przy uruchamianiu DVD jako „non-free” pomogłoby z instalacją na tej (NVidia) karcie. Któż to jednak wie.

[pavbaranov]

Toxic napisał(a):

to co piszesz to teoria na karcie radeon hd7990 pod windows w CS:GO mam 200-250 FPS na sterownikach flgrx (catalyst) było 240+ ta sama karta graficzna na amdgpu-pro 50fps ? na otwartych nawet steam nie odpala więc co jest problemem sprzęt ten sam więc gdzie jest przyczyna jak nie w sterownikach ?

To nie teoria, a informacja o wsparciu dla poszczególnych GPU. Zwróć uwagę, że sterowniki dla Windows i sterowniki dla linuksa, nawet jeśli tak samo się nazywają, to dwa różne sterowniki.
Przeczytałeś w ogóle to co napisałem? Masz HD7990 – GPU oparte o technologię GCN 1 wsparcie dla tego typu GPU przez amdgpu jest jak dotychczas eksperymentalne, a amdgpu-pro – praktycznie nie istnieje. Brak wsparcia czy wsparcie eksperymentalne nie oznacza, że na linuksie nie da się takiego GPU odpalić pod amdgpu. Niekoniecznie jednak będzie to właściwe rozwiązanie.

Toxic napisał(a):

własnościowe flgrx ( catalyst, Crimson ) czy pseudo własnościowe amdgpu-pro ?

Po co się tak wymądrzasz? AMDGPU-PRO jest własnościowym sterownikiem będącym rozwiązaniem dostępnym wyłącznie na stronie AMD. Wyłącznie dla tych GPU, które są wspierane.

Toxic napisał(a):

ewentualnie kto wie jak w amdgpu-pro wyłączyć synchronizację pionową ?

Dalej nie czytasz – amdgpu-pro nie ma jeszcze wparcja dla GCN 1. To nie jest właściwy sterownik dla Radeon HD7990. Raz jeszcze, zatem:
Dla tych kart wyłącznie właściwe są sterowniki:
– ati,
– amdgpu (bez pro), ale wymaga skompilowania kernela we własnym zakresie,
– Catalyst/Crimson – ale wymaga starych Xów.
Samo użycie sterownika amdgpu wymaga jeszcze odpowiedniej konfiguracji (m.in. wyłączenia sterownika radeon, jeśli ten jest również zainstalowany).

Toxic napisał(a):

Do tego dodam, iż na sterownikach amdgpu-pro karta graficzna działa tak jak by w trybie iddle i zegary ma 350/450 zamiast 1050/1125. Ktoś ma jakieś pomysły ? czy szukać jakiegoś strszego wydania innego linuxa który wspiera flgrx ? i ewentualnie AMD Overdrive żeby na sztywno ustawić maxymalne zegary ?

Tak mamy pomysł – stosuj sterownik dostosowany do swojego GPU. W Manjaro system sam Ci podpowie jakie masz możliwości instalacji. W Twoim przypadku do wyboru winien być albo ati (otwarty) albo Catalyst (zamknięty). Jeśli jest inaczej, to mhwd w tym zakresie jest wadliwe.

Toxic napisał(a):

z tego Piszesz w tym punkcie to w Manjoro 17 są one dostępne ? czy szukać starszej wersji

Z tego co piszę wynika, że powineneś nieco czasu spędzić nad poznaniem swojego systemu i sposobu instalacji w nim sterowników. Stosowny tekst jest na wiki.manjaro.org
O ile wiem, to w Manjaro 17 Catalyst winien jeszcze być (choć nie wiadomo jak długo będzie jeszcze wspierany). Jeśli go już nie ma, to nie należy go używać – rozbieżność między Xami, a Catalystem z wydania na wydanie tych pierwszych coraz większa, a nie zawsze będzie można utrzymać stare Xy.

[Toxic]

własnościowe flgrx ( catalyst, Crimson ) czy pseudo własnościowe amdgpu-pro ? ewentualnie kto wie jak w amdgpu-pro wyłączyć synchronizację pionową ? bo w większości przypadków takie krojenie FPS poniżej częstotliwości odświerzania monitora jest spowodowana właśnie synchronizacją pionową włączoną w sterownikach

Do tego dodam, iż na sterownikach amdgpu-pro karta graficzna działa tak jak by w trybie iddle i zegary ma 350/450 zamiast 1050/1125. Ktoś ma jakieś pomysły ? czy szukać jakiegoś strszego wydania innego linuxa który wspiera flgrx ? i ewentualnie AMD Overdrive żeby na sztywno ustawić maxymalne zegary ?

Catalyst/Crimson – sterowniki nierozwijane od końca 2015 r. i wymagające starszych Xów; w Archu porzucone wsparcie bodaj w 2014 roku ze względu na ich olbrzymią problematyczność w przypadku systemów rolling release; obecnie dostępne wyłącznie w starszych dystrybucjach (także LTS) oraz w Manjaro; sterowniki te obsługują część starszych kart AMD (HD5000-HD6000) oraz karty GCN 1, 2 i 3; nie obsługuje kart GCN 4 i nowszych

z tego Piszesz w tym punkcie to w Manjoro 17 są one dostępne ? czy szukać starszej wersji

[pavbaranov]

Czy przeczytałeś to co napisałeś? Staraj się pisać po polsku i w sposób ogólnie zrozumiały.
Sterowniki AMD:
– otwarte:
— ati – dla praktycznie wszystkich kart do GCN 2
— amdgpu – dla kart GCCN 3 i 4; eksperymentalne wsparcie dla GCN 1 i 2 (trzeba najczęściej przebudować kernel, albowiem nie są w nim włączane funkcje eksperymentalne); sens używania amdgpu na GCN 1 i 2 jest zresztą obecnie jeszcze niewielka, albowiem – przynajmniej w moim przypadku – osiągają gorszą wydajność od ati; nie jest przewidywane, by AMD zrobiło ten sterownik dla architektur starszych niż GCN
– zamknęte:
— Catalyst/Crimson – sterowniki nierozwijane od końca 2015 r. i wymagające starszych Xów; w Archu porzucone wsparcie bodaj w 2014 roku ze względu na ich olbrzymią problematyczność w przypadku systemów rolling release; obecnie dostępne wyłącznie w starszych dystrybucjach (także LTS) oraz w Manjaro; sterowniki te obsługują część starszych kart AMD (HD5000-HD6000) oraz karty GCN 1, 2 i 3; nie obsługuje kart GCN 4 i nowszych
— amdgpu-pro – nowe sterowniki zamknięte rozwijane wyłącznie dla kart GCN 3 i 4; nie jest przewidywane by AMD zrobiło te sterowniki dla kart starszych niż GCN; nie wiadomo czy pokusi się o objęcie nimi również GCN 1 i 2.
— catalyst-legacy – stare sterowniki dla kart HD2000-HD3000 – nie wiem, czy jeszcze gdziekolwiek jest on poważnie wspierany,
— dla kart starszych od HD2000 nie ma sterowników własnościowych.
Sterowniki otwarte (ati) oraz Catalyst we wszelkich testach przeprowadzanych przez Phoronix uzyskują obecnie podobną wydajność dla kart, dla których są właściwe. Dla GCN 3 zdaje się że również nowe, otwarte amdgpu wypadły porównywalnie do Catalyst.
Pamiętaj, że wydajność karty, to nie tylko sterownik, ale również kernel, Xy i ustawienia sterownika.
Jeśli chcesz zatem zainstalować amdgpu-pro musisz mieć kartę opartą o architekturę GCN 3 lub GCN 4.
W Manjaro są dostępne sterowniki: ati, amdgpu oraz catalyst. O ile wiem, to amdgpu-pro jest dostępny (i będzie dostępny) wyłącznie w AUR.

[Toxic]

Witam czy najnowsza wersja posiada wsparcie własno ściowych sterowników AMD flgrx ? ponieważ czasami chciał bym pograć na linuxie a sterownikach amdgpu-pro w grach moja karta jest o połowę mniej wydajna niż kiedyś jak korzystałem z ARCH linux który wspierał właśnie własnościowe sterowniki AMD

[aquila]

1. Jeśli nie masz stwórz wpis odzyskiwania (recovery) by można łatwo przywrócić system.
Otwórz /etc/default/grub i w linijce GRUB_DISABLE_RECOVERY=”true” zmień na false.
Zapisz, zamknij, przeładuj gruba:

sudo update-grub

2. Odinstaluj sterownik:

sudo mhwd -r video-hybrid-intel-ati-bumblebee

3. Zainstaluj oddzielnie sterowniki dla obu kart:

sudo pacman -S xf86-video-ati xf86-video-intel

Restart.

4. I jeśli system wstanie :D to co pokaże:

xrandr --listproviders

Przeczytaj.

Bad Tux | Spacja przed "?" | Aquila