Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 53 reacties
Bron: Phoronix

Halverwege mei beloofde AMD betere Linux-drivers voor zijn grafische producten. Om een indruk te geven wat hierbij komt kijken gunt AMD een blik op het ontwikkeltraject van dergelijke drivers.

ATi-tuxDe Linux-gemeenschap heeft ATi de afgelopen jaren bestookt met verzoeken om de drivers te verbeteren. Met de overname van ATi door AMD rees de vraag wat de gevolgen daarvan voor de driver-ontwikkeling zouden zijn. Half mei reageerden Linux-gebruikers verheugd op de belofte van AMD om zich in te spannen om de kwaliteit van zijn graphicsdriver voor Linux op korte termijn op te schroeven. Hoewel de installatie en het uiterlijk van de Linux-drivers verbeterd zijn, kan onder andere op de prestaties namelijk nog wel wat afgedongen worden, zo stelt de site Phoronix.

De website kreeg toegang tot een presentatie van de AMD Graphics Products Group die de ontwikkeling van Linux-drivers uiteenzet. AMD voorziet Windows- en Linux-klanten maandelijks van aangepaste Catalyst-drivers, maar de ontwikkeling van deze drivers duurt elf weken, ofwel bijna drie maanden. Het schrijven van de software duurt ruwweg een maand, waarna de kwaliteit gecontroleerd wordt. Die controle bestaat uit drie weken valideren, drie weken beta-testen en tot slot een week die als buffer dient om ervoor te zorgen dat de Windows- en Linux-versie op dezelfde dag uitkomen. Elke nieuwe functie of verbetering die de AMD-ontwikkelaars in de release terug willen zien moeten in de ontwikkelfase afgerond worden. Uitzonderingen zijn serieuze problemen die aangepakt moeten worden en scripts die voor specifieke distributies toegevoegd moeten worden. Deze laatste packaging scripts worden beheerd door communityleden van AMD's internet beta-testprogramma waardoor aanpassingen in de testfase doorgevoerd worden.

AMD kent hiermee een totaal ander ontwikkeltraject dan nVidia, constateert Phonorix. Waar NVidia in dit jaar slechts één Linux-driver voor de GeForce-serie, twee beta-releases en een driver voor oudere grafische kaarten heeft uitgebracht, heeft de gestructureerde ontwikkelcyclus van AMD al tot vijf nieuwe Linux-drivers geleid, met nog eens zeven stuks op komst dit jaar. Gevolg van de rigide aanpak is wel dat AMD over het algemeen niet in staat is binnen een maand support te bieden voor nieuwe kernels en versies van X.Org. De strategie om de Linux-driver onderdeel uit te laten maken van de maandelijkse releasecyclus toont in ieder geval de toewijding van AMD aan de Linux-gemeenschap aan, zo kan geconcludeerd worden.

AMD graphics Linux ontwikkeling
Moderatie-faq Wijzig weergave

Reacties (53)

Laat ze nou gewoon meer samen gaan werken met de opensource gemeenschap. Als ze dat zouden doen hebben ze binnen no time met veel minder inspanning veel betere drivers. Opensource ontwikkelaars zitten namelijk te springen om te helpen.

