Az openSUSE dobja az AMD/ATI Catalyst bináris driver (fglrx) rpm támogatást

openSUSE, SUSE, SLES

Úgy tűnik, hogy az openSUSE (is) rájött, hogy a zárt forrású, bináris AMD/ATI driver (ismertebb nevén fglrx) egy "döglött ló". A projekt részéről Bruno Friedmann a napokban bejelentette, hogy dobják az proprietary fglrx driver rpm támogatását:

Say goodbye fglrx!, repeat after me, goodbye fglrx.

Sőt, nem csak, hogy röpül az fglrx, de úgy tűnik, hogy a szintén zárt forrású amd-gpu-pro driver sem lesz hivatalosan támogatott:

Yeap there’s a closed driver, called amd-gpu-pro, available, for newer cards. But there’s two things that bring me out of the game, first I don’t have those newer gpu,
and don’t have the need to replace my hd5750 for the moment. The second and certainly the most important, those drivers are only available for Ubuntu or at least in .deb format.

I will certainly not help proprietary crap, if I don’t have a solid base to work with, and a bit of help from their side. I wish good luck to those who want to try those drivers,
I’ve got a look inside, and got a blame face.

Részletek itt.

( Polesz v | 2016. 12. 11., v – 10:21 )

Csodálkozik valaki? Az Xorg 1.20-nál tart, az fglrx driver meg az 1.17-et támogatja. Downgrade? Nem megoldás. Akkor marad a nyílt driver, vagy Nvidia kártya beszerelés, ha lehetséges.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Szerintem senki. Én az elmúlt ~ 15 évben egyetlen egyszer gyengültem meg és egyszer vettem NVIDIA helyett AMD kártyát. Annyit duruzsoltak, hogy ilyen meg olyan jó. Aham. Soha többet. Most is NVIDIA van a gépben. Amíg az AMD-nek ilyen a hozzáállása, húzza a kártyáját a pélójára, aztán pörgesse.

--
trey @ gépház

tl;dr: szeretnek upstreamelni a drivert, de red hat-es autistak miatt nehez

Több éve dolgozom a Red Hat-nél, úgyhogy a fentit nem tudom szó nélkül hagyni. Dave nem közvetlen kollégám (nem grafika / desktop területen vagyok), úgyhogy ezt a hozzászólást abszolút a saját szakállamra írom. A nyílt forrású fejlesztési modell-lel azonban napi tapasztalatom van.

A tények fenti összegzése ("autisták") minimum durva rosszulinformáltság (rosszabb esetben szimpla gonoszkodás, amit nem tudok hova tenni).

Egy hardvergyártónak, ha támogatni akarja a Linux kernelt, és jól, több lehetősége van. Ezek közül neveznék meg négyet.

  1. Megírja a drivert, beküldi az lkml-re, ill. a megfelelő alrendszeri listára. Együttműködik a reviewer-ekkel és a maintainerekkel. Néhány próbálkozás után a drivert beolvasztják. Az összes olyan jövőbeni API változtatás, amely a driver alatti rétegeket érinti, automatikusan átvezetésre kerül a driver-ben is. Regressziók sajnos vannak, de ez az upstream CI hiányossága, nem a fejlesztési modellé. Ez a módszer nagyon sok munkát igényel a driver szerzőjétől, utána viszont nagyon kényelmes.
  2. Megírja a drivert, nyílt forrással, de nem küldi be. Folyamatosan dolgozik azon, hogy a driver naprakész legyen a legfrissebb upstream (mainline, vagy valamelyik long term) kernel kiadáshoz.
  3. Megírja a drivert, de a forrást nem adja ki. Különféle homályos taktikákkal kerülgeti / maszatolja a GPL sértést. Folyamatosan dolgozik azon, hogy a (zárt forrású, proprietary) driver naprakész legyen a legfrissebb upstream (mainline, vagy valamelyik long term) kernel kiadáshoz.
  4. Megírja a drivert kifejezetten olyan GNU/Linux disztribúciók számára, amelyek valamilyen API/ABI garanciát vállalnak, valamekkora időintervallumra. (Az upstream kernel semmi ilyet nem nyújt.) A disztribúció következő minor release-énél a modulokat nem kell újrafordítani, major release-nél viszont a gyártótól új (friss) modulok kellenek a felhasználóknak.

