Intel maakt source grafische Linux-driver openbaar

Intel heeft een website gewijd aan opensource Linux-drivers voor de igp van de 965-chipset. Daarmee is het de eerste gpu-fabrikant die, in samenwerking met X.org, Mesa en de kernelmaintainers, een complete set grafische drivers ter beschikking van de opensourcecommunity stelt. Het werk is nog lang niet af, blijkt uit de teksten op intellinuxgraphics.org, maar het nieuws is niettemin opzienbarend: terwijl ATi en nVidia de broncode van hun grafische drivers met geheimzinnigheid omhullen en zelfs de simpelste pogingen om een open driver te publiceren dwarsbomen, heeft Intel in de open broncode ondersteuning voor onder andere de vertex-, geometry- en fragmentshaders van de 965 verwerkt, waarmee de driver als zeer compleet mag worden betiteld.

De code voor de 2d- en 3d-functionaliteit is overigens onder de MIT-licentie uitgegeven, terwijl de AGP- en direct-renderingsoftware met het GPLv2-papiertje op pad mag. Daarmee is de software geschikt om in elke Linux-distributie verwerkt te worden, in tegenstelling tot de propriëtaire spullen van ATi en nVidia die door diverse fabrikanten geweigerd worden. 'De publicatie van deze drivers is een grote stap voor de evolutie van de industrie', juichte EFF-advocaat Eben Moglen. Intel zelf zou er minder garen bij te spinnen hebben: gebruikers van de intensieve 3d-applicaties waar een dergelijke driver voor nodig is hebben meestal niet de geïntegreerde gpu van Intel, maar een krachtigere kaart van ATi of nVidia in hun systeem zitten.

Toch is Intel met de publicatie eenoog in het land der blinden: 'We zijn ervan overtuigd dat we hiermee een voorsprong nemen', aldus Dirk Hohndel van Intels opensource-ontwikkelcentrum. Opvallend is bovendien dat onder andere Red Hat en Novell net bezig zijn om hun Linux-interfaces van meer eye candy te voorzien, waarbij de 3d-ondersteuning goed van pas komt. De grote vraag is nu of ATi en nVidia zullen volgen. De laatste heeft al laten weten dat het zijn beleid niet zal aanpassen. De vraag is echter of het bedrijf daarin een keuze heeft: AMD zou serieus overwegen om 'een substantieel deel' van de ATi-drivers ook te opensourcen. Zolang het bedrijf eerder is dan nVidia zou ook AMD/ATi hiermee, vooral dankzij betere hardware dan die Intel kan leveren, een aanzienlijke hap uit het Linux-marktaandeel kunnen nemen. Misschien wordt het nog eens wat met gamen onder Linux.

Reacties (62)

[Kanarie]

Misschien wordt het nog eens wat met gamen onder Linux.

Leuk plaagstootje, maar niet helemaal terecht.

De closed drivers van nVidia en Ati zijn qua performances en features al erg goed. De performance van native games (en dat zijn er helaas maar een paar) is daardoor net zo goed als onder Windows.

Het succes van gamen onder linux hangt dus niet meer af van driver support van grafische kaarten, maar van de bereidheid van game developers om linux binaries uit te brengen (en je eigen bereidheid om closed source drivers/kernel modules te gebruiken).

[Verwijderd]

De closed drivers van nVidia en Ati zijn qua performances en features al erg goed. De performance van native games (en dat zijn er helaas maar een paar) is daardoor net zo goed als onder Windows.

Het succes van gamen onder linux hangt dus niet meer af van driver support van grafische kaarten, maar van de bereidheid van game developers om linux binaries uit te brengen (en je eigen bereidheid om closed source drivers/kernel modules te gebruiken).

Het verhaal is natuurlijk iets genuanceerder dan dat de developers gewoon niet 'bereid' zijn om linux binaries uit te brengen. Als het niet al te veel inspanning kost, zijn ze doorgaans bereid (maar dan moeten ze van te voren wel hun game op die manier ontwikkeld hebben, zoals bv Doom3, dat is een keuze, en er zijn goede argumenten voor en tegen die keuze).
Je hebt namelijk meer nodig dan alleen een goede driver. Je moet ook een goede API hebben, en als het even kan, ook nog wat middleware.
Microsoft ontwikkelt altijd druk door aan de D3D-API, en levert goede support, en de D3DX-toolkit wordt steeds krachtiger, en groeit naar middleware toe met XNA.
De OpenGL-API is al erg verouderd, en hoewel fabrikanten altijd de nieuwste functionaliteit toevoegen via extensies, zijn deze vaak niet uitwisselbaar met andere fabrikanten, dus heb je als ontwikkelaar een probleem. Verder werken al die extensies gewoon minder fijn, dat soort dingen gebeuren bij Direct3D achter de schermen, dus in je code hoef je weinig rekening te houden met wat voor hardware je hebt. Je hoeft maar een paar dingen te checken (shader-versies bv), met een simpele functie-call. Bij OpenGL is het vooral met alles lager dan SM2.0 een ramp om shaders of geavanceerde fixed-function te gebruiken. Verder is OpenGL lang niet zo portable als veel mensen schijnen te denken, want de extensies voor dezelfde hardware, van dezelfde fabrikant, willen nog wel eens verschillen (of zelfs ontbreken) op verschillende platformen.