Er was een half jaar geleden geleden hier op tweakers een nieuwsbericht van iemand die een opensource driver had geschreven op basis van een document dat hij onder nda in handen had. Hij had dus een werkende driver geschreven voor een ati radeon 1300, had aan ati toestemming gevraagd deze te releasen. Ati heeft hier nooit toestemming voor gegeven. Dit is dus de driver ontwikkeling bewust frustreren.
Dan had iemand zijn computer moeten 'hacken' zodat het leek alsof die driver geleakt was. Had hij geen problemen (als hij het een beetje goed nabootste) en kon de open source community gauw wat leren over ati kaart(en) ^^
Dan nog zal de open source communitie dit niet mogen gebruiken. Dit is namelijk NDA info en mag niet gebruikt worden.
Als je dit door leaken of dergelijke toch doen hebben ze een probleem met ATi.
Daarom wordt er zoveel mogelijk aan gedaan om dit soort info buiten de deur te houden.
Het kan natuurlijk wel dat de driver op een of andere russische site komt en dat gebruikers zelf er mee aan de slag gaan maar officeel zal het niet gebruikt gaan worden.
Dan nog zal de open source communitie dit niet mogen gebruiken. Dit is namelijk NDA info en mag niet gebruikt worden.
Volgens welke wet dan? Diegene die de informatie lekt en een NDA (contract) had afgesloten met een bedrijf heeft een probleem ja. Maar anderen kunnen prima de informatie gebruiken. Het niet meer geheim zijn van een 'trade secret' is gewoon pech gehad voor het bedrijf (vage wetten als DMCA even hierbuiten gelaten).
gewoon keihard rebellen en laten releasen door iemand anders...

en dan gewoon blijven releasen niet mee kappen...

vind het kei laf dat fabrikanten dit soort dingen flikken. de enige reden dat ik niet overstap naar linux is dat ik wel van een spellejte hou en dus toch de windows nodig heb
Dit is helemaal niet de driver ontwikkeling bewust frustreren. Dit is iemand houden aan de afspraken die vooraf met hem gemaakt zijn. AMD wil niet dat de technische specificaties van hun software openbaar gemaakt wordt. Dat is hun recht en als je dan een contract met AMD sluit om toch inzage te krijgen heb je dat recht te respecteren. Wil je iets wat je volgens je NDA niet mag, vraag je daar van te voren toestemming voor. Je komt niet op het laatste moment met de vraag en maakt het al helemaal niet publiekelijk bekend dat je de vraag aan AMD gesteld hebt en die is afgewezen.
Zeer mooi dat ze dit doen. (als ze het ECHT uitvoeren).

Ook nVidia mag wat meer doen aan hun performance van hun drivers.
In Quake3-gebasseerde games haal ik dezelfde fps in linux als in windows.
Ik haal in Linux veel meer FPS dan in WIndows, met dezelfde hardware en beiden de meest recente drivers.
Ik mag het hopen -.-

Er even vanuit gaande dat je kaart een stuk jonger is dan Q3.
dit doen ze al, deze aanpak is eigenlijk al door ATI zelf ingezet, nog voor de overnamen door AMD. kijk de meuk tracker er maar op na, de linux drivers komen al een tijdje samen met de windows drivers uit.
reken daar de bijna 3 maanden ontwikkeltijd nog bij voor de eerste driver en je ziet dat ze al een tijdje zo werken.
Och, ik vind de prestatie's van m'n 7600GT nog wel meevallen in Ubuntu 7.04. Nou moet ik wel bekennen dat ik alleen Half-Life 2 via Wine gespeeld heb (en 3D desktop Beryl draai). Voor het echte spelgenot schakel ik toch weer over naar Windows XP.
Hmm.. Ik dacht dat de NVidia drivers bij Beryl nog steeds last hadden van de "Black Window" bug (zie google)? Dat maakt het werken met linux onder beryl vrij onmogelijk..

Nvidia heeft ook nog flink wat te doen..
Wat ik had gelezen, was dat de Intel kaarten nog het dichts bij compleet ondersteund zaten. Dit is dan wel met de OSS drivers.
Gevolg van de rigide aanpak is wel dat AMD over het algemeen niet in staat is binnen een maand support te bieden voor nieuwe kernels en versies van X.Org.
De nieuwe kernels en X.Org versies worden toch ook eerst in een alfa, beta, experimenteel, etc uitgebracht. Dus ik vind dat een beetje een zwak excuus. Desalniettemin, de support voor de ATI kaarten onder linux is het laatste jaar aanzienlijk verbeterd.

Typo
De linux community (en OS ook wel in het algemeen) lijkt soms wel een versie en upgrade fetisj te hebben.