Az NVIDIA a harmadik opciót követi, hosszú idő óta. Ez számukra kényelmes, mert a driver belsejébe nem dumál bele senki, ugyanakkor a GPL sértés esélyes, illetve rengeteg munkájukba kerül az állandó forward porting.

A grsecurity a második opciót követi. (Természetesen tudom, hogy a grsecurity nem egy "driver", de a modell illusztrálására megfelel.) Teljesen érvényes fejlesztési módszer.

Az AMD ebben az esetben egyik modellt sem követi.

A negyedik módszert kizárhatjuk, mivel eleve az upstream kernel a céljuk (nagyon helyesen, mellesleg).

A harmadik módszert szintén kizárhatjuk, mert nyílt forrásban gondolkoznak (köszönet illeti őket érte).

Az első módszert az AMD nem követi. Februárban megmondták nekik a DRI / gfx maintainer-ek, hogy a Linux kernelben a driver-eknek tilos közbülső absztrakciós réteget alkalmazniuk (vagyis amikor a kernel segédfüggvényeit, meglévő infrastruktúráját egy vendor-specifikus development API-vá transzformálják, majd a lényegi drivert erre a vendor API-ra építik rá). Ez akkor is tilos, ha egyébként a driver en bloc nyílt forrású. A lényegi drivert közvetlenül a Linux API-kra, Linux infrastruktúrára kell építeni.

A közbülső réteg tilalmának két oka van: (a) rengeteg felesleges kódot jelentene, (b) a belső kernel API-k változásainak automatikus átvezetése a driver-ben lényegében lehetetlenné válna, ha a lényegi driver kód frissítése helyett egy bonyolult (jelen esetben >100kloc) közbülső réteget kell először megreszelni. A közbülső réteg önmagában nem csinál semmit, nincs célja, ráadásul megváltoztathatatlan (a vendor pont azért vezette be, hogy számára stabilitást nyújtson -- a kernelben pont ez tilos, mert megkövülnek tőle az absztrakciós rétegek). A belső API változások csak akkor propagálhatók rendesen, ha a 3rd party fejlesztő érti, hogy a lényegi driver mit csinál; ezt a közbülső vendor API pedig akadályozza.

Természetesen az AMD számára van értelme a közbülső kernel-absztrakciós rétegnek (hiszen Windows-ra is van driver, és csak a kernel-absztrakciós réteg különbözik, a lényegi driver ugyanaz). A Linux karbantartók számára ez lényegtelen, az ő feladatuk a Linux kernel karbantartása, nem X vagy Y vendor számára a munka megkönnyítése.

Február óta az AMD a közbülső réteget vékonyította, de nem szüntette meg. Ez a fő oka annak, hogy a drivert nem fogadta el Dave. Nem vállalhat felelősséget egy közbülső vendor API hosszú távú karbantartásáért.

Az AMD a második módszert sem követi. Ugyanis a grsec-től és az NVIDIA-tól eltérően arra sincs erőforrásuk, hogy a (nyílt forrású, out-of-tree) drivert hosszú távon forward portolják.

Az sajnos nem megy, hogy a hosszútávú karbantartást a kernel maintainer-ekre szeretnék bízni, de a kezdeti nagy energiabefektetést (a közbülső réteg komplett eliminálását) nem tudják vállalni. Pontosabban: nem is akarják (ahogy olvastam a listán), mert a belső validációs és QA rendszereik is a közbülső réteget használják. Tehát egy 100%-ban tiszta Linux driver (amit a kernel maintainer-ek akarnak -- teljes joggal, tegyük hozzá) az AMD számára egy külön belső development stream-et jelentene, amire szintén nincs erőforrásuk.

Ez a végfelhasználók számára elég kellemetlen, de a helyzet az, hogy mindkét oldalnak igaza van, a saját szemszögéből. Az AMD számára nyitva áll az út, hogy megtartsa a közbülső réteget, de akkor a 2. opciót kell választania.