Daarom kiezen veel ontwikkelaars voor hun Windows-games al jaren voor D3D, ipv OpenGL.
En naast D3D zijn er natuurlijk ook nog andere technologieen, zoals DirectSound etc... die het porten naar linux nog lastiger maken. Bij Windows is het dankzij DirectX gewoon een feit dat bijna alle software op bijna alle hardware draait, zonder ook maar enige aanpassingen. De hardware, drivers en API zorgen voor een mooi homogeen geheel. Zolang de programmeurs de API maar goed gebruiken, is de software ook prima compatibel.
Het enige dat linux-gaming succesvol zou kunnen maken, zonder dat linux een groot marktaandeel heeft, zou zijn om een platform-onafhankelijke omgeving te maken rond OpenGL, OpenAL etc, en dat ongeveer te verpakken als DirectX (voornaamste aspecten zijn wel dat het gewoon op alle hardware moet werken, zonder uitzonderingen, dus OpenGL-extensies en OpenAL of andere libraries etc verbergen voor de programmeur, om een zo homogeen en compatibel mogelijke omgeving te maken), maar dan beter, en dit zodanig ontwikkelen dat het in ieder geval 100% compatible is tussen de Windows-versie en de linux-versie.
Dat zal niet gaan gebeuren, dus zal linux gaming ook nooit van de grond komen, zolang Windows een veel groter marktaandeel in handen heeft.

[TheOneLLama]

Dat het grafische gedeelte van OpenGL erg veel achterloopt op op DirectX is onzin. Soms loopt het zelfs voor (straks met geen DX10 op XP al helemaal).

En gebruik maar eens een programmatje als Hardwareinfos om te kijken welke welke extenties alleen maar als ATI of NV beschikbaar zijn, en niet ook als EXT, ARB of gewoon in OpenGL 2.0 zitten.

Ik zal je alvast verklappen dat het voornamelijk dezelfde dingen zijn die je in DirectX OOK apart moet doen voor Ati en nVidia. (als je denkt dat die er niet zijn, dan moet ik je toch echt teleurstellen).

Natuurlijk is OpenGL niet portable als er geen goede drivers zijn voor een bepaald platform, precies waarom dit goed nieuws is.

Andere Microsoft APIs, met name DirectSound en DirectInput zijn wel serieus een stapje beter te noemen als de alternatieven, zoals OpenAL (geluid) en SDL. Maar je kan prima een game ontwikkelen die OpenGL voor de graphics gebruikt en DirectSound en DirectInput voor de rest. Veel makkelijker om uiteindelijk toch te porten (veel kleiner deel van de code), en je hoeft je klanten geen Vista op te dringen als je je game engine nog wat verder door wilt ontwikkelen.

Overigens hoef je mij niet te geloven.. ze zijn dan wel in de minderheid maar er komen regelmatig toch zeer geavanceerde spellen uit die van OpenGL gebruik maken. Nog directer bewijs zijn producten zoals transgaming, die zeer geadvanceerde DirectX programmas runtime naar OpenGL vertalen vrijwel zonder verlies van performance.

[Verwijderd]

Overigens hoef je mij niet te geloven.. ze zijn dan wel in de minderheid maar er komen regelmatig toch zeer geavanceerde spellen uit die van OpenGL gebruik maken. Nog directer bewijs zijn producten zoals transgaming, die zeer geadvanceerde DirectX programmas runtime naar OpenGL vertalen vrijwel zonder verlies van performance.

