Wine+Playonlinux – problemy.

[azja]

… w wierszach 33,34 i 56 make wyrzuca error’y. Wcześniej, w wierszach 19,24 i 30 pojawia się komunikat sugerujący błędy w składni źródeł (zapewne, to jest źródło problemu): … has no left operand. Pytanie – czy i jakie ma, to znaczenie (nie jestem programistą, więc nawet nie mogę tego oszacować), bo instalacja kończy się komunikatem o sukcesie. Poza tym, i tak trzeba by zajrzeć do wskazywanych plików i sprawdzić o co dokładnie chodzi. Ale, to robota dla programisty.
… pomijając błędy przy instalacji – chodzi?

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

[loctor]

pavbaranov napisał(a):

Bez owego „make.log” nic nikt

Podałem go na screenie, brakuje tylko kilku pierwszych linii.
Tak wygląda cały:

DKMS make.log for amdgpu-pro-17.10-401251 for kernel 4.9.44-1-MANJARO (x86_64)
nie, 27 sie 2017, 11:08:22 CEST
make: Wejście do katalogu '/usr/lib/modules/4.9.44-1-MANJARO/build'
  LD      /var/lib/dkms/amdgpu-pro-17.10/401251/build/built-in.o
  LD      /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/built-in.o
  LD      /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/built-in.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_drm.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/main.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/amdgpu_drv.o
  LD      /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/built-in.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_memory.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/symbols.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_fence.o
In file included from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../amdgpu/amdgpu_ttm.h:27:0,
                 from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../amdgpu/amdgpu.h:54,
                 from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../backport/include/kcl/kcl_amdgpu.h:5,
                 from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../backport/backport.h:5,
                 from <command-line>:0:
/var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../scheduler/gpu_scheduler.h:27:49: error: operator '==' has no left operand
 #if (defined OS_NAME_RHEL) && (OS_VERSION_MAJOR == 6)
                                                 ^~
In file included from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../backport/backport.h:14:0,
                 from <command-line>:0:
/var/lib/dkms/amdgpu-pro-17.10/401251/build/include/kcl/kcl_acpi.h:8:49: error: operator '<=' has no left operand
 #if (defined OS_NAME_RHEL) && (OS_VERSION_MAJOR <= 6)
                                                 ^~
In file included from /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/../backport/backport.h:16:0,
                 from <command-line>:0:
/var/lib/dkms/amdgpu-pro-17.10/401251/build/include/kcl/kcl_hwmon.h: In function ‘kcl_hwmon_device_register_with_groups’:
/var/lib/dkms/amdgpu-pro-17.10/401251/build/include/kcl/kcl_hwmon.h:15:49: error: operator '<=' has no left operand
 #if (defined OS_NAME_RHEL) && (OS_VERSION_MAJOR <= 6)
                                                 ^~