Er word gevit op alpha versies, gescholden op beta's en de final mist altijd de belangrijke features van de volgende versie, waardoor iedereen weer overstapt op beta's.
Het is natuurlijk leuk als je de nieuwste snufjes wil zien, maar dan is het niet gek dat een bedrijf daarin niet constant meegaat.

Een 3 maanden response tijd voor een nieuwe versie is best aardig. Je voorkomt alvast dat je uren werk in een alpha kernel stopt waarna Linus besluit het toch maar niet te doen. X.Org heeft toch een veel rustigere cycly, dan is 3 maanden weinig spannends en de laatste tig kernel updates zijn weinig vernieuwend meer geweest voor 99,9% van de mensen.
Ik sluit mij bij Rune aan. De ati-drivers zijn brak. Ik hoef niet elke paar maanden een nieuwe, paar maanden is vlot zat. Wat zeg ik, 1x per jaar zou ik prima vinden Als Het Goede Drivers Waren, maar dat zijn het niet...

Als Ati een jaar geleden naar de ontwikkelingen rondom Beryl/Compiz had gekeken hadden ze nu een goed ondersteunende kaart uit kunnen brengen. Da's geen koffiedik kijken naar mogelijke features in alpha's, maar een duidelijk ontwikkeling die duidelijk doorzet...

X1400 op m'n laptop: dualhead ondersteuning? Alleen op papier, AIGLX? nope, Composite? nope...

Waarin ik Rune niet begrijp.. 'ik wil niet naar Nvidia..'

Ik wel.

Ati heeft het totaal verprutst, mijn volgende laptop heeft geen Ati-kaart.

Als Ati alsnog z'n best doet en mijn kaartje goed gaat ondersteunen overweeg ik me te bedenken. Maar vooralsnog is het alleen gebabbel. Hun laatste driver kreeg ik niet eens geinstalleerd onder ubuntu feisty.
Op dit moment is de enige logische keuze Intel. Nvidia verneukt de boel vroeger of later ook en dan zit je met een kaart zonder drivers zonder specs.
Ik weet nog dat we X.Org 7.1 een dik halfjaar hebben uitgesteld omdat zowel nvidia als ATI gewoon niet met die versie konden werken. xorg-server-1.3.0 hebben we nu gewoon de repos ingedrukt: nvidia ondersteunt het alleen in een gare beta die half werkt, ati ondersteunt het al een tijdje.