Ik geloof jou inderdaad niet, want ik heb zelf genoeg ervaring met OpenGL en DirectX, en spreek ook bijna dagelijks daarover met collega's. Velen daarvan prefereren DirectX. OpenGL is bruikbaar, maar dat is niet genoeg, zoals ik al zei. Ik heb nog geen enkel spel gezien dat zo geavanceerd is als de beste Direct3D-spellen (zoals Half-Life 2, Far Cry, FEAR etc).
Het beste OpenGL-spel dat ik ken is Doom3, en dat zal voor de leek hetzelfde zijn, maar de ervaren 3d-programmeur kijkt daar natuurlijk zo doorheen, en ziet dat de shading wel heel eenvoudig is (een GF2 kan het ook, gewoon blinn-phong shading met normalmaps, meer niet), en er eigenlijk maar 1 materiaal/shader gebruikt wordt in het hele spel, waardoor alles een plastic-achtige glans krijgt, of het nu metaal is, karton of mensen (okee, ze hebben wat getweakt zodat mensen minder glimmen, maar het ziet er echt niet uit). Kijk dan eens naar Half-Life 2 waar niet alles glimt, maar waar je ook roest hebt, of kapotte tegeltjes, die niet glimmen, en ook refractie op bewegende objecten, en waar ieder materiaal er echt als dat materiaal uitziet, en niet als een stuk plastic met wat tweaks.
En de echte kracht van Half-Life 2 is dat het heel goed schaalt van simpele hardware tot high-end. Doom3 is een totale ramp op een geintegreerde chipset (als ie uberhaupt al een beetje ondersteund wordt), en de enige non-shaderkaart die ondersteund wordt, is de GeForce1/2.
Half-Life 2 kun je met of zonder shaders spelen, ongeacht de hardware, en zelfs op een onboard chipje kun je het nog best goed spelen, terwijl de graphics er zelfs nog best goed uitzien, want er wordt goed gebruik gemaakt van de fixedfunction shading modes en SM1.x, wat bij OpenGL niet te doen is omdat dat niet onder een ARB/EXT-standaard valt. Een hele generatie hardware wordt dus gewoon genegeerd door de API.

TransGaming is leuk, maar het is geen 1:1 vertaling.
Bepaalde dingen zullen niet (of niet goed) vertaald worden naar OpenGL, terwijl ze in Windows op dezelfde hardware wel zouden werken.
Dus in feite draai je dan op lagere kwaliteit. Dan is het niet zo moeilijk om geen performance te verliezen.
De uitgevoerde code is niet 1:1, de beeldkwaliteit is niet 1:1 en dus kun je ook de performance niet 1:1 vergelijken.

Als ik bv hier kijk, zie ik het volgende:

