A jakie to "rozwiązania" decydują o poprawnym przypisaniu sterownika grafiki ?
Sterowniki własnościowe czy otwartoźródłowe - który sterownik będzie tym właściwym ?
No właśnie. AMD. Tu nie ma problemu własnościowe vs. otwarte, albowiem dla znakomitej większości dystrybucji istnieje wyłącznie sterownik otwarty. Oczywiście AMD produkuje sterowniki własnościowe, tylko, że z zarzuconym obecnie Catalyst (obsługuje karty do GCN2 włącznie i nie obsługuje najstarszych rozwiązań) jest ten problem, że na współczesnych wersjach Xów oraz kernelu po prostu nie uruchomi się (obsługiwane są xserver 1.17.x oraz kernele do 4.17). Natomiast dla kart z serii GCN jest również AMDGPU-PRO, ale ten produkowany jest bodaj dla dwu dystrybucji (też zresztą ma swoje ograniczenia jeśli chodzi o wersje wyżej wspomnianych komponentów). Na wszelkich zatem popularnych, czy w miarę popularnych dystrybucjach, o tych rozwiązaniach można zapomnieć. Dodatkowo AMDGPU-PRO jest specyficznym sterownikiem, do specyficznych zastosowań (niekoniecznie na celu ma poprawne wyświetlanie grafiki). AMD wszystkim ZU proponuje rozwiązania otwarte, których zresztą jest twórcą.
W przypadku sterowników ati/radeon oraz amdgpu mówimy zresztą wyłącznie o sterowniku tzw. akceleracji 2D. Za akcelerację 3D odpowiada w takim przypadku mesa. Podstawowy sterownik - tak CPU, jak i GPU dla AMD znajduje się w kernelu (i ta część kernela dostarczana jest przez AMD). To jednak początek sukcesu.
Po pierwsze by określony procesor AMD (CPU, GPU, APU) działał w linuksie musisz mu zapewnić:
- wersję kernela, która taki procesor obsługuje,
- wersję firmware'u, który taki procesor obsługuje,
- wersja ucode,
- podniesienie ucode przed podniesieniem kernela.
I tu zaczynają się schody, albowiem cykl wydawniczy tak kernela, jak i firmware'u nie pokrywa się z cyklem wydawniczym AMD. O ile jeszcze nowy firmware pojawia się mniej więcej gdy jest on dostarczony, to z kernelem bywa różnie, albowiem bywało, że od dostarczenia kodu przez AMD do pojawienia się wersji kernela w pełni obsługującej sprzęt, którego ten kod dotyczy mijały 2-3 wydania kernela. Z reguły też ów kod nie trafi do wcześniejszych wydań kerneli. Nawet do LTS. Jeśli zatem np. linia 4.19 wychodząc nie potrafiła się poprawnie dogadać z APU, który tak jak w tym przypadku pojawił się ok. rok temu (nie potrafiła, bowiem gdy się pojawiła 4.19, to to APU jeszcze nie istniało), to pomimo tego, że odpowiedni kod pojawił się i został zaimplementowany (pytanie czy w całości) w wersji 5.4, to odpowiednia partia kodu nie trafi do wersji 4.19 (i ogólnie wcześniejszej niż 5.4). I cały czas mówimy o tzw. upstreamie.
Aby zatem jakiś procesor mógł być odpowiednio obsłużony, to nie tylko w upstream musi istnieć odpowiedni kod, ale również rozwiązania upstreamu muszą znaleźć się w dystrybucji. I tu muszą został łącznie spełnione następujące warunki:
- kernel w odpowiedniej wersji,
- firmware w odpowiedniej wersji
(i pomijam już odpowiednie wersje Xów, mesy, czy sterowników 2D; w tym ostatnim przypadku ostatecznie wbudowany w kernel modesetting winien dać sobie radę).
Nadto jeśli dana dystrybucja ma zautomatyzowany proces ustawiania "sterowników" pod określony procesor, to musi go prawidłowo rozpoznać, a to najczęściej jest czynione na podstawie mechanizmu, który potrafi rozpoznać tzw. idVendor i idProduct urządzenia (CPU) i w zależności od tego przyporządkować mu odpowiedni "układ" instalowanych komponentów. Jeśli rozpoznany będzie idVendor (bo to najczęściej tak - idVendor dla AMD się nie zmienia), ale nie zostanie rozpoznany idProduct (bo go po prostu ktoś nie dopisał), to system może zwariować. Stąd bardzo często to rozpoznanie nie jest do końca poprawne i systemy takie albo odmawiają współpracy w ogóle, albo działają "na pół gwizdka". Zwłaszcza te, które wydawane są (albo nawet tworzone) przed pojawieniem się danego układu. Tutaj nawet wersje poprawkowe takich dystrybucji niekiedy nie muszą wnieść poprawy swej współpracy z takim procesorem.
W przypadku zatem AMD problem "własnościowe vs. otwarte" nie istnieje raczej. Istnieje natomiast problem, czy dany układ, w danej dystrybucji jest obsługiwany w sposób w pełni poprawny.
Na drugim krańcu leżą dystrybucje tego typu jak Arch, które zasadniczo winny mieć wszystkie współczesne komponenty, które winny umożliwić współpracę z danym CPU/GPU/APU (oczywiście o ile ona jest już zaimplementowana), tyle, że te rozwiązania najczęściej wymagają sporo wiedzy od użytkownika, który to sam ustawia. Niekiedy sama wiedza nie wystarczy, bowiem do prawidłowego działania trzeba dojść metodą prób i błędów (np. raz tzw. KMS early start będzie z korzyścią w danym układzie, a w innym przypadku trzeba to pominąć). Tutaj jednak słowo klucz, to wiedza użytkownika. Samo się nie zrobi (oczywiście z założeniem, że w ogóle aktualne wersje wspomnianych komponentów obsłużą już dany CPU/GPU/APU oraz nie mają one błędów). Trzeba np. wiedzieć, że samo zainstalowanie mikrokodu w systemie w cudowny sposób nie spowoduje, że ewentualny problem zniknie. Trzeba jeszcze przebudować obraz kernela (nie zbudować kernel!), który jest ładowany przy starcie. Same sterowniki 2D/3D (zwłaszcza te ostatnie) niekoniecznie spowodują, że akceleracja zostanie uruchomiona, bowiem najczęściej wymagana będzie jeszcze instalacja dodatkowych paczek (libva lub vdpau; tak z tej drugiej technologii także GPU AMD potrafi skorzystać) i ewentualne jeszcze skonfigurowanie. Także obsługa H.264 niekoniecznie "sama się pojawi".
I w zasadzie tyle. W przypadku tych otwartych rozwiązań AMD nie istnieje ten problem, który występuje w przypadku NVidia, tj. dokonania wyboru między nouveau, a - odpowiednią w dodatku - wersją nvidia. Nie istnieje problem odpowiedniej współpracy sterownika z innymi komponentami (Xy, Mesa, kernel), albowiem sterowniki AMD po prostu w tych rozwiązaniach są. Mogą natomiast w danej wersji jeszcze nie obsługiwać określonego CPU, GPU czy APU.
Athlon 300U zawiera w sobie Vega 3 - bodajże od kernela 4.19 akurat podsystem grafiki tego procesora winien być obsługiwany. Sam procesor ma te same instrukcje co bodajże Ryzen serii 2xxx. Również gdzieś zatem w okolicach 4.19 powinna wejść jego obsługa (jeśli to jednak wyższa seria Ryzena, to późniejsze procesory). Problem może się pojawić zatem w firmware (i tu nie znam nazwy kodowej tego Athlona, by sprawdzić), uucode oraz - przede wszystkim - w przypadku wszelkiej maści instalatorów, "pomocników" konfiguracji itp. w tym, że jego "namiary" nie zostały tam dopisane i po prostu system nie rozpozna go właściwie.
O samym Athlon 300U piszą, że odstał on wsparcie w 5.4, ale jeszcze co najmniej w wersji 5.4.8 sprawiał problemy (jak jest w obecnej 23 - nie wiem, nie chce mi się tego szukać, wszak nie mam takiego procesora i strata to czasu dla mnie). Gdzieś też było info, że dopiero w 5.5 pojawiła się jego poprawna obsługa (jednak jeśli poprawna obsługa pojawiła się w 5.5, to oznaczać może, że trafi/-ła ona również, do 5.4, albowiem stosowny podsystem w 5.4 już jest i najczęściej w takim przypadku poprawki są robione dla wszystkich linii kernela, które taki podsystem mają, czyli winny być w 5.4, 5.5 i nadchodzącym 5.6).
Ufff... koniec.
@Predator - Być może Tobie się zdaje, że powinnością innych użytkowników forum jest wpisywanie Tobie informacji, które są powszechnie dostępne, a po które Tobie nie chce się sięgnąć. Mylisz się.
