AMD brengt Linux-drivercode uit voor HD 7000 en Trinity
AMD heeft code vrijgegeven die het mogelijk maakt om Southern Islands-gpu's van de Radeon HD 7000-series aan te sturen via opensource-drivers. Daarnaast kan de code gebruikt worden op systemen die beschikken over een Trinity-apu.
Alex Deucher, driver-ontwikkelaar bij AMD, laat op de dri-mailinglijst weten dat er een lijst met 48 patches is uitgebracht. Deze patches kunnen worden opgenomen in de Linux 3.4-kernel, waardoor de opensource-drivers voor AMD-gpu's voortaan beter overweg moeten kunnen met de nieuwe Southern Islands-gpu's, voorzien van de codenamen Tahiti, Pitcairn en Cape Verde, die in de Radeon HD 7000-serie worden gebruikt. Ook de grafische mogelijkheden van Trinity-apu's kunnen met de nieuwe drivercode benut worden door opensource-drivers.
AMD brengt, net als Nvidia, propriëtaire Catalyst-drivers uit voor Linux, maar veel Linux-gebruikers klagen dat deze zowel qua geboden features als wat prestaties betreft achterblijven bij de drivers die beide bedrijven voor Windows ontwikkelen. Daarnaast klinkt vanuit de Linux-ontwikkelgemeenschap de roep om het opensource maken van AMD- en Nvidia-drivers, zodat de gpu's beter aangestuurd kunnen worden met drivers die door de community worden ontwikkeld.
Reacties (57)
Erg goed nieuws, grafische ondersteuning onder Linux is vaak niet 100%, maar dat geldt voor meer soorten drivers, hopelijk komt daar binnenkort verandering in.
De gesloten drivers van AMD zijn helaas om van te huilen (ver van 100%). In samenwerking met Gnome 3 werken ze in ieder geval niet goed (na ruim een half jaar zijn de artifacts verwijderd, maar random crashes of desktop verversingen zijn er nog steeds elke paar minuten) en dan heb je dus al problemen bij een paar bekende grote distros. Ik hoop daarom dat de open drivers met deze patches beter worden, zodat de gesloten drivers helemaal niet meer nodig zijn.
Ik heb met mijn Radeon 5770 i.c.m. KDE niet echt problemen. Werkt Gnome 3 wel goed samen met nVidia of intel?
Het probleem is inderdaad Gnome hier.
Gnome 3 werkt anders prima op niet-AMD videokaarten, dus simpelweg zeggen dat het aan Gnome ligt is zeker niet correct.
gnome 3 een tijdje met de closed source drivers gebruikt op een e350 apu maar herken deze problemen niet. Het enige probleem dat ik heb gehad is dat er geen goede gpu acceleratie in flash is waardoor ik geen 1080p en nauwelijks 720p youtube kan afspelen zonder de files eerst te downloaden. Maar dit ligt meer aan adobe en aan het fijt dat de alternatieve flash plugins nog niet volwassen genoeg zijn.
Je kunt ze ook streamen:
$ mplayer $(youtube-dl -g [videourl])
Werkt anders http://lightspark.github.com/ ipv. Gnash niet goed genoeg op die apu?
$ mplayer $(youtube-dl -g [videourl])
Werkt anders http://lightspark.github.com/ ipv. Gnash niet goed genoeg op die apu?
Dat heeft niks met de driver te maken maar met gnome zelfDe gesloten drivers van AMD zijn helaas om van te huilen (ver van 100%). In samenwerking met Gnome 3 werken ze in ieder geval niet goed (na ruim een half jaar zijn de artifacts verwijderd, maar random crashes of desktop verversingen zijn er nog steeds elke paar minuten) en dan heb je dus al problemen bij een paar bekende grote distros. Ik hoop daarom dat de open drivers met deze patches beter worden, zodat de gesloten drivers helemaal niet meer nodig zijn.
Hoe komt het dan dat dit enkel bij de closed source AMD drivers gebeurt? Het zal deels wel aan de veranderingen in Gnome 3 liggen, maar andere videokaarten hebben nergens last van hoor.
Als je googled of de bugtracker leest zie je ook dat het met nvidia kaarten gebeurt.. en geloof zelfs ook bugs met alle verschillende GPU's
en hoe komt het dan dat ik met KDE geen enkel probleem heb ondervonden Draai al meer dan 3 jaar ATI en nog nooit een crash gehad of rare artifacts
en hoe komt het dan dat ik met KDE geen enkel probleem heb ondervonden Draai al meer dan 3 jaar ATI en nog nooit een crash gehad of rare artifacts
[Reactie gewijzigd door demilord op donderdag 22 maart 2012 12:48]
Nu nog goede support voor powermanagement en UVD in de radeon driver en ik laat de catalyst driver voor wat hij is.
Precies, als powermanagement goed is dan is de opensource driver ineens een heel stuk aantrekkelijker, zeker aangezien deze stabieler is een veel betere 2d performance heeft.
goede ontwikkeling op opensource gebied moet ik zeggen.
Ik snap het idee van een driver in de kernel nog steeds niet een driver is geen onderdeel van de kernel maar een los staand iets dat het mogelijk maakt voor de kernel om met de onderliggende hardware te communiceren.
De kernel dient ten alle tijden een exact gelijke interface met bijvoorbeeld de grafische driver te hebben. Op dat moment is het aan de driver bouwers om simpel weg de kernel commando's te accepteren en op de best mogelijke manier naar hun hardware door te sturen. Een driver update zo als deze is dan simpel weg een kwestie van de module vervangen en niet van een nieuwe kernel compileren.
Daar naast snap ik AMD niet helemaal waarom wacht men dan niet tot de drivers klaar zijn voor het tweede meest belangrijke OS dat ze ondersteunen? Waarom worden kaarten al uitgebracht voor de drivers af zijn en waarom is er schijnbaar zo weinig overlap tussen het aansturen van de kaarten op de verschillende OS'en? Als er een overlap is die er toch echt moet zijn dan vind ik het vreemd dat AMD zo veel tijd nodig heeft om de code van Windows naar Linux over te zetten zeker 50% van de code is gelijk omdat dit de commando's naar de GPU zelf behelst en dus eigenlijk niet echt zal verschillen per OS.
De kernel dient ten alle tijden een exact gelijke interface met bijvoorbeeld de grafische driver te hebben. Op dat moment is het aan de driver bouwers om simpel weg de kernel commando's te accepteren en op de best mogelijke manier naar hun hardware door te sturen. Een driver update zo als deze is dan simpel weg een kwestie van de module vervangen en niet van een nieuwe kernel compileren.
Daar naast snap ik AMD niet helemaal waarom wacht men dan niet tot de drivers klaar zijn voor het tweede meest belangrijke OS dat ze ondersteunen? Waarom worden kaarten al uitgebracht voor de drivers af zijn en waarom is er schijnbaar zo weinig overlap tussen het aansturen van de kaarten op de verschillende OS'en? Als er een overlap is die er toch echt moet zijn dan vind ik het vreemd dat AMD zo veel tijd nodig heeft om de code van Windows naar Linux over te zetten zeker 50% van de code is gelijk omdat dit de commando's naar de GPU zelf behelst en dus eigenlijk niet echt zal verschillen per OS.
Het idee van een driver in de kernel, houdt niet per definitie in dat de driver ook daadwerkelijk in de kernel zit. Er wordt hier met 'in de kernel' bedoeld dat de code zich in de kernelsource bevind, waarna er bij de kernelconfiguratie gekozen kan worden voor ofwel een module ofwel de driver direkt in de kernel bakken.
Het voordeel van de drivers direkt in de kernel bakken, is dat dit iets wat sneller is bij het opstarten. Sommige drivers (bv voor chipsets en satadrivers) moeten wel direkt in de kernel. Het is bijvoorbeeld niet mogelijk om de satadrivers van je hdd te halen, als je hdd via sata verbonden is.
Het voordeel van de drivers direkt in de kernel bakken, is dat dit iets wat sneller is bij het opstarten. Sommige drivers (bv voor chipsets en satadrivers) moeten wel direkt in de kernel. Het is bijvoorbeeld niet mogelijk om de satadrivers van je hdd te halen, als je hdd via sata verbonden is.
Je kan je drivers niet van je sata-hdd halen nee, maar toch hoeven de benodigde drivers niet in de kernel te zitten.Sommige drivers (bv voor chipsets en satadrivers) moeten wel direkt in de kernel. Het is bijvoorbeeld niet mogelijk om de satadrivers van je hdd te halen, als je hdd via sata verbonden is.
De oplossing daarvoor is initrd. Die wordt door de kernel gelezen, uitgepakt (het is een mini-filesystem met alle benodigde drivers) en het script "/init" wordt gestart. Die zorgt er dan voor (meestal dmv udev) dat de drivers geladen worden die nodig zijn om de hdd te kunnen mounten en de echte init (/sbin/init) te starten.
Je kunt de kernel dus echt helemaal leeghalen.
[Reactie gewijzigd door Ertepeller op woensdag 21 maart 2012 17:53]
Dat kan inderdaad ja. Dat was ik vergeten te vermelden.
Ik ben hier zelf echter geen fan van. Om een universele kernel te maken is het erg handig, dat ontken ik niet, maar voor mijn eigen kernel doe ik het niet. Voor elk systeem dat ik gebruik maak ik een specifieke kernel, en zorg ervoor dat eigenlijk bijna niets in modules komt te staan.
Ik ben hier zelf echter geen fan van. Om een universele kernel te maken is het erg handig, dat ontken ik niet, maar voor mijn eigen kernel doe ik het niet. Voor elk systeem dat ik gebruik maak ik een specifieke kernel, en zorg ervoor dat eigenlijk bijna niets in modules komt te staan.
Ik maak ook live-cd/usb-stickjes en dan móet je wel met initrd werken.
Je gesquashte filesysteem staat op de cd/stick en initrd moet dat afhandelen, dat kan niet met alleen een kernel. Dus dan maakt het ook niet meer uit en kan je net zo goed alles in modules doen.
Voor je eigen PC, waarvan je weet welke hd-partitie rootfs is en welk type filesysteem kan je dat wel in je kernel meebakken natuurlijk en initrd buiten schot laten. Scheelt toch weer een paar seconden
Je gesquashte filesysteem staat op de cd/stick en initrd moet dat afhandelen, dat kan niet met alleen een kernel. Dus dan maakt het ook niet meer uit en kan je net zo goed alles in modules doen.
Voor je eigen PC, waarvan je weet welke hd-partitie rootfs is en welk type filesysteem kan je dat wel in je kernel meebakken natuurlijk en initrd buiten schot laten. Scheelt toch weer een paar seconden
zulke verschillen zijn niet eens zichtbaar, hoogstens een aantal nanosecondenHet idee van een driver in de kernel, houdt niet per definitie in dat de driver ook daadwerkelijk in de kernel zit. Er wordt hier met 'in de kernel' bedoeld dat de code zich in de kernelsource bevind, waarna er bij de kernelconfiguratie gekozen kan worden voor ofwel een module ofwel de driver direkt in de kernel bakken.
Het voordeel van de drivers direkt in de kernel bakken, is dat dit iets wat sneller is bij het opstarten. Sommige drivers (bv voor chipsets en satadrivers) moeten wel direkt in de kernel. Het is bijvoorbeeld niet mogelijk om de satadrivers van je hdd te halen, als je hdd via sata verbonden is.
Het tweede "belangrijke OS dat ze ondersteunen", heeft een marktaandeel van 1%, en een veel groter deel van die 1% speelt geen games, want voor games is het Windows platform veel meer geschikt, een werkende 2D driver met beperkte 3D functie, is voor de meeste, meer dan genoeg.maar veel Linux-gebruikers klagen dat deze zowel qua geboden features als wat prestaties betreft achterblijven bij de drivers die beide bedrijven voor Windows ontwikkelen.
Daar naast snap ik AMD niet helemaal waarom wacht men dan niet tot de drivers klaar zijn voor het tweede meest belangrijke OS dat ze ondersteunen?
En iOS is een Linux variant, die wel gesloten drivers gebruikt, en die door de veranderingen aan de Linux Unix kernel, als ik het goed heb niet op de open source Linux draait
Helaas zijn dat de feiten zo, dat als Linux een degelijk game platform was, zou ik en vele andere het best over wegen om te gebruiken, maar zelfs mijn vriend, die professioneel met Linux werkt als ITer, en thuis op zijn hoofdsysteem Linux gebruikt, heeft hij nog steeds een dual-boot naar Windows, voor de meeste spelletjes, quote "moderne spelletjes spellen op Linux werkt gewoon niet goed op Linux".
Hoofd driver ontwikkeling bij AMD/nVidia: ach wat jammer nou voor die arme Linux gebruikers, wou dat ik meer voor ze kon doen, maar mijn budget is maar zo groot, en ik besteed in verhouding al meer aan de Linux dan aan de Windows driver.
@Arcadia
Wederom daar maakt het weinig uit of de drivers open source zijn of niet, daar de mobiele markt voornamelijk geen problemen hebben met een mix van open en closed source software.maar als ze net als NVIDIA eens willen uitbreiden naar de mobiele (ARM) markt met ingebakken gpu, kan het bijzonder handig zijn om al de nodige code beschikbaar te hebben.
En als er een markt is, dan zullen ze vast meer geld stekken in de ontwikkeling van de driver.
Als dingen als OpenCL echt interessant worden op servers, dan zal er vast wel een Linux OpenCL driver uit komen.Daarnaast lijken mensen maar niet te beseffen dat je ook andere dingen met videokaarten kan doen dan spelletjes spelen; juist op Linux...
Het is niet zo dat AMD/nVidia tegen open source zijn, waar ze wel tegen zijn is geld verspillen aan iets waar ze geen winst mee maken.
Imho hebben Linux gebruikers een beetje last van het Calimero syndroom.
Edit 2:
Ik loop de Linux gebruikers helemaal niet te kleineren, ik zou graag gehad hebben dat Linux de dominante OS was geworden over Windows.Je kan Linux-gebruikers wel kleineren,
Maar een feit is, dat veel Linux gebruikers in hun eigen wereld leven, en hoe hard je het ook wild en zegt hoe makkelijk het ook is, (PS3 games porten naar Linux).
Feit blijft dat het lock-in Windows op het PC platform, een 99.8% markt aandeel heeft als het op gamen aan komt, en hoe hard je ook stampt met je voet, daar zal niks aan veranderen.
En men geen extra ontwikkelingsgeld gaat stekken in een platform met 0.2% game marktaandeel.
Don't kill the messenger, ik probeer alleen maar te verwoorden, hoe "ik" denk dat de driver managers bij AMD/nVidia denken.
OpenGL evangelist Carmack: Direct3D is now better than OpenGL
First person shooter godfather John Carmack has revealed that he now prefers DirectX to OpenGL, saying that 'inertia' is the main reason why id Software has stuck by the cross-platform 3D graphics API for years.
Speaking to bit-tech for a forthcoming Custom PC feature about the future of OpenGL in PC gaming, Carmack said 'I actually think that Direct3D is a rather better API today.' He also added that 'Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better.'
[Reactie gewijzigd door player-x op woensdag 21 maart 2012 17:22]
Let wel dat dat marktaandeel slaat op de desktopmarkt hè. Nu zullen er niet veel webservers met Radeon-kaarten zijn, maar als ze net als NVIDIA eens willen uitbreiden naar de mobiele (ARM) markt met ingebakken gpu, kan het bijzonder handig zijn om al de nodige code beschikbaar te hebben.
Daarnaast lijken mensen maar niet te beseffen dat je ook andere dingen met videokaarten kan doen dan spelletjes spelen; juist op Linux...
Overigens is iOS een BSD/Mach-variant; géén Linux-variant.
@player-x
Je kan Linux-gebruikers wel kleineren, maar de Linux-community doet in ieder geval nog actief z'n best om zélf goed werkende software te maken, omdat hen niet alles komt aangewaaid. Op het Windows-platform hebben gebruikers gewoonweg geen keuze, dus het maakt daar niets uit als Microsoft een ondermaats OS maakt of NVIDIA of ATI ondermaatse drivers maken. Je moet het gebruiken; het wordt meegeleverd of er zijn geen alternatieven beschikbaar. En die lock-in die daarmee ontstaat, gebruiken ze om gebruikers onwetend te houden. Weten zij veel dat er alternatieven zijn. En dat houden ze ook graag zo. Want ze vinden het heerlijk; 90% van de markt in handen met een OS waarvan het lang niet zo is dat het ook écht de beste optie is.
En als sommige gebruikers er wel achter komen dat er alternatieven zijn, wordt het ze wel heel moeilijk gemaakt omdat vrijwel alle Windows-programma's Windows-only zijn. Natuurlijk zijn er prima werkende alternatieven, maar dan moet je wel weten welke dat zijn, en de kleine verschillen onder de knie gaan krijgen.
En dat leidt tot allerlei obscure bestandsformaten, gesloten drivers waar niemand van mag weten hoe ze werken en zodoende het idee dat Linux minder goed zou zijn omdat het een kleine speler is. Dus hoe noemen we Windows-gebruikers dan? Neo-imperialisten met een "wir haben es nicht gewusst"-mentaliteit? Overal is een naam voor te verzinnen, maar ik denk dat iedereen het er wel over eens is dat concurrentievervalsing, op welk gebied dan ook, niet goed is. En Microsoft heeft wel degelijk een dikke vinger in de pap. Ze hebben al de nodige onfatsoenlijke uitspraken gedaan richting de Linux-community, en het is duidelijk wat hun mentaliteit naar die groep is. Ze zullen het wellicht niet (meer) hardop zeggen, maar ze willen er absoluut alles aan doen om Linux zo klein mogelijk te houden. Ik sluit zeker niet uit dat ze ATI en NVIDIA toch 'sterk geadviseerd' hebben om de 3D-accelleratie op Linux niet in de buurt te laten komen bij die op hun platform, om zodoende maar het beeld te behouden dat Windows het beste OS zou zijn.
Daarnaast lijken mensen maar niet te beseffen dat je ook andere dingen met videokaarten kan doen dan spelletjes spelen; juist op Linux...
Overigens is iOS een BSD/Mach-variant; géén Linux-variant.
@player-x
Je kan Linux-gebruikers wel kleineren, maar de Linux-community doet in ieder geval nog actief z'n best om zélf goed werkende software te maken, omdat hen niet alles komt aangewaaid. Op het Windows-platform hebben gebruikers gewoonweg geen keuze, dus het maakt daar niets uit als Microsoft een ondermaats OS maakt of NVIDIA of ATI ondermaatse drivers maken. Je moet het gebruiken; het wordt meegeleverd of er zijn geen alternatieven beschikbaar. En die lock-in die daarmee ontstaat, gebruiken ze om gebruikers onwetend te houden. Weten zij veel dat er alternatieven zijn. En dat houden ze ook graag zo. Want ze vinden het heerlijk; 90% van de markt in handen met een OS waarvan het lang niet zo is dat het ook écht de beste optie is.
En als sommige gebruikers er wel achter komen dat er alternatieven zijn, wordt het ze wel heel moeilijk gemaakt omdat vrijwel alle Windows-programma's Windows-only zijn. Natuurlijk zijn er prima werkende alternatieven, maar dan moet je wel weten welke dat zijn, en de kleine verschillen onder de knie gaan krijgen.
En dat leidt tot allerlei obscure bestandsformaten, gesloten drivers waar niemand van mag weten hoe ze werken en zodoende het idee dat Linux minder goed zou zijn omdat het een kleine speler is. Dus hoe noemen we Windows-gebruikers dan? Neo-imperialisten met een "wir haben es nicht gewusst"-mentaliteit? Overal is een naam voor te verzinnen, maar ik denk dat iedereen het er wel over eens is dat concurrentievervalsing, op welk gebied dan ook, niet goed is. En Microsoft heeft wel degelijk een dikke vinger in de pap. Ze hebben al de nodige onfatsoenlijke uitspraken gedaan richting de Linux-community, en het is duidelijk wat hun mentaliteit naar die groep is. Ze zullen het wellicht niet (meer) hardop zeggen, maar ze willen er absoluut alles aan doen om Linux zo klein mogelijk te houden. Ik sluit zeker niet uit dat ze ATI en NVIDIA toch 'sterk geadviseerd' hebben om de 3D-accelleratie op Linux niet in de buurt te laten komen bij die op hun platform, om zodoende maar het beeld te behouden dat Windows het beste OS zou zijn.
[Reactie gewijzigd door Arcadia op woensdag 21 maart 2012 16:34]
Veel servers hebben juist wel degelijk een FireGL-kaart, die gebaseerd is op een low-end Radeon GPU... 
Dat klopt.. Of ook heel lang nvidia riva ..Veel servers hebben juist wel degelijk een FireGL-kaart, die gebaseerd is op een low-end Radeon GPU...
Helaas komt het hier in praktijk wel op neer. Het probleem is ook een vicieuze cirkel: De grootste reden dat er weinig gegamed wordt onder Linux is het gebrek aan echte goede graka drivers. Hierdoor komen er geen grote games voor Linux uit. Doordat er weinig gegamed wordt, hechten AMD/nVidia minder belang aan hun drivers, waardoor het aantal games/gamers bij Linux niet groter wordt.
Als ik met vrienden wat ga Lannen, en er wordt UT gespeeld, draai ik dit gewoon native onder Linux. Dit draait echt prima en is gewoon echt makkelijk te installeren. Bij gentoo staat UT2004 gewoon in de package manager, en kan je het dus daarlangs installeren, mits je de DVD in de drive doet.
Eigenlijk zou games onder Linux helemaal niet zo heel moeilijk moeten zijn, tenminste niet games die ook op de PS3 draaien, deze gebruikt immers OpenGL (ik dacht de embedded versie).
Wat misschien ook wel wat meespeelt, is de grote verscheidenheid in Distro's. Hoewel de meeste distro's technisch niet zo heel veel van elkaar verschillen, moet een spel wel op een stuk of 8 distro's getest worden voordat het verkocht kan worden. Dit is natuurlijk niet ideaal.
Als ik met vrienden wat ga Lannen, en er wordt UT gespeeld, draai ik dit gewoon native onder Linux. Dit draait echt prima en is gewoon echt makkelijk te installeren. Bij gentoo staat UT2004 gewoon in de package manager, en kan je het dus daarlangs installeren, mits je de DVD in de drive doet.
Eigenlijk zou games onder Linux helemaal niet zo heel moeilijk moeten zijn, tenminste niet games die ook op de PS3 draaien, deze gebruikt immers OpenGL (ik dacht de embedded versie).
Wat misschien ook wel wat meespeelt, is de grote verscheidenheid in Distro's. Hoewel de meeste distro's technisch niet zo heel veel van elkaar verschillen, moet een spel wel op een stuk of 8 distro's getest worden voordat het verkocht kan worden. Dit is natuurlijk niet ideaal.
Met een beetje degelijk package management zouden game-ontwikkelaars de meeste problemen op dat gebied kunnen voorkomen door alle dependencies goed aan te geven. Dan zou je in ieder geval op alle Debian-afgeleiden met apt/dpkg nooit op die problemen kunnen lopen, en voor zo ver ik weet werkt het met yum / yaourt / emerge en alle andere mogelijkheden niet heel anders.
Je zou hoogstens met het probleem kunnen komen te zitten dat bepaalde behoudende enterprise distro's nog niet de benodigde versies van de pakketten in de repositories hebben zitten; maar dan zou je altijd nog kunnen kiezen voor een testing/unstable-repository, die in de praktijk vaak lang niet zo instabiel is als men wil beweren.
Maar als je nu kijkt hoeveel Linux-gebruikers Ubuntu / Mint / Fedora etc. draaien, komt dat allemaal wel goed. En zij die Debian / CentOS / RHEL draaien, weten ook zelf wel hoe ze met de repositories moeten omgaan. Al denk ik niet dat je veel gamers in die groep zult vinden.
Je zou hoogstens met het probleem kunnen komen te zitten dat bepaalde behoudende enterprise distro's nog niet de benodigde versies van de pakketten in de repositories hebben zitten; maar dan zou je altijd nog kunnen kiezen voor een testing/unstable-repository, die in de praktijk vaak lang niet zo instabiel is als men wil beweren.
Maar als je nu kijkt hoeveel Linux-gebruikers Ubuntu / Mint / Fedora etc. draaien, komt dat allemaal wel goed. En zij die Debian / CentOS / RHEL draaien, weten ook zelf wel hoe ze met de repositories moeten omgaan. Al denk ik niet dat je veel gamers in die groep zult vinden.
[Reactie gewijzigd door Arcadia op woensdag 21 maart 2012 19:39]
Laten we even duidelijk zijn over Games op Linux:
Dat dit niet zo lekker gaat heeft lang niet altijd iets met de drivers te maken, maar meer met DirectX - of de afwezigheid daarvan.
In mijn ervaring (Phenom X4, HD6770, Catalyst 12.2) loopt iedere game geschreven voor OpenGL lekker op een Linux bak (uitzonderingen daartgelaten). Er zijn moderne Games die (ook) een OpenGL renderer aan boord hebben. Ik roep maar Left 4 dead, Portal, Baldur's Gate, Half Life, Oilrush, Neverwinternights, en wat al niet meer. Deze kun je allemaal, met goede performance, spelen op Linux/iOS. Ook kun je best veel DirextX games (hoewel niet optimaal) aan de praat krijgen met Wine.
Als hier iemand debet aan is, dan is dat de Games Industrie. Zij hebben DirectX (gratis, closed source grafische APIs) heilig verklaard en daarom is het niet mogelijk om alle mainstream games (uitzonderingen daargelaten) zonder meer te spelen op Linux. Natuurlijk zal de industrie incl. AMD haar pijlen richten op dat wat mainstream is...
Helaas zijn dat de feiten.
Dat dit niet zo lekker gaat heeft lang niet altijd iets met de drivers te maken, maar meer met DirectX - of de afwezigheid daarvan.
In mijn ervaring (Phenom X4, HD6770, Catalyst 12.2) loopt iedere game geschreven voor OpenGL lekker op een Linux bak (uitzonderingen daartgelaten). Er zijn moderne Games die (ook) een OpenGL renderer aan boord hebben. Ik roep maar Left 4 dead, Portal, Baldur's Gate, Half Life, Oilrush, Neverwinternights, en wat al niet meer. Deze kun je allemaal, met goede performance, spelen op Linux/iOS. Ook kun je best veel DirextX games (hoewel niet optimaal) aan de praat krijgen met Wine.
Als hier iemand debet aan is, dan is dat de Games Industrie. Zij hebben DirectX (gratis, closed source grafische APIs) heilig verklaard en daarom is het niet mogelijk om alle mainstream games (uitzonderingen daargelaten) zonder meer te spelen op Linux. Natuurlijk zal de industrie incl. AMD haar pijlen richten op dat wat mainstream is...
Helaas zijn dat de feiten.
[Reactie gewijzigd door mrlammers op woensdag 21 maart 2012 16:37]
Afwezigheid van DirectX is echt het probleem niet voor games op Linux. Zodra de markt er is, komt er een OpenGL-versie. Kijk maar naar de Mac, waar ook geen DirectX te bekennen is. Sterker nog, kijk naar Android. Het is Linux, maar dat is geen enkel probleem: de markt is er, dus er verschijnen games.
Huh? Maar dat snap ik al niet. In tegenstelling tot DirectX is OpenGL cross platform, dus waarom dat niet in de eerste plaats doen dan? Daar verbreed je toch alleen je doelgroep/markt mee?Zodra de markt er is, komt er een OpenGL-versie
Verder heeft Microsoft met de introductie van Vista de wereld bang gemaakt voor OpenGL, de OpenGL Architecture Review Board verlaten, DirectX10 gepresenteerd als Holy Grail en gedreigd OpenGL als een laag over D3D heen te leggen.
De Games Industrie slikte het als zoete koek.
Verder zou ik geen geld zetten op OpenGL versies van games 'als de markt er is'. Ontwikkeling van games duurt jaren en als vooraf niet bepaald is dat er een OpenGL versie moet komen, dan komt ie er ook niet (Tenzij een groepje fanatici de koppen bijelkaar steekt om er een projectje van te maken).
[Reactie gewijzigd door mrlammers op woensdag 21 maart 2012 17:18]
Met OpenGL versmal je je doelgroep, omdat je er niet zeker van kan zijn dat het onder Windows werkt. Voor Windows gebruik je dus gewoon DirectX; voor Mac (& iOS) en Linux (& Android) gebruik je OpenGL. Een engine ombouwen naar OpenGL is nou ook weer niet zo onoverkomelijk dat je er jaren over gaat doen.
Mocht een game te veel aan de W32 API gekoppeld zijn, dan kan er altijd nog voor worden gekozen om een compatibility library te gebruiken zoals Wine, die de W32 API vrijwel volledig implementeert. Zo hebben game publishers ook veel games op de Mac gepubliceerd toen dat net populair begon te worden.
Mocht een game te veel aan de W32 API gekoppeld zijn, dan kan er altijd nog voor worden gekozen om een compatibility library te gebruiken zoals Wine, die de W32 API vrijwel volledig implementeert. Zo hebben game publishers ook veel games op de Mac gepubliceerd toen dat net populair begon te worden.
Tuurlijk slikt industrie het voor zoete koek, die heeft maar een belang, en dat is geld verdienen, en hoe mooi Linux ook mag zijn, het is een nagenoeg irrelevante onderdeel van waar ze hun geld kunnen verdienen.De Games Industrie slikte het als zoete koek.
Is een poort naar Linux goedkoop genoeg of de game groot genoeg (WoW), dan zullen de bean counters uitrekenen dat, hey we kunnen een beetje geld verdienen aan een Linux poort.
Als de cijfers onder de streep in het rood uitkomen, wat meestal gebeurd, dan laten ze een Linux vallen, het is zo simpel.
En MS doet wat het doet, ook puur uit eigen belang, ben nog nooit een echte fan geweest van MS, vroeger had ik er zelfs een hekel aan hoe ze zaken deden, maar tegenwoordig is MS helemaal niet meer anti Linux, en de reden om te overwegen om OpenGL als een laag over D3D heen te leggen, puur financieel is en echt niet meer om Linux te dwarsbomen.
De games industrie is al volop bezig met Linux games, er zijn zat games verkrijgbaar voor Android. De Linux desktop markt is voor een game developer veel te gefragmenteerd, maar 1% marktaandeel, en dan nog verdeeld over tientallen distro's, en ontelbare combinaties van verschillende X Window versies, dependencies en drivers.
[Reactie gewijzigd door Dreamvoid op woensdag 21 maart 2012 17:05]
Ik denk dat die 1% wel groter is, alleen zullen veel linux desktop gebruikers voor het gemak een dual boot gebruiken: het is kip-ei, als de externe driver en game support beter wordt (al is deze al behoorlijk ok bij nvidia) dan zal dat aandeel vanzelf rap omhoog gaan.
Ook diverse externe support zal dan vanzelf groeien, hetzelfde zag je bij osx gebeuren.
Ook diverse externe support zal dan vanzelf groeien, hetzelfde zag je bij osx gebeuren.
Na een beetje rond te kijken lijkt het linux gedeelte te liggen rond de 1.6%. Er zijn veel bronnen beschikbaar dus een beetje op het gevoel een gemiddelde getrokken.
1.6 is niet veel maar met de geschatte desktops op 1 miljard heb je het toch over 16 miljoen desktops.
1.6 is niet veel maar met de geschatte desktops op 1 miljard heb je het toch over 16 miljoen desktops.
Er zouden alleen al zo'n 20 miljoen Ubuntu-"desktops" (inclusief laptops etc.) in gebruik zijn, dus die 1.6% lijkt me nogal laag geschat dan...
Uiteraard zullen daar veel dual boots bij zijn, dus machines die ook Windows (en/of Mac OS X) draaien. En mogelijk worden ook derivate distro's als Mint & Deepin meegeteld (waarbij gebruikers van die laatste in de meeste westerse webstats nauwelijks zullen opduiken).
Uiteraard zullen daar veel dual boots bij zijn, dus machines die ook Windows (en/of Mac OS X) draaien. En mogelijk worden ook derivate distro's als Mint & Deepin meegeteld (waarbij gebruikers van die laatste in de meeste westerse webstats nauwelijks zullen opduiken).
Het probleem is als mensen dual booten linux/windows osx/linux dan word het alleen als windows of mac gerekent
CUDA en OpenCL worden volop gebruikt in High Performance omgevingen, en dat wordt gedomineerd door Linux. Dat gedeelte van Linux graphics drivers is dan ook prima in orde. Echte consumenten-features zoals NVIDIA's Optimus en ondersteuning voor de nieuwste desktopomgevingen, dat is minder een prioriteit.Als dingen als OpenCL echt interessant worden op servers, dan zal er vast wel een Linux OpenCL driver uit komen.
Er is een heel groot verschil tussen het model van de Windows kernel en die van Linux m.b.t. integratie van drivers. Ik denk dat je daar mee in de war bent.
De kernel van Windows heeft een erg stabiele API, ook richting drivers. Dit is onder andere meer dan noodzakelijk omdat de sourcecode van Windows closed source is. Dit model maakt het mogelijk dat hardwarefabrikanten zelf drivers ontwikkelen zonder betrokken te zijn bij het ontwikkelingsproces van de Windows kernel zelf.
De Linux kernel heeft eigenlijk niet eens een echte API richting drivers. Hoewel een driver in de vorm van een module kan worden gecompileerd, is deze module wel zeer afhankelijk van de versie van de kernel waartegen deze gecompileerd is. Dit betekend dus ook dat hardwarefabrikanten niet zomaar op hun eigen zolderkamertje een driver kunnen maken, eigenlijk is het vereist dat de code hiervan in de Linux sourcecode boom wordt opgenomen. Dit is wat hier wordt bedoeld.
Als je hier meer over wilt weten: http://www.linuxfoundatio...ab/linuxdevicedrivermodel
Verder vraag je je af waarom hardwarefabrikanten eerst hardware uitbrengen en dan pas drivers... Dit is om een heel simpele reden: Time to market
De kernel van Windows heeft een erg stabiele API, ook richting drivers. Dit is onder andere meer dan noodzakelijk omdat de sourcecode van Windows closed source is. Dit model maakt het mogelijk dat hardwarefabrikanten zelf drivers ontwikkelen zonder betrokken te zijn bij het ontwikkelingsproces van de Windows kernel zelf.
De Linux kernel heeft eigenlijk niet eens een echte API richting drivers. Hoewel een driver in de vorm van een module kan worden gecompileerd, is deze module wel zeer afhankelijk van de versie van de kernel waartegen deze gecompileerd is. Dit betekend dus ook dat hardwarefabrikanten niet zomaar op hun eigen zolderkamertje een driver kunnen maken, eigenlijk is het vereist dat de code hiervan in de Linux sourcecode boom wordt opgenomen. Dit is wat hier wordt bedoeld.
Als je hier meer over wilt weten: http://www.linuxfoundatio...ab/linuxdevicedrivermodel
Verder vraag je je af waarom hardwarefabrikanten eerst hardware uitbrengen en dan pas drivers... Dit is om een heel simpele reden: Time to market
[Reactie gewijzigd door metaal op woensdag 21 maart 2012 16:05]
Open of closed source maakt in principe niet uit, de OS X kernel is open source en heeft ook een stabiele driver API. Het is meer dat zowel Apple als MS afdwingen dat je als driver bouwer de API *moet* gebruiken en niet zomaar wat kernel code mag aanpassen om je driver werkend te krijgen. Bij BSD werkt het in principe ook zo, de API is heilig. Linux is veel vrijer, iedereen mag zelf naar hartelust in de kernel gaan prutsen en zijn eigen code erin duwen. Er is ook niemand die de macht heeft om 1 stabiele API af te dwingen.Dit is onder andere meer dan noodzakelijk omdat de sourcecode van Windows closed source is.
[Reactie gewijzigd door Dreamvoid op woensdag 21 maart 2012 17:01]
'In principe' had Microsoft elk model kunnen kiezen, maar ik denk niet dat het erg praktisch zal zijn om met een closed source kernel eenzelfde model te gebruiken zoals Linux dat doet. Ik bedoel, zelfs al zouden ze dat willen... Dit zou voor IHVs betekenen dat ze enorm veel onderhoud moeten plegen op hun drivers, of heel snel hardware niet meer kunnen ondersteunen.
Niemand?
Ditr is een punt wat ik al veel vaker heb aangehaald. Eerste de api, dan de drivers, dan de rest. Maar daar is niet iedereen hier het mee eens.
Ditr is een punt wat ik al veel vaker heb aangehaald. Eerste de api, dan de drivers, dan de rest. Maar daar is niet iedereen hier het mee eens.
Dat is de typische BSD filosofie.
In de praktijk laat Linux zien dat het allebei kan, als je maar genoeg uren instopt kan je elke chaos rechtbreien, en met onvoldoende uren wordt zelfs de mooiste architectuur niet volwassen.
In de praktijk laat Linux zien dat het allebei kan, als je maar genoeg uren instopt kan je elke chaos rechtbreien, en met onvoldoende uren wordt zelfs de mooiste architectuur niet volwassen.
[Reactie gewijzigd door Dreamvoid op woensdag 21 maart 2012 18:55]
Misschien begrijp ik het niet.De kernel van Windows heeft een erg stabiele API
Je bedoelt dat er zelden interfaces en functies uit Windows APIs verwijderd worden en daarom vaker en langer backwards compatible blijven? Stabiel als in conservatief? Je bedoelt die dingen die de blauwe schermen veroorzaken? user32.dll? ntoskrnl.exe?
Misschien begrijp ik het verkeerd, maar je eigen referentie zegt:
Voor veel mensen is falende hardware een veel groter risico dan een stuk software dat weigert...But the biggest problem with the Windows model is that stable device driver ABIs do not actually remain stable. Microsoft has modified the Windows ABI in every Windows release, resulting in a relentless succession of hardware support issues. Any change in the ABI can cause hardware to stop working correctly, and can even crash the entire OS.
Zo heb je toch meer zekerheid dat je I/O het blijft doen, toch?By contrast, the Linux kernel does provide a stable userspace interface for Linux applications.
Wist je dat drivers die eenmaal in de Linux kernel zijn opgenomen bij elke nieuwe kernel versie worden geüpdate? En dat de hardwareondersteuning in Linux hierdoor nooit slechter wordt, maar alleen maar beter? En dat applicaties gecompileerd voor versie 1.0 het ook nog zullen doen op 3.3?
Tis wel van de Linux Foundation he, die gaan niet vertellen dat hun driver model een rommeltje is Als je dat verhaal leest is het compleet rozegeur en maneschijn in Linuxland, en is het een bijkans een wonder dat Windows/OS X uberhaupt nog boot. In de praktijk heeft de succesvolste Linux distro (Android) al zijn gfx drivers als binary blobs, net als de enige fatsoenlijke Linux+X gfx driver (nVidia). En die blobs bieden aan game developers, hou je vast, een...stabiele API!
Als je dat verhaal leest is het compleet rozegeur en maneschijn in Linuxland, en is het een bijkans een wonder dat Windows/OS X uberhaupt nog boot. In de praktijk heeft de succesvolste Linux distro (Android) al zijn gfx drivers als binary blobs, net als de enige fatsoenlijke Linux+X gfx driver (nVidia). En die blobs bieden aan game developers, hou je vast, een...stabiele API!Feit is wel dat een stabiele API vooral een wens is, maar nooit echt een werkelijkheid. De veranderingen in Windows komen hooguit langzamer, maar ze komen wel. Het gaat eigenlijk niet eens zozeer om de API zelf, maar om het ontwikkelmodel. Alle ontwikkeling in een gedeelde tree doen is (volgens de Linux-ontwikkelaars) een beter ontwikkelmodel dan een stabiele API en aparte ontwikkel-eilandjes voor elke fabrikant. Hardware is vaak meer gelijk dan verschillend, waardoor met het Linux-model een boel duplicatie voorkomen kan worden. Voor Linux is zo'n stabiele API dan eigenlijk overbodige moeite, omdat men liefst toch alle code bij elkaar heeft.
Case in point: de propriëtaire drivers van NVIDIA en AMD negeren een groot deel van de Linux graphics stack en implementeren beide hun eigen versie van memory management, shader compiler, modesetting, userspace API's zoals OpenGL en OpenCL enzovoorts. Dit is een gevolg van de eilandjes-mentaliteit van deze fabrikanten.
Case in point: de propriëtaire drivers van NVIDIA en AMD negeren een groot deel van de Linux graphics stack en implementeren beide hun eigen versie van memory management, shader compiler, modesetting, userspace API's zoals OpenGL en OpenCL enzovoorts. Dit is een gevolg van de eilandjes-mentaliteit van deze fabrikanten.
ntoskrnl.exe is de eigenlijke kernel, en die heeft een ABI die niet zo stabiel is als sommigen schijnen te denken; de rest zijn libraries/APIs daar bovenop (zowel in kernel space als in user space) die wel grotendeels vastliggen.
@mrlammers, ik bedoel in deze context uiteraard de API die je gebruikt als je een driver schrijft. Ik heb het dus niet over bijvoorbeeld functies als CreateFile() of CloseHandle(), maar zoiets als IoCreateDevice(). De laatst genoemde functie kan je niet vanuit een normale executable gebruiken.
En met stabiel bedoel ik inderdaad dat er geen veranderingen in de interface worden gemaakt. Anders zou het nooit mogelijk zijn dat een hardwareboer binary drivers op een CDtje zet die op alle versies van bijvoorbeeld Windows XP werkt. 'Stabiel' heeft in deze niets te maken met blauwe schermen e.d. Een API (interface) kan geen blauwe schermen veroorzaken, enkel de implementatie of de gebruiker (executable in dit geval) ervan.
Ik denk ook dat je de volgende zin verkeerd interpreteerd:
Wees ook voorzichtig met de uitspraken op het einde van je reactie:
En met stabiel bedoel ik inderdaad dat er geen veranderingen in de interface worden gemaakt. Anders zou het nooit mogelijk zijn dat een hardwareboer binary drivers op een CDtje zet die op alle versies van bijvoorbeeld Windows XP werkt. 'Stabiel' heeft in deze niets te maken met blauwe schermen e.d. Een API (interface) kan geen blauwe schermen veroorzaken, enkel de implementatie of de gebruiker (executable in dit geval) ervan.
Ik denk ook dat je de volgende zin verkeerd interpreteerd:
Wat hier staat is dat de API richting userspace wel stabiel is, ongeveer netzoals dat bij de Windows API voor userspace processen het geval is, dit in tegenstelling tot de Linux driver API die absoluut niet stabiel is..By contrast, the Linux kernel does provide a stable userspace interface for Linux applications.
Wees ook voorzichtig met de uitspraken op het einde van je reactie:
Zoals al eerder gezegd werd, ook bij Linux is het niet enkel rozengeur en manenschijn, zeker in de graphische hoek. Als een driver niet genoeg aandacht krijgt (te weinig gebruikers / geen ontwikkelaars die het willen onderhouden) dan wordt die op den duur gewoon uit de kernel gewipt.Wist je dat drivers die eenmaal in de Linux kernel zijn opgenomen bij elke nieuwe kernel versie worden geüpdate? En dat de hardwareondersteuning in Linux hierdoor nooit slechter wordt, maar alleen maar beter?
Is dit ook goed nieuws voor FreeBSD-gebruikers? Dat kan ik nu namelijk nog niet goed op mijn desktop draaien...
Ik neem aan dat er vrij eenvoudige ports voor te maken zijn ja. Ik heb niet heel veel praktijkervaring met BSD, maar voor zover ik weet zijn ze qua licensing nog makkelijker dan de GPL, en de codebase is in veel gevallen nagenoeg gelijk. Het enige probleem zou kunnen zijn dat de community nog kleiner is dan die van Linux; dus dat je wel één of meerdere mensen moet vinden die de port willen maken.
Voorzover ik weet neemt alleen nVidia de moeite om goede grafische drivers voor FreeBSD te leveren. Zeker als je aan 3D of video-acceleratie (VDPAU) gaat doen.
ik ben bang dat dit niet echt nieuws is voor FreeBSD gebruikers. FreeBSD draait immers op een compleet andere kernel dan Linux.
ze lijken toch veel op elkaar
en met de source code voor de linux kernel is prima na te gaan hoe de GPU aangestuurd moet worden, wat vertaalt kan worden naar freebsd.
maar dan moet wel iemand de moeite nemen om dat te doen.
en met de source code voor de linux kernel is prima na te gaan hoe de GPU aangestuurd moet worden, wat vertaalt kan worden naar freebsd.
maar dan moet wel iemand de moeite nemen om dat te doen.
BSD is op kernel niveau compleet anders dan Linux. Er draaien wel dezelfde Unix/POSIX libraries bovenop waardoor je het als applicatie niet echt merkt, maar het zijn fundamenteel andere operating systems. Voor een BSD Radeon driver kan AMD beter hun OS X code gebruiken, dat is ook een BSD variant.
[Reactie gewijzigd door Dreamvoid op woensdag 21 maart 2012 17:23]
Qua grafische zooi verschillen de Mac OS X kernel en de FreeBSD kernel echter wel heel erg, dus dat lijkt me niet...
Mooi, eindelijk ziet AMD in dat als ze zelf niet de moeite willen nemen om met iets propers te komen (lees goed werkende Catalyst drivers) ze beter het werk kunnen uitbesteden aan de Linux community.
Het gaat al lang niet meer over alleen gamen; vooral wetenschapelijke taken, waar GPGPU erg van pas kan komen profiteren hiervan. "1% marktaandeel", zoals eerder gesuggereerd werd, gaat in dit geval zeker niet op: https://upload.wikimedia....op_500_supercomputers.svg .
Gamen doe je idd wel nogsteeds op je Wintendotje.
Het gaat al lang niet meer over alleen gamen; vooral wetenschapelijke taken, waar GPGPU erg van pas kan komen profiteren hiervan. "1% marktaandeel", zoals eerder gesuggereerd werd, gaat in dit geval zeker niet op: https://upload.wikimedia....op_500_supercomputers.svg .
Gamen doe je idd wel nogsteeds op je Wintendotje.
[Reactie gewijzigd door C.Hariri op woensdag 21 maart 2012 16:37]
Tja, zelfs wetenschappelijke taken is niet heel interessant voor de fabrikanten van videokaarten, denk ik. Je stuurt de link naar de top-500 supercomputers. Linux heeft wel een enorm marktaandeel in deze top, maar het zijn er slechts 500...
Volgens http://www.mobilecowboys.nl/gadgets/16040 zijn er 414,6 miljoen computers verkocht in 2011. Zelfs al zitten er 10.000 grafische kaarten in een supercomputer, dan is het nog steeds slechts 1% van de totale verkoop van grafische kaarten (rekenend met 1 grafische kaart per verkochte pc, het gemiddelde zal daar redelijk bij in de buurt komen).
Ik vind het inderdaad ook het beste dat ze het open source maken: het levert simpel weg te weinig op om zelf mensen te betalen drivers voor *nix te maken.
Volgens http://www.mobilecowboys.nl/gadgets/16040 zijn er 414,6 miljoen computers verkocht in 2011. Zelfs al zitten er 10.000 grafische kaarten in een supercomputer, dan is het nog steeds slechts 1% van de totale verkoop van grafische kaarten (rekenend met 1 grafische kaart per verkochte pc, het gemiddelde zal daar redelijk bij in de buurt komen).
Ik vind het inderdaad ook het beste dat ze het open source maken: het levert simpel weg te weinig op om zelf mensen te betalen drivers voor *nix te maken.
In de praktijk worden 80% of meer van de PCs zonder grafische kaart verkocht...
Maar die leuke GPGPU taken werken vlekkeloos met de gesloten drivers.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