make[2]: *** [scripts/Makefile.build:293: /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu/amdgpu_drv.o] Błąd 1
make[1]: *** [scripts/Makefile.build:544: /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdgpu] Błąd 2
make[1]: *** Oczekiwanie na niezakończone zadania....
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_fence_array.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_kthread.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_tt.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_io.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_mn.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_reservation.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/kcl_drm_global.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_bo.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_bo_util.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_bo_vm.o
  LD [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/amd/amdkcl/amdkcl.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_module.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_object.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_lock.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_execbuf_util.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_page_alloc.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_bo_manager.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_page_alloc_dma.o
  CC [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/ttm_agp_backend.o
  LD [M]  /var/lib/dkms/amdgpu-pro-17.10/401251/build/ttm/amdttm.o
make: *** [Makefile:1493: _module_/var/lib/dkms/amdgpu-pro-17.10/401251/build] Błąd 2
make: Opuszczenie katalogu '/usr/lib/modules/4.9.44-1-MANJARO/build'

azja napisał(a):

… pomijając błędy przy instalacji – chodzi?

Nie. Nadal aktywnym sterownikiem jest video-amdgpu.

[azja]

… a czy w ogóle masz pakiet amdgpu-pro zainstalowany w systemie? Czy komunikat o sukcesie był prawdziwy?

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

[loctor]

Komunikat o sukcesie był prawdziwy. Nie modyfikowałem screena w photoshopie jeśli o to chodzi.
Pakiet amdgpu-pro-dkms jest w Pamacu oznaczony na zielono jako zainstalowany ale inxi -Gi mhwd -l -d --pci informują, że sterownikiem grafiki w systemie jest video-amdgpu.

[azja]

… ha ha ha, fotoszopy nie takie rzeczy widziały ;-)
Miałem na myśli, to czy tylko powiedział, że zainstalował, czy również zainstalował. Piszesz, że
mhwd -l -d --pci
zwraca video-amdgpu jako zainstalowany. A co mówi o dostępnych? Widzi amdgpu-pro?
————-
EDIT … i jeszcze:
dkms status
————-

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

[loctor]

Nope, nie widzi. Dostępne są tylko video-amdgpu i video-vesa.
I jeszcze:

dkms status
amdgpu-pro-17.10, 401251: added

[azja]

… tak podejrzewałem, że mhwd nie zobaczy, bo to poza nim było robione. Ale trzeba było sprawdzić. Jesteśmy na dobrej drodze do domu – dkms widzi zainstalowany moduł. Teraz trzeba tylko dowiedzieć się, w jaki sposób go aktywować, uruchomić, etc. Nie używam dkms, więc praktyki nie mam i nie mam na czym sprawdzić, ale zacznijmy od:
http://www.linuxjournal.com/article/6896
https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support
… spróbuj poczytać (szczególnie ten pierwszy link, dość dokładnie opisuje działanie dkms i możliwe/niezbędne operacje). Wygląda na to, że masz za sobą ’add’, teraz czeka Cię ’build’ i ’install’ – jeżeli, to jest takie jak wygląda, to nie powinno być problemu, dwie komendy i z głowy. Ja już dzisiaj odpadam.

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

[pavbaranov]

@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.

[loctor]

Panowie.
Przyznaje bez bicia, że pogubiłem się w tym wszystkim jakieś dwie strony temu i cała sytuacja od tego momentu przypomina trochę kopanie się z koniem i to podkutym. Mimo waszych rad nie wygram tego starcia z moją wiedzą i doświadczeniem a ma to takie znaczenie, że nie rozumiem nawet połowy tego co czytam w podlinkowanych stronach. Za dużo tu programistycznego żargonu, szermowania coraz to wymyślniejszymi nazwami pakietów, mnożenia ich w nieskończoność i komplikowania rzeczy, wydawałoby się, stosunkowo prostych. Czytając wpisy i komentarze na githubie czy stronach AUR widać że developerzy są w swoim żywiole, szkoda tylko, że w tym całym „zapale tworzenia” stracili z oczu najważniejsze – użytkownika. Tego zwykłego użytkownika, który chciałby po prostu zainstalować np. sterownik i cieszyć się tym czy tamtym z jego wykorzystaniem.
Pomarudziłem, teraz do rzeczy. Straciłem serce do dalszej walki z tym sterownikiem więc odpuszczam. Może kiedyś AMD doprowadzi swój otwarty sterownik do stanu pełnej używalności a jak nie to trudno, chcąc pograć przełączę się na Windowsa.

[pavbaranov]

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.

[azja]

… @loctor -> plasuję się gdzieś pośrodku, pomiędzy Tobą, a @pavbaranov; zarówno z poziomem wiedzy, jak i punktem widzenia. Rozumiem, to o czym pisze @pavbaranov, czytam ze zrozumieniem (mniejszym lub większym) strony z wiki i forum, ale uważam, że powinno być tak, jak to wygląda z Twojego punktu widzenia. Ale!, nie można mieć wszystkiego. Dysponujemy dobrym systemem, stabilnym, nowoczesnym, bogatym w funkcjonalność – wszystko to za darmo, a dokładniej za cenę pracy milionów zapaleńców. Nie obejmuje on całego informatycznego ekosystemu (podobnie jak rozwiązania płatne) i pewne rozwiązania wymagają naszego wzmożonego wysiłku. Każdy sam ustala, gdzie jest jego granica, której nie chce przekraczać, bo żyłki mu popękają albo nie chce mu się, albo cokolwiek.
… poukładaj sobie systemy na dysku (masz oba na tym samym dysku?), zmniejsz Windows do niezbędnej objętości (odinstaluj nieużywane oprogramowanie i zmniejsz rozmiar partycji, aby nie marnować miejsca), wrzuć Microsof’ta do manjaro’wego Grub’a i ciesz się wolnością korzystania z najlepszego dostępnego rozwiązania dla danej funkcjonalności.
… co do samego Manjaro, to jeżeli chcesz zmniejszyć prawdopodobieństwo ręcznej ingerencji w system, to:
# skup się na repozytoriach systemowych;
# w razie niezbędnej konieczności, instaluj rozważnie z AUR;
# unikaj innych źródeł oprogramowania;
# jeżeli nie znajdziesz, tego czego potrzebujesz, w repozytoriach systemowych czy AUR, a masz taką ważną potrzebę, to poczytaj sobie nt. rozwiązań kontenerowych i korzystaj z nich/któregoś z nich (dla przykładu, DWA z nich; materiału na ten temat w net’cie jest od metra), bo nie musisz ingerować w system.
… problemu nie rozwiązaliśmy, ale poszerzyłem swoją wiedzę, więc jestem zadowolony. Dziękuję Panowie za współudział w tym incydencie..

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

[pavbaranov]

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.

[azja]

… no i pięknie. Ładne podsumowanie/zestawienie. Gdy ktoś trafi tutaj, w poszukiwaniu wiedzy na ten temat, to na pewno będzie usatysfakcjonowany. Tak jak ja – aż wrzuciłem text do swojej prywatnej KB.

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

[loctor]

@pavbaranov
Wybornie zwięzłe i treściwe podsumowanie.
Pozwolę sobie jednak rozgrzebać coś co podnosiłeś kilka razy – chodzi o akcelerację sprzętową.
Link, który podałeś zawiera informacje na temat pakietów VAAPI i VDPAU. Oba odpowiadają za sprzętowe wspomaganie video a więc kodowanie/dekodowanie materiałów video. Z grami nie ma to nic wspólnego – tu raczej chodzi o akceleracje 3D. O ile wiem w linuxach odpowiada za to OpenGL ale chyba tylko dla natywnie działających aplikacji. W Wine teoretycznie instaluje się DirectX i to on powinien odpowidać za aplikacje nienatywne, uruchamiane przez Wine. Nie wiem niestety jaka jest korelacja między DirectX/Wine a OpenGL/amdgpu ale wydaje się, że u mnie one się nie dogadują. Co ciekawe gdzieś obiło mi się o oczy, że i KDE może mieć jakiś w tym udział. Niestety jak pisałem nie widzę w Manjaro niczego na kształt panelu sterowania, który dałby jasny wgląd w bieżącą konfiguracje karty/sterownika i ewentualną możliwość korekcji ustawień.

Wracając na chwilę do VAAPI I VDPAU to były one u mnie włączone prawdopodobnie defaultowo. Ręcznie ich nie włączałem ale mam teraz w Manjaro taki bałagan przez boje z amdgpu-pro, że głowy nie dam. W każdym razie oba są zainstalowane i działają.

Jeśli gdzieś plotę bzdury, proszę mnie poprawić.

[pavbaranov]

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).

[Autor]

Posty