Geef mij maar gewoon een Intel 945G of G965, snel zat, ondersteuning voor zowat alles en de specs liggen gewoon op straat. Na de intel chips komen bij mij op de 2e plaats de ATI R200 gebaseerde kaarten, daar heeft ATI destijds voldoende specs voor uitgegeven om een fatsoenlijke opensource driver te bakken met werkende 3D die beter werkt dan de binary ATI driver.
rune, zoals _JGC_ hier dus ook vermeld, voor r1xx en r2xx kaarten zijn er opensrc drivers die erg goed presteren. De r3xx kaarten worden er sinds een tijdje ook mee ondersteunt, al is dat natuurlijk nog niet 'af' omdat ze daar nog geen specs e.d. van hebben.
Niks upgrade fettish. Ben het een beetje beu dat m'n ATI kaarten maar halfbakken worden ondersteunt.
(Brakke dualhead ondersteuning, en nog steeds die verdomde composite niet, m'n R2xx is niet geaccellereerd en bij mijn X1600 worden de modi niet goed uitgelezen.). Ik draai nu zowel thuis als op mijn laptop als op mijn werkstation (op het werk) een stable install. En TOCH zorgen de FGLRX drivers van tijd tot tijd voor elende, met als klap op de vuurpijl dat bij mijn laatste auto update van m'n software op mijn werkstation opeens de ondersteuning voor m'n ati model uit de driver weg was.

Dus ja, ik wil zsm dat dit in orde komt, want ik zit nu al jaren (letterlijk) met brakke X desktops te werken.
(en nee, ik wil niet over naar NVidia).

Dus ik vind het eigenlijk wel een beetje tijd worden. Heb geduld genoeg gehad nu. (En al regelmatig ongenoegen geuit naar ATI support).
Als je niet naar nVidia over wilt, kies je er toch gewoon zelf voor?

Beetje overbodig gemekker dan...

[edit]: iets vriendelijker verwoord :P
De nieuwe kernels en X.Org versies worden toch ook eerst in een alfa, beta, experimenteel, etc uitgebracht. Dus ik vind dat een beetje een zwak excuus.

Zo zwak is dat excuus niet.

Probleem is dat ATI/Nvidia hun drivers niet als sourcecode willen leveren. Dan zouden ze zo meegecompileerd kunnen worden met de kernel.
ATI/Nvidia willen alleen de binaries leveren, maar kernel modules die alleen als binary geleverd worden hebben een stabiele kernel interface nodig.
Die is er niet. De kernel groep weigert een stabiele interface te definieren. Sterker nog, er is een groep die er op uit is om datgene wat er is, opzetelijk met iedere versie te veranderen.
De redenering is tweeledig.
1. Een dergelijke interface is niet nodig als je de sourcecode van de drivers hebt. En het is een open-source systeem, dus de drivers horen ook open-source te zijn.
2. Door een dergelijke interface maak je voor de gebruiker oncontroleerbare software onderdeel van de kernel. Dan kun je de stabiliteit van het systeem dus niet meer garanderen. Ook allerlei malware zou hier gebruik van kunnen maken.

Voor een groot deel is dit probleem dus gewoon een botsing tussen de open-source filosofie en de closed-source filosofie.
Voor een groot deel is dit probleem dus gewoon een botsing tussen de open-source filosofie en de closed-source filosofie.
Wat mij betreft is die botsing niet nodig.. zowel NVidia als ook ATI zijn hardware fabrikanten (ze bakken chips) en geen software fabrikanten. Ik pleit al langer voor het compleet scheiden van hardware en software voor grotere bedrijven.
Uit betrouwbare bronnen heb ik vernomen dat het mogelijk net iets gecompliceerder ligt: Een deel van de software mogen AMD/ATI en nVidia mogelijk niet vrijgeven, omdat de rechten niet bij hunzelf liggen van bepaalde gedeelten, of omdat dat simpelweg zo in bepaalde contracten staat. Immers, niet alle hardware(ontwerpen) op een grafische kaart is afkomstig van nVidia/ ATI zelf. Natuurlijk is er ook nog het al dan niet legitieme argument dat van bepaalde delen software afgelezen kan worden hoe de hardware in mekaar hangt.

Het bedrijf van mijn bron heeft deze problemen verholpen door de driver's in twee delen op te delen: Een open kernel module, die dus tegen iedere nieuwe kernel gecompileerd kan worden en waarme community-software kan communiceren, en een stukje low-level gesloten firmware dat aan de kernel-module gelinkt is, voor de onderdelen die niet vrijgegeven kunnen worden. Die firmware hoeft niet zo vaak ge-update te worden. Persoonlijk vond ik het een vrij aardige oplossing.
nVidia is geprezen om de goede compatibiliteit met Linux, maar onthoud wel dat dit de relatieve compatibiliteit tegenover ATI is en niet de absolute compatibiliteit. De drivers zijn inderdaad goed, maar het is niet echt alles, bijvoorbeeld is het iedere keer na een kernel update of een driver update de verrassing of X-Server goed start en dus of de wfb-module nog laadt, de versie van de X-Server module en kernel module gelijk zijn etc etc etc.

Zo moet het niet vindt ik, het moet of zoals in Windows dat je een BSOD krijgt en heel je systeem onbruikbaar wordt ( :P ) of dat X-Server automatisch terugvalt op vesa en dat je grafisch de drivers kan herinstalleren.

Op het moment gebruik ik na lange tijd weer de packaged driver, maar deze is helaas wat verouderd. Ik hoop voor het goede voor AMD en misschien kan ik eens een ATI kaart in me bak zetten in plaats van gebonden te zijn aan nVidia. :)
Bwa, voor ik mijn kernel hercompileer haal ik even de nVidia drivertjes af, en kan ik, na de installatie van mijn kernel, even booten in recovery modus (Ubuntu), driver compileren, en gaan met die banaan ;)
Als je de Nvidia driver gebruikt die ik de repo's zit van Ubuntu dan heb je geen last van kernel updates.