Sokan hajlamosak azt hinni, hogy a nyílt forrású fejlesztés "olcsó". Egyáltalán nem olcsó; bizonyos esetben a kezdeti befektetés (az upstream-elés) sokkal drágább, mert olyan igényeknek is meg kell felelni, amelyek a vendor számára érdektelenek. Alapvetően az ötlet az, hogy a vendor a nyílt forrású közösség munkájából később profitálni fog. Ezt árnyalja az adott alrendszer / terület, illetve a vendor üzleti modellje. (Ld. ismét NVIDIA és grsecurity, akiknek a hosszú távú out-of-tree karbantartás sokkal jobban megfelel, mint az upstreaming.)

Szerk.: a fenti természetesen magánvélemény, nem céges állásfoglalás.

"A közbülső réteg tilalmának két oka van: (a) rengeteg felesleges kódot jelentene, (b) a belső kernel API-k változásainak automatikus átvezetése a driver-ben lényegében lehetetlenné válna, ha a lényegi driver kód frissítése helyett egy bonyolult (jelen esetben >100kloc) közbülső réteget kell először megreszelni. A közbülső réteg önmagában nem csinál semmit, nincs célja, ráadásul megváltoztathatatlan (a vendor pont azért vezette be, hogy számára stabilitást nyújtson -- a kernelben pont ez tilos, mert megkövülnek tőle az absztrakciós rétegek). A belső API változások csak akkor propagálhatók rendesen, ha a 3rd party fejlesztő érti, hogy a lényegi driver mit csinál; ezt a közbülső vendor API pedig akadályozza."

WTF

Először is, nyilván nem felesleges, és csinál is valamit, különben nem lenne probléma megszüntetni. :) Másodszor, nem igazán sikerült megérteni az absztrakciós réteg lényegét: pont azért van, hogy elfedje az implementációs részleteket. Egy 3rd party fejlesztőnek nem is kell megértenie, mit csinál a driver, elég, ha az absztrakciós réteget megérti és biztosítja, hogy az általa nyújtott funkcionalitás ne változzon.

Az AMD helyében én is ebbe az irányba indultam volna, ha már van egy kódbázisom (ami feltételezem, hogy nagyságrendekkel nagyobb, mint az absztrakciós réteg), amit integrálnom kell egy nem túl stabil API-val, akkor én is megpróbálnám elfedni azt. Erre az OOP világban még nevesített design patternek is vannak: Adapter, Facade. A hasznosságát meg jól mutatja, hogy még a tesztelést is megkönnyíti.

Először is, nyilván nem felesleges, és csinál is valamit, különben nem lenne probléma megszüntetni

A Linux kernel szempontjából felesleges. A lényegi driver kód elől elrejti azt a tényt, hogy Linuxon fut. Az AMD számára ez hasznos, a Linux kernel karbantartók szempontjából ballaszt / hátrány.

nem igazán sikerült megérteni az absztrakciós réteg lényegét: pont azért van, hogy elfedje az implementációs részleteket.

De, sikerült megérteni. A Linux vs. Windows implementációs részletek elfedése az AMD számára hasznos, a kernel karbantartók és 3rd party Linux fejlesztők számára hátrányos. Amikor egy független DRI fejlesztő a driver forrásában olyanokat lát, hogy kmalloc(), ioremap(), queue_delayed_work(), akkor tudja, hogy miről van szó. Amikor ezek helyett olyan függvényhívásokat lát, amelyek csak az AMD számára jelentenek valamit, akkor utána kell vadásznia minden alapvető lépésnek.

A kernelben rengeteg vendor rengeteg kártyájához van driver, nyilván kizárt dolog, hogy mindegyik vendor a saját belső fejlesztésű, több százezer soros framework-jét tolja bele a kernelbe, a közös kernel-infrastruktúra elfedésére.

Egy 3rd party fejlesztőnek nem is kell megértenie, mit csinál a driver