- Amd Athlon XP 3000+ standard clock speed.
- 1024mb/3200 crucial and generic ram.(512x2)
- Edubuntu 5.40 with patched 2.6.16 kernel.(uname -r 2.6.16-ck3)
- VIA KT266/333 (I believe) motherboard. (I'll confirm this in the future.)
- MSI GeForce NX6600 256mb agp 8x, running in 4x

+ Properties
- Pixal Shaders 1.4.
- 256 video ram, 128 vertex.
- Decreased wineserver.
- Windows 98 emulated environment.
- Everything else in Cedega P2P properties default.
- Heapsize 250000.
- DirectX level 8.1. (I believe 8.1, corrections will be made in the future.)
- 40 seconds to start up.
- 60 seconds to load previously saved game.
- Average frame rate: 7-65fps.

Ten eerste is een 6600 natuurlijk geen SM1.4-kaart, dus waarom werkt ie niet als SM2.0?
Ten tweede zijn die framerates wel heel laag voor een dermate krachtig systeem. In Windows zou dat veel sneller lopen.
Dus mindere graphics en mindere performance.... u zei?

[TheOneLLama]

Ik zou zeggen, maak eens een spel met Direct X dat eruit ziet alsof je een Doom3 engine hebt wat op een Geforce2 kan draaien...

Je lult natuurlijk enorm uit je nek.. het ergste is dat je waarschijnlijk beter weet. Je weet net zo goed als ik dat HalfLife2 aparte renderpaden heeft voor aparte versies van DirectX.

Je kan net zo makkelijk (of makkelijker zelfs, je hoeft niet met de soms absurde verschillen tussen verschillende DirectX versies om te gaan) met OpenGL verschilldende renderpaden maken. Dat Carmack dit minder doet voor Doom3 wil niet zeggen dat het niet kan. De man richt zich nou eenmaal op meer highend systemen dan ze bij Valve doen.

Je doet haast alsof de shaders die in HalfLife2 zitten niet gewoon net zo makkelijk in OpenGL gebruikt kunnen worden. Je hebt precies hetzelfde niveau van toegang tot de verschillende shader functies (1.x-3.x). Het enige verschil zit in de high level taal (HLSL vs. GLSL).. Dus ja, ook met OpenGL kun je wat roest op een tegeltje pleuren. Door helemaal zelf je shader te tikken, met GLSL of met Cg.

Dan dit gelul dat je SM1.x niet zou kunnen gebruiken omdat het een ARB extentie is! Nu val je echt door het ijs... ARB is de manier waarop vendors afspreken verschillende extenties te standardizeren, zodat je ze op alle verschillende hardware kan gebruiken. Verder werkt het precies hetzelfde als hoe de rest van OpenGL werkt. Alle hardware die shaders ondersteunen hadden dan ook bijna onmiddelijk drivers, en sinds die dag kun je gewoon 1.x shaders gebruiken.

ARB is een platform waar verschillende partijen samenwerken om een standaard te maken. Het is niet zoals Direct X 1 bedrijf wat z'n monopolie gebruikt om het hele tempo van ontwikkeling aan de markt op te leggen. en af en toe natuurlijk een favoriete hardware partner kiest die dan wat voordeel op de rest heeft.

Over transgaming nog even dan.. ik beweer niet dat transgaming hele spellen op volle snelheid kan emuleren, end dat het zich ook nog eens op alle generaties hardware richt. Ik beweer dat als men zich toelegt op een vertaling van van een bepaalde Dirext X functie naar OpenGL dat dit bijna altijd zonder snelheids verlies is. Wat ik alleen maar zeg om aan te geven dat inhoudelijk OpenGL en DirectX weinig verschillen.

Het enige waar je (indirect) een punt hebt, is dat OpenGL slechtere driver ondersteuning heeft. Tenminste, als je het vanuit de windows-only wereld bekijkt.. Dirext X draait niet bepaald lekker op linux/macintosh etc. eh?

Die slechte ondersteuning beperkt zich echter tot bedrijven als SiS/S3 ed. die het ook met DirectX niet al te best doen, en tot voor kort Intel's geintregreerde chipsets. Gelukkig is de OpenGL ondersteuning hiervan verbeterd de laatste tijd, want dit is wel een belangrijke partij voor bepaalde game makers. niet dat veel high end DirectX games zich hier op richten overigens!

Ik zal even quoten waar ik oorspronkelijk op reageerde: "De OpenGL-API is al erg verouderd". Je moet toegeven dat ik aangetoond hebt dat dit onzin is..

"en hoewel fabrikanten altijd de nieuwste functionaliteit toevoegen via extensies, zijn deze vaak niet uitwisselbaar met andere fabrikanten, dus heb je als ontwikkelaar een probleem." En later zei je het ook, je zou geen PS1.x kunnen gebruiken omdat het zo'n extentie is. Nu weet je dat je ARB/EXT juist wel op alle hardware kan gebruiken (en met name ARB is ook bijna altijd door nVidia/Ati/Intel geimplementeerd, soms als EXT al voordat de DirectX versie voor zo een feature uit is).

Natuurlijk snap ik best dat de meeste game makers Direct X kiezen.. het dekt goed hun markt, en het geeft een bepaalde zekerheid. Je hoeft je geen zorgen te maken dat MS opeens dreigt de ondersteuning te blokkeren (zie het net verschenen artikel.. als OpenGL developer heb je toch bijna een jaar tot de knieen in de FUD gezeten), of dat iemand bij Intel/AtiAMD/nVidia besluit de OpenGL ondersteuning even op een laag pitje te zetten. De voordelen van OpenGL zijn niet zo belangrijk..

- cross platform, natuurlijk. (Unix/Linux/Mac/Windows/Embedded/Mobiel/etc./x86(-64)/IA64/PPC/Sparc/ARM/etc.)
- stabiele basis API. Games worden vaak relatief snel ontwikkeld.. je pakt de nieuwste DirectX en tegen de tijd dat je klaar bent heb je hooguit 1 keer een nieuwe Direct X upgrade meegemaakt, en misschien 2 of 3 keer een kleine. (En als je een beetje belangrijk bent krijg je ook early acces releases etc). Als je een veel langlopender project met lagere budgetten doet echter is het fijn als de API niet steeds wijzigd wordt.
- Minder angst voor dead end platformen (zoals XP bij DX10)
- Zelf invloed kunnen hebben op de ontwikkeling van de API via ARB (zelfs zonder lid te zijn kan dat). je moet wel HEEL belangrijk zijn om dat bij Direct X te hebben.
- Makkelijker voor beginners (we zullen maar geen flamewars beginnen over welk API beter/eleganter etc. is, maar je moet toch toegeven dat voor een beginner OpenGL fijner is).

Of ga anders eens terug in de tijd en vergelijk spellen die en Direct X en OpenGL ondersteunde (bv HalfLife 1, de UTs) en je zult zien dat het tot de dag van de ontwikkelingen bij heeft gehouden. Kijk eens op game developer's fora en probeer een effect te vinden uit HL2 wat niet in OpenGL nagemaakt kon worden, door een paar hobbyisten. Of wacht anders ff op de nieuwste UT engine of op de PlayStation3.

Je hoeft echt niet zo dogmatisch te doen over OpenGL alleen omdat jij toevallig met Direct X ontwikkelt.

[johnbetonschaar]

Het enige dat linux-gaming succesvol zou kunnen maken, zonder dat linux een groot marktaandeel heeft, zou zijn om een platform-onafhankelijke omgeving te maken rond OpenGL, OpenAL etc, en dat ongeveer te verpakken als DirectX (voornaamste aspecten zijn wel dat het gewoon op alle hardware moet werken, zonder uitzonderingen, dus OpenGL-extensies en OpenAL of andere libraries etc verbergen voor de programmeur, om een zo homogeen en compatibel mogelijke omgeving te maken), maar dan beter, en dit zodanig ontwikkelen dat het in ieder geval 100% compatible is tussen de Windows-versie en de linux-versie.

SDL dus. http://www.libsdl.org/

OpenGL 2.0 is trouwens al een goede stap in de richting van wat D3D op Windows doet. En denk niet dat ontwikkelen voor D3D nou zo'n feest is en overal werkt, want tussen elke major versie verandert de feature-set en API enorm, waardoor veel games tegenwoordig 2 render engines moeten aanbieden. Bijvoorbeeld 1tje op <DX9 voor machines zonder pixel shader 3.0 en eentje op DX9 voor de top-end grafische kaarten... En dan heb ik het nog niet eens over de 'semi-major' updates van sommige DX versies, omdat de eerste versie te veel fouten bevatte (DirectX5.0, 5.0a, 5.0b/DirectX9, 9b anyone?).

Komt nog bij dat vanaf DX10 Windows XP niet eens meer gesupport wordt, en er verder geen enkel OS is dat een DirectX implementatie heeft.

[Verwijderd]

Ik programmeer zelf regelmatig met SDL maar kan je vertellen dat het echt lang niet op het niveau zit van Direct-X.

Support is niet aanwezig, documentatie is een ramp en qua werking is het ook niet vergelijkbaar met Direct-X.

[ppl]

Ik vind dat nogal opmerkelijk dat de game industrie voor DirectX kiest terwijl ieder andere fabrikant op gebied van CAD en 3D modelling of wat dan ook voor OpenGL gaat. Ik denk dat het dan ook eerder ligt aan de keuze die ze ooit eens hebben gemaakt waardoor ze er nu aan vast zitten en het ontzettend veel tijd, moeite en dus ook geld kost om te switchen. Economisch niet verantwoord zullen ze wel denken.

EDIT: even ter verduidelijking heb ik het hier dus ook over pakketten als Maya die je dus prima op 1 client kunt draaien en niet alleen over die grote renderfarms waarbij het voornamelijk op rekencapaciteit aan komt (en dat heeft meer met cpu/mem te maken).

[SuperDre]

mwah ik denk dat het bij CAD en 3dmodelling toch wel wat anders ligt, daar heb je niet al die extraatjes nodig die bij games wel nodig zijn...

[Verwijderd]

Renderfarms werken meestal met gespecialiseerde software-renderers, zoals bv Renderman van Pixar.

3d hardware wordt pas sinds kort een beetje gebruikt voor offline rendering, met bv nVidia's Gelato. Maar volgens mij is dat nog niet in gebruik voor productie.

CAD is verder totaal anders dan games.
CAD heeft vaak hoog detail en weinig of geen shading, vaak zelfs wireframe.
Verder worden de meshes dynamisch gegenereerd, en zijn vaak niet geoptimaliseerd voor rendering.
Games zijn lowpoly, veel shading, en geoptimaliseerd voor rendering.
Dus compleet andere situtaties met compleet andere eisen aan de API en hardware. Daarom zitten er ook andere drivers bij een professionele kaart als een FireGL of een Quadro.
Deze drivers zijn efficienter met dingen als wireframe en high-poly modellen, maar zijn vaak in games niet zo efficient.

[Terracotta]

Welke extratjes heb je nodig bij games die je bij 3D renderfarms en graphics specialisten niet kan gebruiken?

[Verwijderd]

En daarmee word dan toch de stap gezet om het gamedevelopers weer moeilijk te maken ? Ze werken vaak al met beperkte budgetten, laat staan als ze nu ook nog eens met Linux rekening moeten houden.

De stap die Intel maakt vind ik vreemd. Ze kunnen toch ook zelf Linux drivers bakken, nee, ze laten het liever aan de community over, scheelt ze weer geld. Verder willen ze hiermee gewoon meer desktops dus laten runnen onder Linux, omdat ze een gpu'tje hebben die vaak al op de mobo's word meegeplakt. Ze willen dus el cheapo op de eerste rang zitten voor niet windows systemen. Als ze het al willen laten slagen lever dan zelf Linux drivers.

Voor gamers verder niet interessant, die gebruiken geen Intel gpu's en voor barebone's lijkt me ook niet, aangezien een laptop steeds meer een beter alternatief is + goedkoper als multi media apparaat voor muziek of content op de tv.

[killercow]

Uhm,

Wat loop je nou te ranten man,

Intel heeft deze drivers toch gemaakt en beschikbaar gesteld?

Ik ben geen intel fan, maar dit is toch echt wel geweldig.
Ze steken er geld in, en geven daarna de community ook nog eens voldoende kans om mee te werken.

Das een stuk meer dan je van bijvoorbeeld matrox kan zeggen (die nemen niet eens de moeite om een knappe driver te releasen), terweil dat op windows juist hun verkoop punt is.

[FrankNStein]

Zoals Killercow al zegt: Ze hebben al drivers, en die maken ze opensource.

Dat heeft 2 voordelen:
a) Linux-'hackers' kunnen de code verbeteren.
b) Distro's kunnen de code/ binairies meeleveren, en meeinstalleren. Dit komt omdat de GPL het gebruik van closed-source-kernel-modules verbied. Dat is de reden dat vrijwel alle distro's geen fatsoendelijke drivers meeleveren, omdat het gewoon niet legaal is.
(Gebruikers kunnen het wel zelf nog altijd zelf installeren. zie de duizenden how-to's. De meegeleverde drivers zijn vaak de opensource mesa-drivers. RedHat levert wel nog gesloten kernelmodules mee. Novell heeft aangekondigt het in zijn komende versies niet meer te doen.)

Verder, niet vergeten dat bijna alle kernel-devs, en x-org devs het helemaal niet erg vinden om hun eigen drivers te schrijven. Daarvoor zijn ze immers kernel/x-org-devs geworden.

[CAPSLOCK2000]

Ik snap niet waarom game developers het moeilijk krijgt. Niemand verplicht ze om iets met Linux te doen. Zelfs als een gamedeveloper wel voor Linux programmeert zal hij hier geen enkele last van hebben. Het is een driver, daar heeft de gemiddelde programmeur niks mee te maken.

Dat Intel z'n drivers zelf heeft geschreven hebben andere al gemeld.

Zoals je zegt gebruiken die-hard gamers meestal geen Intel chips. Maar er zijn een hele hoop mensen die af en toe wel eens een spelletje willen spelen, zonder die-hard gamer te zijn. Ik denk dat dat er zelfs meer zijn als fanatieke gamers. Dat soort mensen willen geen 300E uitgeven aan een graka. Die mensen hoeven nu geen losse grafische kaart meer te kopen, maar kunnen toe met zo'n intel dingetje.

[merethan]

terwijl ATi en nVidia de broncode van hun grafische drivers met geheimzinnigheid omhullen en zelfs de simpelste pogingen om een open driver te publiceren dwarsbomen, heeft Intel in de open broncode ondersteuning voor onder andere de vertex-, geometry- en fragmentshaders van de 965 verwerkt, waarmee de driver als zeer compleet mag worden betiteld.

Sommige mensen...

[CAPSLOCK2000]

Vanuit het oogpunt van de grote computer verkopers (Dell en HP enzo) is dit ook prachtig nieuws. Die grote jongens lopen altijd als eerste tegen driver problemen aan, gewoon omdat ze zo groot zijn.

Als bv. Dell een klacht van een klant krijgt, moeten zij gaan uitzoeken wat er mis is. Na tijd puzzelen ontstaat het vermoeden dat het een driver probleem is. Dan moeten ze Intel bellen, (die eerst ontkennen dat het een driver probleem is) en dan doet Intel zijn eigen onderzoek. Dan komt Intel er achter dat het eigenlijk een DirectX probleem is, en dat Dell dus maar met MS moet bellen, etc. etc. etc.....

Al die tijd zit de klant op Dell te wachten. De klant zal het geen bal schelen waar de fout zit, als het maar wordt opgelost. Dell zelf kan ook niet meer doen als wachten op anderen.

Bij een OpenSource systeem hoeft dat niet. Dell kan zijn eigen ingenieurs het probleem laten uitzoeken en oplossen. De klant is dan direct geholpen, en men kan daarna rustig met Intel enzo gaan bekvechten over wiens fout het is en hoe die moet worden opgelost.

Het klinkt als een dure grap voor Dell, om zelf driver problemen op te lossen, maar als ze daarmee betere garantie en service kunnen leveren als hun concurrenten, zullen een hoop bedrijven er graag voor betalen.

[thegve]

Even los van de Dell incidenten de laatste tijd zouden OEM machines geen last moeten hebben van driverproblemen, als de drivers van hun site gebruikt worden. Voordat die machines verkocht worden, worden ze eerst zo vaak getest. Zeker zoiets als een werkstationnetje oid.

[CAPSLOCK2000]

"OEM machines zouden geen last moeten hebben van driver problemen" is correct geformuleerd, het zou niet moeten gebeuren. Toch komt het best vaak voor, zeker als je een beetje afwijkende configuratie hebt.

Kijk maar eens naar de versienummers van de drivers op de Dell site ofzo, vrijwel alles heeft al meerder bugfix releasees gehad.

[cybermans]

zag op de page van intel dat een zekere keith packard in de het developmentteam zat. Had hij niet een of andere X server ook gecode?

[moto-moi]

Hij is degene geweest die XFree86 heeft geforked vlak voor hun licentieverandering en toen is begonnen met x.org, welke nu in zo'n beetje elke distro zit.

[smokalot]

klopt, hij is ook de belangrijkste auteur van de kdrive X server. Maar dat is maar een experimenteel speeltje.

[arjankoole]

Maar dat is maar een experimenteel speeltje.

waren de BSD's en Linux ook niet ooit zo begonnen? Of eigelijk, is alles niet zo begonnen?

[nero355]

Chapeau voor Intel !! Zo wordt het nog aantrekkelijker om een Core 2 Duo laptop te nemen en dan Linux erop te draaien

[killercow]

Vergeet vooral de Nieuwe mac mini niet,
Deze wordt bijna 100% ondersteund volgende de pagina van intel.

Hopelijk krijgen we weer nette distro's helemaal kant en klaar voor de mac-mini, met video driver en al, die dan net als apple een kant en klare experience kunnen leveren.

[VittunWasted]

Laten we hopen dat ATI en Nvidia volgen. Voor mijn part moeten ze hun driver niet open-sourcen. Laat ze maar allebei hun rommel houden. Beide drivers hebben zo hun stabiliteitsproblemen. Ze zouden enkel de nodige documentatie moeten vrijgeven om een driver te kunnen schrijven. De Free Software Community doet het meestal toch beter (bv. de open nv driver is veel stabieler dan die van nvidia) Maar wat Intel doet is zeker toe te juichen! Ik heb het gevoel dat mijn volgend pc'tje een intel videokaartje zal hebben.

[_JGC_]

De closed source drivers zijn zo brak omdat de opensource ontwikkelaars er niet op in kunnen spelen en de ontwikkeling van dingen als de kernel en X.Org zo snel gaan dat de closed source driverontwikkelaars gewoon niet voldoende tijd en mankracht hebben om het een en ander goed te laten functioneren.
Met een opensource videodriver weet een X.Org ontwikkelaar precies waar de knelpunten zitten op het moment dat hij iets fundamenteels verandert in de code van X of desnoods de kernel zelf.

Verder kan je wel zeggen dat de nv driver veel stabieler is dan de nvidia driver, maar dat is appels met peren vergelijken. De nv driver is maar een heel simpel drivertje die je bijna kunt vergelijken met de vesa driver. Dat ding doet enigszins versneld 2D en verder wordt die hele nvidia chip niet benut. Als je dat gaat vergelijken met een driver die alle onderdelen van een grafische chip belast met de complexiteit die daarbij komt kijken...

[bbob]

gamen gamen gamen onder linux. Ik denk dat het eerder boeined is voor andere features zoals 3d. Wil linxus echt doorbreken dan is dat zeker niet omdat je er op kan gamen.
De massa van de pc's zit nog steeds in de zakelijke markt en intel in nog steeds de grootste fabrikant van grafische chips.
Als je het vanuit die kant bekijkt kan het zeker goed zijn voor linux.

[killercow]

Dingen als XGl en zo zijn nu native te ondersteunen op een machine met deze chipset,

wat dus een streepje voor is op de vista effecten, want die hebben overall een veel zwaarder systeem nodig, of gebruiken meer resources.

XGL draait prima op mijn extra:
athlon 600,
192mb
Geforce 2 mx 32mb

[Adrianb]

Ik gebruik nu full-time Linux en de games die werken op Linux hebben me daar grotendeels naartoe gedreven.

[smokalot]

Dit is wel echt een hele belangrijke stap, hierdoor zullen de features, de snelheid, de flexibiliteit en de stabiliteit van linuxmachines sterk verbeteren!

Intel had altijd al best aardige drivers voor linux/unix, maar nu zullen nog meer mensen met een intel chipset af kunnen, ipv een nvidia/ati.

[thegve]

OEM's die servers leveren leveren nu al meestal Intel chips, omdat die ondersteuning zowieso al OK was en omdat graphics toch niet belangrijk zijn. Nu kunnen ze (voorlopig) gewoon bijna niet meer om Intel heen. AMD was voorheen erg populair onder tweakers, die ook bovengemiddeld veel doen met Linux. Deze begonnen zowieso al wat meer Intel minded te worden met de nieuwe CPU's. De grootste groeimarkten op dit moment zit in Azie en Afrika, waar Linux een grotere rol op de desktop lijkt te gaan spelen dan het in het Westen gedaan heeft, zeker met de laatste RedHat, Fedora, Ubuntu versies lijkt me dit goed mogelijk. Al met al lijkt me dat Intel dit nog redelijk wat kan gaan opleveren zolang een van de concurrenten niet besluit hetzelfde te gaan doen. En ATI schijnt problemen te hebben met technieken van derden die ze gebruiken, dus denk dat dat zo'n vaart niet loopt. Nvidia weet ik direct niet, maar mijn gevoel zegt dat ze het niet doen .

[Verwijderd]

Oeh, dit kan wel eens een harde klap worden voor AMD (ATi). Of ze moeten zo slim zijn om ook een driver te releasen die volgends GPL licentie werkt (anders kan je hem niet zo intergreren met de kernel, iig dat is niet netjes). En je kan nou 100% zeker zijn dat alle distro's ondersteund worden.

[hansg]

Bedoel je soms "harde klap voor NVidia"? Aangezien AMD/ATI juist overweegt om mee te gaan in het open sourcen van hun drivers...

Denk trouwens dat het wel los loopt met NVidia. De hardste klappen vallen ongetwijfeld bij Microsoft, die wederom een stukje vendor lock kwijt raakt.

Overigens, mijn complimenten voor Intel! Dit is een uitstekende ontwikkeling die inderdaad zeer positieve effecten op de ontwikkeling van Open Source producten zal hebben.

[Jungian]

De nvidia-driver werkt anders prima. De ati-driver heeft de performance van een paard met 2 rubberen benen, dus daar zou open source een goede uitkomst voor zijn.

[Terracotta]

Inderdaad, de drivers installeren is nog ni half zo moeilijk als het lijkt, maar als het met ATI out of the box werkt dan kunnen ze wel wat verliezen, maar het zal niet zo veel zijn denk ik, alhoewel, linux gebruikers zijn zo af en toe nogal gehecht aan de gpl

[VNA9216]

ik las vanmorgen toevallig dit: http://www.infoworld.com/article/06/08/02/32OPcurve_1.html

daarin staat onderaan dat AMD het ook overweegt

[SuperDre]

dit is dus echt geen harde klap, die interne graphics procs van Intel presteren bij lange na niet zo goed als die van ATI of Nvidia, een echte 3d user zal ook zoals het artikel al aangeeft helemaal niet eens dat ding in hun computer hebben zitten..

[TheOneLLama]

Maar wel de user die straks bv. GLX wil gebruiken, voor wat mooie effecten op je desktop (zoals MacOS X en Vista). Dat kun nu zonder allemaal belachelijke installatie perikelen zoals bij ATi and nVidia.

Voor een niet al te dure laptop zat je toch vaak vast aan of Ati integrated graphics (of een X300 ed, die geen eigen graphics memory hebben), of die van Intel. In dit geval heeft Intel dan duidelijk een streepje voor, ondanks dat de Ati chip vaak theoretisch sneller is.

[synthesix]

Had dit eigenlijk eerder verwacht van amd.
Om de meer hardcore kant van de computergebruikers te steunen.

[killercow]

Er zijn genoeg geruchten dat amd ook over de ati drivers nadenkt.

Opensource ati drivers zou namenlijk best wel een boel positieve invloed voor ati/amd onder linux betekenen.

[leuk_he]

intel geeft hiermee uiteraard meteen een flinke plaagstoot aan ATI-AMD. Je kun de intel 965 alleen gebruiken op een intel chipset die alleen intel cpu's ondersteund.

Ik denk ook niet dat je losse video kaarten kunt kopen met een I965g chipset.

[Stevendefeij]

WTF bedoel je nu eigenlijk dat je de intel drivers alleen kan gebruiken als je een moederboard met een intel chipset hebt???

Eh ja duh dat heet een driver ati drivers werken toch ook niet op een Nvidia kaart?
Of bedoel je dat AMD processor niet op intel chipsets werken???? Joh ga jij toch lekker een socket 7 moederboard kopen kan je lekker een AMD k5,k6, pentium mmx, cyrix 5x86 of 6x86 nogwat, winbond of rise processor gebruiken.
Sorry maar dit slaat echt nergens op.

Effe wat anders goede actie van intel drivers te opensources, en nu maar hopen dat AMD/ATI volgt en wie weet gaat Nvidia over een x aantal tijd ook overstag.

Dat zou toch mooi zijn OpenGL wordt wel verbeterd met tijd en DirectX is funest voor transgaming dus Go opensource go OpenGL.

[voodooless]

AMD denk hier ook sterk over na: http://www.infoworld.com/article/06/08/02/32OPcurve_1.html