Jammergenoeg herkende deze driver m'n Geforce go 7200 niet en moet ik het nvidia script van nvidia zelf gebruiken.

En inderdaad na iedere kernel update moet ik het script opnieuw laten lopen.
Getroost, binnenkort kan X zonder configfile werken. Problemen in de xorg.conf, geen probleem, X runt dan op een gegenereerde config die wel werkt :). Ook zal het eindelijk mogelijk zijn om de instellingen van de configuratie aan te passen en toe te passen zonder X te hoeven herstarten :).
AMD heeft blijkbaar een prachtig geölied ontwikkelproces, ik mis alleen nog de resultaten ervan.

De nvidia-driver is aardig feature-compleet en levert goede performance (met een 6600GT) in tegenstelling tot de fglrx-driver die best aardige performance levert, maar echt zuigt qua features *kuch* compositing *kuch*.
zoiets kost gewoon tijd.
daarbij zijn de resultaten al aardig zichtbaar aan het worden, de huidige drivers zijn goed bruikbaar te noemen waar dat een jaar of 2 hiervoor nog lang niet altijd het geval was.

dat gezeur over compositing komt ook vanzelf wel goed, nu de drivers zelf goed werken voor (bijna) iedereen kunnen ze aan de features dan wel de performance gaan werken.
het andersom aanpakken zou pas echt fout zijn geweest.
Ach, mijn kaart was 2 jaar terug (als het niet langer is) ondersteund. In die tijd is er weinig verandert in de featureset van de driver en de performance van m'n kaart is ook niet astronomisch vooruit gegaan. Ik vraag me dus een beetje af wat ze hebben lopen doen, behalve achter de feiten aanlopen (Xorg-updates, features, kaartondersteuning).
Ik begrijp überhaubt niet waarom ze die drivers niet open source maken. Aan de drivers zelf verdienen ze immers niets, en het is toch echt in hun belang dat hun kaarten zo goed mogelijk werken op zo veel mogelijk OSs.
Of mis ik nu heel erg iets?
Punt is dat in de driver technieken verwerkt zitten die duidelijk maken hoe AMD bepaalde zaken hardwarematig heeft opgelost. Een Open Source driver geeft een hardwarebouwer dus een hele hoop informatie over hoe AMD grafische chips bouwt waardoor die bepaalde zaken waar AMD veel tijd en moeite in gestoken heeft zomaar kan overnemen.

Daarnaast speelt performance natuurlijk een grote rol. Is de driver van AMD slimmer dan die van (bv) nVidia, kan AMD met goedkopere hardware, snellere grafische kaarten maken.

Tot slot kán het zijn dat er patent issues spelen en de driver/hardware gelicentieerde technieken gebruikt die AMD niet openbaar mag maken.

Het Open Source maken van de driver kan dus heel gevaarlijk zijn voor een bedrijf wat voor zijn omzet grotendeels afhankelijk is van die ene serie producten.
Ok, redelijk wat gemist dus :$
Bedankt voor de info in elk geval. had ik ook zelf moeten kunnen bedenken.
Dit zou juist grotendeels door patenten ondervangen moeten worden, sowieso kan je alles vrijgeven als het patent eenmaal toegewezen is. Wat er met NDA's meestal aan de hand is, dat er technieken worden gebruikt die nog niet gepatenteerd zijn en daarom geheimgehouden moeten worden. Overigens schijnt dat onder het Amerikaanse patentrecht ook weer geen probleem te zijn, omdat dan telt wie het als eerste toepast, niet wie het als eerste patenteert.
Als je gelooft dat AMD/ATI, Nvidia en Intel elkaars drivers niet disassembleren dan ben je wel erg naďef hoor... ;)