Viccelsz? Sarkítok, de például gondolj arra, hogy a fenti három "workhorse" függvény egyikének módosítják a prototípusát. A módosítást az összes call site-on át kell vezetni. Vannak hívások, ahol ez könnyű, van azonban olyan hely is, ahol ez közvetlenül nem lehetséges, és a hívó kódban egy szélesebb környezetre kiterjedő változtatást kell végrehajtani. Abban az esetben, ha a 3rd party fejlesztő megérti (megértheti) a hívó kódot (= a drivert), akkor legalább van esélye, hogy a változtatást a hívó driver minimális átszervezésével megoldja.

Ha azonban van egy közbülső Linux/Windows absztrakciós réteg, akkor annak a külső felülete (ami a lényegi driver felé néz) megköti a fejlesztő kezét. Így (a) vagy nem tudja megoldani a változtatást, (b) vagy átvezeti a közbülső rétegen is a változtatást a lényegi driver-ig, ami ugyanaz, mint a fenti eset, csak több (= felesleges) munka, (c) vagy külön kompatibilitási kódot ír, amely eleinte (egy rövid ideig) esetleg jól néz ki, de középtávon irdatlan kódburjánzáshoz vezet, és nagyon nagy terhet ró a karbantartókra. (A teljesítménye pedig rövid távon is pocsék lehet, még akkor is, ha funkcionálisan sikerül elrejteni a változást.)

Az AMD helyében én is ebbe az irányba indultam volna, ha már van egy kódbázisom (ami feltételezem, hogy nagyságrendekkel nagyobb, mint az absztrakciós réteg),

A lényegi driver kódról nem tudom, hogy mekkora, de az absztrakciós réteg februárban (az olvasottak alapján) 300 ezer sorral indult, majd mostanra sikerült lefaragni 100 ezer sorra. Szóval az absztrakciós réteg önmaga is ordenárén nagy.

Az AMD hozzáállása természetesen logikus -- a maguk szemszögéből. A kernel karbantartók szemszögéből teljesen értelmetlen, mert ők nem foglalkoznak Windows-ra írt driver-ekkel, így a Windows/Linux különbségek elfedése a Linuxon belül megindokolhatatlan.

A Linux upstreaming-nek az az értelme, hogy a független kernel maintainer-ek és jövőbeni 3rd party fejlesztők felelősséget vállalnak azért, hogy a beolvasztott AMD driver-t működőképes formában tartják, a jövőbeni fejlesztések, átszervezések során is. Valamint ha valamilyen alsóbb rétegben javul a teljesítmény, paraméterezhetőség stb., akkor abból az AMD drivere is részesülni fog, mert az AMD-től függetlenül is kiterjesztik ezeket a változtatásokat az AMD driver-ére is.

Mivel a beolvasztással a maintainer és a közösség felelősséget vállal, az eredeti fejlesztőtől függetlenül is, érthető, hogy az előbbiek döntik el, hogy miért hajlandók felelősséget vállani.

amit integrálnom kell egy nem túl stabil API-val, akkor én is megpróbálnám elfedni azt.

Az API instabilitása csak addig probléma, amíg a driver nincs beolvasztva. Utána az API változásokat az adott fejlesztő (aki éppen az API-t változtatja) átvezeti az összes hívási helyen, olyan driver-ekben is, amelyekhez addig semmi köze nem volt, akár azok szűkebb/tágabb átszervezésével is.

Az absztrakciónak mint olyannak természetesen van értelme, általánosságában. A Linux/Windows különbségek absztrahálásának nincs értelme, főleg nem egy százezer soros réteggel.

Az AMD szemlélete, bár a driver nyílt forrású, továbbra is egy proprietary vendor szemlélete. Onnantól, hogy a driver beolvasztásra kerül, a kódot effektíve nem ők kontrollálják. Tehát nem az ő érdekeik a mérvadóak (főleg nem azok az érdekeik, amelyek más operációs rendszerekre is kiterjednek). A beolvasztott driver végleges formájának a kernelfejleszői közösség munkáját kell megkönnyítenie, nem az AMD-ét.

Ha van pár percet, ezt a videót érdemes megnézni. Az AMD egyetlen hibája (mind a mai napig), hogy a jó driverek késnek a kártya releasehez képest. Egyre kevesebbet de még mindig késnek. Viszont cserébe hosszabb ideig támogatottak maradnak a kártyák. Ami miatt egyedül elkondolkodnék Nvidia mellet az a CUDA, játékra teljesen jó az AMD.
Természetesen ha van pénz GTX1070-re vagy 1080-ra akkor nem szóltam :-) Középkategóriában RX480-t venném GTX1060 helyett.