Het is wel zo dat ze bijna zeker patenten van elkaar schenden, en in de USA en sommige andere landen is "reverse engineeren" verboden, dus kunnen ze elkaar (daar) geen proces aandoen zonder zelf een "misdaad" te bekennen.

[Reactie gewijzigd door Filip Maurits op 5 juni 2007 20:26]

Ik wil toch even duidelijk maken dat ATI niet altijd slechte ondersteuning voor Linux heeft gehad. Een aantal jaar geleden had ik zelfs speciaal een oude ATI Radeon 7000 gekocht vanwege de uitmuntende ondersteuning onder ELK actueel besturingssysteem omdat ATI toen ALLE benodigde specs vrijgaf. Dat de kaart passiefgekoeld was en spotgoedkoop was, was natuurlijk ook mooi meegenomen. De aanleiding voor die aankoop was dat mijn Nvidia TNT2-kaartje na een aantal jaren gebruik erg onstabiel werd door redenen die mij onbekend zijn. Die ATI-kaart is nu al een aantal jaren in gebruik en werkt nog steeds perfect. Als je dus een goedkoop en stil Linux-kantoorsysteempje wilt bouwen, kan ik je dit kaartje aanraden: pricewatch: Sapphire Radeon 7000 64MB DDR
(dat is de nieuwere versie van het kaartje dat ik heb: pricewatch: Sapphire Radeon 7000 64MB SDR )

Het is misschien erg verouderd qua technologie, maar het *werkt* vreselijk goed (je hoeft je geen zorgen te maken over te installeren drivers; de driver zit normaal standaard in X.org zodat je zelfs volledige ondersteuning hebt onder distributies die vanaf cdrom draaien zoals bv. Knoppix) en het kaartje blijft ook *blijft* werken. Dat mijn kaartje nog steeds te koop blijkt te zijn, heeft misschien iets te maken met de populariteit.
Als je mensen toch een Ati-kaart aan wilt praten kun je ze beter eentje aanraden met een r300-chipset : niet zo afgrijselijk antiek en prima ondersteund door zowel de fglrx- als de ati-driver.
Dit is wel goed van AMD. Als er meer (en gebruikersvriendelijkere) drivers beschikbaar komen voor Linux, zullen meer mensen van dit OS gebruik gaan maken.
Het hele bericht gaat niet over plannen, maar beschrijft puur de huidige werkwijze. Het artikel (het origineel) eindigt dan ook met de dooddoener: "Er kan nog iets leuks aankomen tegen het eind van het jaar".

Ja, dat geloven we wel, maar ondertussen zit ik al sinds januari met brakke drivers op mijn macbook pro (x1600), en joost mag weten wanneer ik iets fatsoenlijks krijg.

Hopen op binnenkort open-source drivers, en hopen dat AMD daar eens een steentje aan bijdraagt:
http://tirdc.livejournal.com/
http://www.michaellarabel.com/?k=search&t=Reverse
leuk nieuws, ik hoop alleen dat ze dit keer niet de FreeBSD variant vergeten.

Nvidia doet dit weer juist wel erg goed, de FreeBSD drivers zijn net zo goed als de linux varianten, en ik heb eigenlijk nog nooit een serieuze fout meegemaakt. (ik weet het, niet iedereen heeft dergelijke fraaie resultaten met die drivers - maar goed nieuws mag ook wel eens gemeld worden).

Ik weet toevallig dat de coder achter LainOS, een FreeBSD variant die de grafische interface van Lain wil kopieren wel bezig is met een poort van de propietary ATi driver (met bijbehorende NDA uiteraard - ook hier zit weer veel propietary zooi van SGI in voor OpenGL),

Ik hoop dat ze er wat mee doen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True