https://www.youtube.com/watch?v=gEw3CaNSbUo

( cus | 2016. 12. 11., v – 18:05 )

AMD helyebe kuldenek neki egy RX480-at, mert - ahogy a csavo is irja - openszorszeknal az van tamogatva, amilyen hardvere van a maintainernek :)

( artifex | 2016. 12. 11., v – 19:19 )

"The second and certainly the most important, those drivers are only available for Ubuntu or at least in .deb format."

ehhez képest

https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-L…

AMDGPU-Pro Driver Version 16.50 for RHEL 7.3
AMDGPU-Pro Driver Version 16.50 for RHEL 6.8 / CentOS 6.8
AMDGPU-Pro Driver Version 16.50 for Ubuntu 16.04
AMDGPU-Pro Driver Version 16.50 for SLED/SLES 12 SP2

egyik rhel tartalma:

amdgpu-pro-16.50-362463.el7.x86_64.rpm
amdgpu-pro-lib32-16.50-362463.el7.x86_64.rpm
xorg-x11-drv-amdgpu-pro-1.1.99-362463.el7.x86_64.rpm
xorg-x11-drv-amdgpu-pro-debuginfo-1.1.99-362463.el7.x86_64.rpm
vulkan-amdgpu-pro-16.50-362463.el7.x86_64.rpm
...
libdrm-amdgpu-pro-debuginfo-2.4.70-362463.el7.x86_64.rpm
libdrm-amdgpu-pro-2.4.70-362463.el7.x86_64.rpm
libdrm-amdgpu-pro-devel-2.4.70-362463.el7.x86_64.rpm

a kettő információ valahogy nem klappol egymással. lemaradtam valamiről?

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Mert APU az, nem szimpla cpu, egy szilícium lapkában van az igp és a cpu. Pont az lenne a lényege, hogy kicsi fogyasztás, használható teljesítmény. Windows-on ez kb meg is van, de Linux-on fglrx-et ne próbálj telepíteni rá.
Ez a nagy baja az AMD-nek, nem képesek felfogni a terméktámogatás fogalmát. Van egy nvidia GTX 560-am, a mai napig minden támogatott OS(Windows, Linux, BSD, egyéb Unix-ok) alatt friss driver-t kap. Egy 4 éves amd vga/igp meg legacy támogatást kap, ami ráadásul használhatatlan az esetek nagy többségében.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

tudom miről beszélsz. nekem otthon ati 5570-es passzív hűtésű kártyám van, a passzív volta miatt vettem, debian 8 van a gépemen és volt egy pillanat amikor kihúzták alóla a gyári drivert, azóta a normál driver megy, igazi 3d felejtős. lehet, hogy valami nagy kavarással ismét működővé tehető, de arra nincs időm és szerintem nem így kellene mennie normálisan. alapból valami blacklistet kellett csinálnom, hogy elinduljon.

munkahelyemen nvidia van debian sid-en és egy mennyország az otthoni amdhez képest. mondjuk ez a kártya is legacy vonalra került amitől nem megy és nouveau drivert használok, de láthatóan fényévekkel jobban támogatott. lehet azóta megcsinálták amitől ismét menne, de erre sincs időm.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Mondjuk lehet megunták - mint, ahogy én is -, hogy majd egy negyed évig az Ubuntun kívül nincs másnak driver. Ugyanis amit belinkeltél csak a múlt héten jelent meg, addig semmi sem volt.
Ez azért egy kicsit feldaszhatta őket, főleg annak fényében, hogy az AMD logója ott van kitéve az oldalaikon. Igaz visszás, hogy mint szponzor, de ezek szerint a pénz nem minden, jobb lenne legalább annyi dokumentáció, mint amit az Ubuntu kaphatott.
(Megint más kérdés, hogy a felhasználó általában könnyebben vált ingyenes oprendszert, mint vasat. Lehet ez is bújtatott disztrib választás? Mert láthatóan vannak akik megunták a banánt.)