Opensourcedriver voor ARM's Mali-gpu in ontwikkeling
Een opensource-project heeft als doel om via reverse engineering tot een grafische driver voor Mali-gpu's van ARM-chips te komen. Het project zal in februari op een bijeenkomst voor ontwikkelaars in België officieel onthuld worden.
Drivers die volledig opensource zijn voor de gpu's die gecombineerd worden met ARM-chips zijn er nog niet, maar mogelijk gaat hier verandering in komen. Het bedrijf CodeThink en met name de Belg Luc Verhaegen blijken namelijk de drijvende kracht achter een project voor het reverse engineeren van de grafische driver voor de Mali-gpu. Verhaegen is X.org-ontwikkelaar en voormalig developer van Suse.
Het project richt zich op de Mali-400 met ondersteuning voor OpenGL 2.0 en de Mali-200 met OpenGL ES 1.1/2.0- en OpenVG 1.1-ondersteuning. CodeThink hoopt dat het bedrijf ARM zelf betrokken zal raken bij het project. Er moet nog veel gebeuren voor het eerste resultaat vrijgegeven kan worden, maar volgens Phoronix is het project nu al verder dan de poging van de Free Software Foundation om de PowerVR-driver te reverse engineeren. Op de FOSDEM-bijeenkomst die begin februari in Brussel plaatsvindt maakt Verhaegen meer bekend over het project.
Reacties (40)
Drivers zouden eigenlijk vanzelfsprekend opensource moeten zijn!
Wat een geklooi toch altijd...
Het nut van closedsource ontgaat me volledig aangezien deze bij populaire hardware zo goed als altijd gereverse-engineerd worden.
Dit vraagt echter tijd, waardoor een deel potentiële gebruikers niet in staat is die hardware (deftig) te gebruiken.
Wat een geklooi toch altijd...
Het nut van closedsource ontgaat me volledig aangezien deze bij populaire hardware zo goed als altijd gereverse-engineerd worden.
Dit vraagt echter tijd, waardoor een deel potentiële gebruikers niet in staat is die hardware (deftig) te gebruiken.
Drivers zijn ook gewoon software en delen van de drivers vallen dan ook vaak onder meerdere softwarepatenten, daardoor is het vaak onmogelijk om de drivers open-source te maken, zelfs als de fabrikant dat wil.
De wetgeving is zo rot als een Mandje..
Als ze in Europa iets kunnen Rechtzetten is het wel dat elk Hardware Product verplicht Opensource moet aan te sturen zijn, of daar een SDK met goede documentatie voor bieden.
Als ze in Europa iets kunnen Rechtzetten is het wel dat elk Hardware Product verplicht Opensource moet aan te sturen zijn, of daar een SDK met goede documentatie voor bieden.
Ja, want in het kader van Open Source, ook wel vrije software, is het natuurlijk heel normaal om bedrijven vrijheden te ontnemen...
je bedoeld de vrijheid om je klanten op te lichten met goede hardware en rommel software. voor hoeveel apparaten neem bijv routertjes wordt hier op tweakers net niet gepredict om de een of andere custom firmware te installeren omdat die beter werken dan de orriginele.
en dan nog software pattenten die waren hier toch helemaal niet geldig, nu kan ik me nog voorstellen dat je bepaalde software verbeter truukjes niet kunt vrijgeven maar gewoon een deftge specificatie hoe de chip werkt, welke instructies ze kent zou in de EU best verplicht mogen worden, drivers bouwen is ECHT het probleem niet, aan de nodige informatie komen is veel lastiger.
en dan nog software pattenten die waren hier toch helemaal niet geldig, nu kan ik me nog voorstellen dat je bepaalde software verbeter truukjes niet kunt vrijgeven maar gewoon een deftge specificatie hoe de chip werkt, welke instructies ze kent zou in de EU best verplicht mogen worden, drivers bouwen is ECHT het probleem niet, aan de nodige informatie komen is veel lastiger.
Voor een goed gedocumenteerde API heb je geen open source nodig.
De mogelijkheid om het aan te sturen is er nu toch al, in de vorm van propriety drivers.
De source open maken, wil zeggen dat je ook een hoop technologie publiceert en dat kun je weer niet verplicht stellen lijkt me.
Dit is dan weer een mooi project, dat binnen de wet een mooie oplossing zal gaan bieden. Ik hoop dat het wat betreft performance ook mee gaat vallen, want daar zit vaak wel een addertje onder het gras bij dit soort projecten. Ik heb voor videokaarten al vaker opensource drivers geprobeerd, maar over het algemeen halen die het niet bij de propriety drivers, juist vanwege het ontbreken van die gepatenteerde technologie.
Maargoed, dit zijn wel aardige zwaargewichten in de opensource wereld, dus ik ben zeker benieuwd.
De source open maken, wil zeggen dat je ook een hoop technologie publiceert en dat kun je weer niet verplicht stellen lijkt me.
Dit is dan weer een mooi project, dat binnen de wet een mooie oplossing zal gaan bieden. Ik hoop dat het wat betreft performance ook mee gaat vallen, want daar zit vaak wel een addertje onder het gras bij dit soort projecten. Ik heb voor videokaarten al vaker opensource drivers geprobeerd, maar over het algemeen halen die het niet bij de propriety drivers, juist vanwege het ontbreken van die gepatenteerde technologie.
Maargoed, dit zijn wel aardige zwaargewichten in de opensource wereld, dus ik ben zeker benieuwd.
Das waar, veelal zijn de drivers niet intern geschreven en krijgen de externen gewoon een deel van de verkoop-koek. Maar toch, hier zouden andere regels toch zeer welkom zijn.
De fabrikant wil hardware verkopen, en zo veel mogelijk, het uitsluiten van een steeds grotere groep mensen, in de meeste gevallen weten deze mensen veel beter met wat ze bezig zijn, kan toch geen goede verkoopstrategie zijn? Maar goed, ik denk dat we nog wat zullen moeten groeien om volledig aanvaard te worden. Apple had om en bij de 5% van de markt nodig, daar zitten we nog niet.
De fabrikant wil hardware verkopen, en zo veel mogelijk, het uitsluiten van een steeds grotere groep mensen, in de meeste gevallen weten deze mensen veel beter met wat ze bezig zijn, kan toch geen goede verkoopstrategie zijn? Maar goed, ik denk dat we nog wat zullen moeten groeien om volledig aanvaard te worden. Apple had om en bij de 5% van de markt nodig, daar zitten we nog niet.
[Reactie gewijzigd door eclipse____ op zondag 22 januari 2012 12:45]
Het zou voor de eindgebruiker fijn zijn dat alle drivers open-source zouden worden, maar dat is niet genoeg. Een open-source licentie maakt het porteren naar Linux een stuk eenvoudiger, maar dat wil niet zeggen dat het in de Linux kernel kan worden opgenomen.
Kijk bijvoorbeeld eens naar ZFS van Sun. Dat is een geweldig filesysteem, maar ondanks dat het open-source is kan het niet worden opgenomen in Linux vanwege de CDDL licentie. Linux is nu bezig met een alternatief (btrfs), maar dat duurt nog jaren voordat het op het niveau van ZFS zit.
Je bent als bedrijf eigenlijk wel gek om iets onder GPLv3 uit te brengen i.v.m. de onmogelijkheid om nog een patent te kunnen gebruiken. Daarmee zet je de deur voor je concurrenten meteen wagenwijd open. Natuurlijk kun je ervoor kiezen een andere licentie te gebruiken, maar dan wordt adoptie in Linux toch wel wat lastig.
Kijk bijvoorbeeld eens naar ZFS van Sun. Dat is een geweldig filesysteem, maar ondanks dat het open-source is kan het niet worden opgenomen in Linux vanwege de CDDL licentie. Linux is nu bezig met een alternatief (btrfs), maar dat duurt nog jaren voordat het op het niveau van ZFS zit.
Je bent als bedrijf eigenlijk wel gek om iets onder GPLv3 uit te brengen i.v.m. de onmogelijkheid om nog een patent te kunnen gebruiken. Daarmee zet je de deur voor je concurrenten meteen wagenwijd open. Natuurlijk kun je ervoor kiezen een andere licentie te gebruiken, maar dan wordt adoptie in Linux toch wel wat lastig.
Voor de eindgebruiker boeit het geen meter, die zal het worst wezen onder welke licensie de gfx driver van bv zijn Android telefoon is uitgegeven. Het is vooral handig voor developers die geen licensie kunnen/willen betalen, en concurrenten die graag eens willen zien hoe het allemaal werkt bij de buren.Het zou voor de eindgebruiker fijn zijn dat alle drivers open-source zouden worden
[Reactie gewijzigd door Dreamvoid op zondag 22 januari 2012 13:24]
Het is in zoverre fijn voor de eindgebruiker dat hij een grotere kans heeft dat zijn hardware ook op andere platformen wordt ondersteund.
en dat security issues sneller worden gevonden en gefixed. En dat zijn hardware langer wordt ondersteund. En dat extra features beschikbaar komen. En dat de fabrikant geen anti-features in kan bouwen. Plenty reden om FOSS drivers voor hardware (die je tenslotte KOOPT) verplicht te stellen. Goed voor de consument, markt en economie. Slecht voor de grootste spelers op de markt maar verder profiteert iedereen... Jammer dat niet die grootste spelers het meestal voor het zeggen hebben (lobby money, dineetjes en reisjes voor politici etc).
WIl niet al te beide hand zijn, maar ik gebruik tegenwoordig zfs onder ubuntu en niet via fuse. Je kan en mag ZFS wel als module gebruiken.
Het mag alleen niet opgenomen worden in de Linux kernel. Ik ken het ZFS on Linux project, maar dat valt niet onder het kernel project. Daarmee is ondersteuning dus niet gegarandeerd. Ook zit het nog in de ontwikkelfase, waardoor het voor experimenteel gebruik wellicht gebruikt kan worden, maar je gaat er geen productie mee draaien (hoop ik).
Als ik de mailinglist mag geloven zijn er voldoende mensen die het in een productie omgeving gebruiken en met succes.
Het is idd een module en zal niet snel in de kernel opgenomen worden, maar maakt dat wat uit? Volgens mij is dit juist 1 van de voordelen van linux, je kan er zelf modules bij plaatsen.
Het is idd een module en zal niet snel in de kernel opgenomen worden, maar maakt dat wat uit? Volgens mij is dit juist 1 van de voordelen van linux, je kan er zelf modules bij plaatsen.
Er zijn 2 redenen om iets te patenteren:Je bent als bedrijf eigenlijk wel gek om iets onder GPLv3 uit te brengen i.v.m. de onmogelijkheid om nog een patent te kunnen gebruiken. Daarmee zet je de deur voor je concurrenten meteen wagenwijd open. Natuurlijk kun je ervoor kiezen een andere licentie te gebruiken, maar dan wordt adoptie in Linux toch wel wat lastig.
- geld voor licenties vangen
- zorgen dat de concurrentie jou niet kan dwarsbomen door te zorgen dat jij zelf licentiegeld moet gaan betalen.
Ik durf wel te stellen dat beide redenen elkaar eigenlijk uitsluiten. Oftewel het is het een of het ander. Vaak worden patenten namelijk als ruilmiddel ingezet zodat bedrijven elkaars patenten vrij kunnen gebruiken.
Bij die 2e reden moet je dus best wel veel kosten maken om je ontwikkeling veilig te stellen.
Je moet namelijk een patent aanvragen in verschillende delen van de wereld en je hebt redelijk wat juridische kosten om het patent veilig te stellen danwel te handhaven.
Als je een groot bedrijf bent zoals IBM/Philips/enz. dan is dat niet zo'n probleem, maar voor kleine bedrijven kan het handig zijn om de boel algemeen beschikbaar te maken en zodoende te voorkomen dat anderen het niet kunnen patenteren. (al is dat met de laatste wijzigingen aan het patent-systeem in de VS een beetje onderuit gehaald)
Onder GPL uitbrengen heeft nog een nadeel wat het voor de concurrentie lastiger maakt.
Je moet namelijk de delen die je gebruikt die onder GPL vallen zelf ook vrij geven en nog belangrijker aanpasbaar maken. Oftewel je moet je eigen software modulair op gaan zetten zodat in theorie iemand het GPL deel zou kunnen aanpassen en kunnen koppelen aan jouw applicatie.
Dat maakt het voor de concurrentie wat vervelender, wat in wezen ook je doel is.
De delen van de video drivers die in de kernel moeten zitten voor de video driver zitten al in de kernel en zijn al vrijgegeven onder GPLv2. Dit was een eis van Google voor Android omdat de kernel GPLV2 is en eist dat zaken die in de kernel zitten ook GPLv2 zijn.Het zou voor de eindgebruiker fijn zijn dat alle drivers open-source zouden worden, maar dat is niet genoeg. Een open-source licentie maakt het porteren naar Linux een stuk eenvoudiger, maar dat wil niet zeggen dat het in de Linux kernel kan worden opgenomen.
De Linux kernel onder GPLv2 vrijgegeven.Je bent als bedrijf eigenlijk wel gek om iets onder GPLv3 uit te brengen i.v.m. de onmogelijkheid om nog een patent te kunnen gebruiken. Daarmee zet je de deur voor je concurrenten meteen wagenwijd open. Natuurlijk kun je ervoor kiezen een andere licentie te gebruiken, maar dan wordt adoptie in Linux toch wel wat lastig.
De patenten van GPU fabrikanten rusten in de meeste gevallen op de hardware niet de software. Als de drivers vrijgeeft als OSS dan heeft dit geen enkel (nadelig) effect op de hardware patenten.
Daarom heeft Intel er geen moeite mee om deze OSS driver voor hum GPUs te maken en AMD om de documentatie vrij te geven waardoor de OSS community zelf de drivers kan schrijven.
aan de andere kant, waarom patenten als je ook gewoon innovatiever en beter kunt zijn dan je concurenten, ... bovendien beschermt de gpl3 jouw ook tegen patent claims van anderen, bovendien kun je ook WEL patenteren en een gratis licentie verstrekken aan iedereen die zich aan de gpl3 houd en geen licentie aan mensen die dat niet doen ...
ook gpl3 bied nog mogelijkheden voor dual-licenties en anders neem je toch de apgl of de lgpl ?? of een andere gpl-compatible licentie.
ook gpl3 bied nog mogelijkheden voor dual-licenties en anders neem je toch de apgl of de lgpl ?? of een andere gpl-compatible licentie.
Een correct werkende Open Source Linux driver, zorgt er met het huidige gebruik van deze driver in de Linux kernel voor dat de hardware tot in lengte van jaren bruikbaar blijft. In hoeverre is dat in het belang van een Hardware Vendor?
Niet natuurlijk, want die wil telkens nieuwe hardware uitbrengen die weer verkocht kan worden met daarop de nieuwste software, in plaats van dat consumenten wat langer met hun oude apparatuur kunnen doen, omdat de software er wel voor volgt.
Zo lang dit de mindset is van Hardware Vendors, zullen open source drivers altijd een stap of twee achter de feiten aan blijven lopen wanneer deze niet de volledige steun van de hardware vendors krijgen. Ik zou niet weten wat voor deze vendors de meerwaarde zou zijn voor het open sourcen van hun drivers. Wie het weet mag het zeggen.
@hieronder: Wat ik bedoel te zeggen is dat je nieuwe hardware (laten we zeggen telefoon) moet kopen omdat de nieuwe software (laten we zeggen Android versie met nieuwe kernel) niet meer draait omdat er geen drivers voor allerhande hardware in je phone voorhanden is. Op zo'n moment zouden correct werkende OS drivers je uit de brand helpen en zolang hardware vendors hier niet aan mee werken blijft dat een utopie.
De belangrijkste reden lijkt me overigens dat de hardware vendors hun concurrenten geen kijkje in hun keuken willen geven met het vrijgeven van de source van hun drivers. Dat zou een eventuele voorsprong snel teniet doen.
Niet natuurlijk, want die wil telkens nieuwe hardware uitbrengen die weer verkocht kan worden met daarop de nieuwste software, in plaats van dat consumenten wat langer met hun oude apparatuur kunnen doen, omdat de software er wel voor volgt.
Zo lang dit de mindset is van Hardware Vendors, zullen open source drivers altijd een stap of twee achter de feiten aan blijven lopen wanneer deze niet de volledige steun van de hardware vendors krijgen. Ik zou niet weten wat voor deze vendors de meerwaarde zou zijn voor het open sourcen van hun drivers. Wie het weet mag het zeggen.
@hieronder: Wat ik bedoel te zeggen is dat je nieuwe hardware (laten we zeggen telefoon) moet kopen omdat de nieuwe software (laten we zeggen Android versie met nieuwe kernel) niet meer draait omdat er geen drivers voor allerhande hardware in je phone voorhanden is. Op zo'n moment zouden correct werkende OS drivers je uit de brand helpen en zolang hardware vendors hier niet aan mee werken blijft dat een utopie.
De belangrijkste reden lijkt me overigens dat de hardware vendors hun concurrenten geen kijkje in hun keuken willen geven met het vrijgeven van de source van hun drivers. Dat zou een eventuele voorsprong snel teniet doen.
[Reactie gewijzigd door bas-r op zondag 22 januari 2012 19:33]
Ik hou altijd wel van een goede conspiracy theorie, maar het aantal mensen dat een nieuwe gfx kaart 'moet' kopen omdat de driver support slechter (?) wordt is denk ik compleet verwaarloosbaar tov de mensen die de oude gewoon te traag vinden.
Ze hebben er juist voordeel van lijkt me, positieve publiciteit en er zullen zeker meer mensen zijn die je hardware overwegen, meeste OSS driver projecten onstaan door slechte closed source drivers overigens.
Als het onder patenten valt is er geen vuiltje aan de lucht om het openbaar te maken, want bij een patent moet je beschrijven hoe het werkt.Drivers zijn ook gewoon software en delen van de drivers vallen dan ook vaak onder meerdere softwarepatenten, daardoor is het vaak onmogelijk om de drivers open-source te maken, zelfs als de fabrikant dat wil.
Enige wat een probleem zou kunnen geven is de betaling van licenties.
Maar dat laat ook weer meteen zien waarom software-patenten geen goed idee zijn.
Het is echter wel een probleem om zaken opensource te maken wanneer de documentatie van de chip-fabrikant onder NDA vallen. (Non-disclosure Agreement)
Er zijn heel veel fabrikanten die gedetailleerde informatie in elk geval voor een bepaalde tijd onder NDA laten vallen. Puur om te voorkomen dat concurrentie de ideeën steelt.
Echter is dat ook steeds minder een issue en zou je software-concepten veel beter onder een NDA kunnen laten vallen dan specificatie van aansturing van hardware.
Een concept implementeren kost tijd en als dat pas bekend is wanneer het in de winkel ligt heb je een behoorlijk voordeel. Echter hardware implementatie is door kenners op dat gebied vaak niet zo lastig zelf te bedenken.
En persoonlijk ben ik van mening dat de keuze tussen 2 chips heel snel uit zal komen op de chip die het meest ondersteund wordt (en het meest simpel aan te sturen is). De prijs speelt dat al iets minder mee, omdat grootschalige ondersteuning ook het veiligstellen is van ontwikkeltijd en meer garanties biedt op langjarige levergaranties van dezelfde chip of in elk geval een compatible chip.
Kortom, software patenten zijn niet het probleem (op licenties na) en NDA's op hardware wat in de winkel te krijgen is is een achterhaald concept.
Mee eens, maar... Inmiddels is het al lang niet meer zo dat hardware door één bedrijf wordt ontwikkeld. Zelfs de groten (ATi, nVidia) zullen voor delen van hun chip andermans werk in licentie nemen. Zaken als encrypted HDMI output ondersteuning moet worden gelicenseerd, maar ook instructiesets voor ondersteunende taken (video decoding, power management, ik noem maar wat). Intel is hier hard de mist mee in gegaan met zijn Poulsbo hardware. Het resultaat is dat de driver niet open-source kan worden gemaakt omdat ze daarmee het IP van andere bedrijven schenden. Reverse-engineerers trekken zich hier natuurlijk weinig van aan. 
[Reactie gewijzigd door RSpliet op zondag 22 januari 2012 11:55]
Bovendien, opensource drivers klinkt leuk maar of het nou werkelijk zo aanlokkelijk is voor een fabrikant? Android is veruit de meest succesvolle Linux distro ooit en gebruikt volop closed source drivers (ook die PowerVR dingen die Intel heeft), geen enkele OEM klaagt daarover. nVidia heeft een closed source driver (+ compleet eigen windowing subsystem) en is stukken beter dan wat de open source community in elkaar heeft geknutseld voor Intel en AMD graphics. Als nVidia hun source vrijgeeft is het eerste wat de community gaat doen de code in de AMD/Intel drivers hergebruiken, en dat is wel het laatste waar nVidia op zit te wachten. Voor nVidia is het allemaal geen idealisme of hobbyisme, ze verkopen voor bijna $1 miljard per jaar aan gpu's voor grafische workstations, een markt die harde $$$ betaalt voor goede OpenGL performance - en dat is naast Windows en Solaris ook Linux-based hardware. Voor ARM en PowerVR geldt hetzelfde, hun gpu technologie laat de schoorsteen roken, en om dat dan allemaal maar openbaar te maken...
Het lijkt erop dat dit project eerder vanuit ideologie wordt opgezet, dan vanuit noodzaak.
Het lijkt erop dat dit project eerder vanuit ideologie wordt opgezet, dan vanuit noodzaak.
[Reactie gewijzigd door Dreamvoid op zondag 22 januari 2012 13:07]
Inderdaad. In de praktijk zie je dat makers van SoCs drivers in binaire vorm meeleveren voor gebruik met hun chips. Je hebt helemaal geen open source drivers nodig.
Waar kan ik dan de hardfp driver vinden voor Xorg 7.6 voor bijvoorbeeld een OMAP4, Tegra2/3, etc?Inderdaad. In de praktijk zie je dat makers van SoCs drivers in binaire vorm meeleveren voor gebruik met hun chips. Je hebt helemaal geen open source drivers nodig.
IMO zie je het te rooskleurig in.
Natuurlijk klaagt hier geen enkele OEM over ze krijgen al deze zaken van Google.Android is veruit de meest succesvolle Linux distro ooit en gebruikt volop closed source drivers (ook die PowerVR dingen die Intel heeft), geen enkele OEM klaagt daarover.
Het gaat helemaal niet om fabrikanten maar om de distro's. Voor de distro waar ik momenteel aan meewerk on deze naar ARM te porten is momenteel nog geen enkele 3D driver voor SGX, Mali, ULP GeForce etc. Vooral omdat openSUSE hardfp gebruikt i.p.v. softfp.Bovendien, opensource drivers klinkt leuk maar of het nou werkelijk zo aanlokkelijk is voor een fabrikant?
De Intel OSS drivers zijn door Intel ontwikkeld, ze werken prima.is stukken beter dan wat de open source community in elkaar heeft geknutseld voor Intel en AMD graphics.
Zoals ik al zeg distro's hebben deze drivers nodig.Het lijkt erop dat dit project eerder vanuit ideologie wordt opgezet, dan vanuit noodzaak.
Hopelijk komt er ook een opensource Tegra GeForce driver zoals deze ook bestaat voor de GForce GPU's in de vorm van nouveau.
Dat je niet ziet waarom is waarschijnlijk omdat je er minder dan voldoende van weet om hier een uitspraak over te doen. In een driver voor een gpu zit enorm veel kennis gepropt. Het bevat algoritmes welke miljoenen aan research hebben gekost en je concurrent ga je die miljoenen echt niet in de schoot werpen. Daarnaast is het ook nog een veel werk om het te implementeren waarvoor je personeelskosten hebt betaald. Tenslotte onthult een driver veel over de hardware waarvoor het geschreven is. De waarde hiervan is moeilijk te berekenen maar met enkele miljoenen kom je hier zeker niet toe. Het nut van de concurrentie veel wind uit de zeilen te halen zal waarschijnlijk niemand ontgaan.
Verder kan ik getuigen dat de gereverse engineerde oplossingen hier enkele jaren achterlopen op de closed source oplossingen. En dat is de termijn wat nodig is voor de producent om zijn investering ten gelde te maken. De opensource drivers waaraan de fabrikanten zelf meewerken laten ze dan ook bewust achterlopen en de gevoelige waardevolle IP zal slechts langzaam worden vrijgegeven.
Daarnaast vind ik het wel apart dat dit in Belgie gelanceerd word. In Belgie was immers een afdeling van ARM aan het werk welke oa aan de mali heeft gewerkt. Deze afdeling is al een tijd gesloten maar ik veronderstel niet dat de ex-werknemers hun kennis mogen inzetten voor een opensource project.
Verder kan ik getuigen dat de gereverse engineerde oplossingen hier enkele jaren achterlopen op de closed source oplossingen. En dat is de termijn wat nodig is voor de producent om zijn investering ten gelde te maken. De opensource drivers waaraan de fabrikanten zelf meewerken laten ze dan ook bewust achterlopen en de gevoelige waardevolle IP zal slechts langzaam worden vrijgegeven.
Daarnaast vind ik het wel apart dat dit in Belgie gelanceerd word. In Belgie was immers een afdeling van ARM aan het werk welke oa aan de mali heeft gewerkt. Deze afdeling is al een tijd gesloten maar ik veronderstel niet dat de ex-werknemers hun kennis mogen inzetten voor een opensource project.
...Als je alles opensource zet zie je ook direct wie een stukje code van jou gebruikt.
Vergeet niet dat opensource niet gelijk staat aan vrije software!
Dat is echt een wereld van verschil.
Vergeet niet dat opensource niet gelijk staat aan vrije software!
Dat is echt een wereld van verschil.
Oh nee en hoe dan niet? Iedereen mag het gebruiken, distribueren, aanpassen, .. en dit alles zonder één cent te hoeven betalen dus hoeveel vrijer moet het nog worden dan?Vergeet niet dat opensource niet gelijk staat aan vrije software!
Open Source *is* Free Software
Dat hangt er vanaf hoe je "open source" definieert. Vroeger was open source precies dat: de source was openbaar gemaakt, ook als niemand er iets mee mocht doen. In de 'nieuwe' definitie van OSI (gebaseerd op de Debian Free Software Guidelines) is het idd gelijk geworden aan free software.
[Reactie gewijzigd door Dreamvoid op zondag 22 januari 2012 20:43]
Imagination Technologies beweerde nog niet lang geleden dat het probleem voor ARM om door te breken met de MALI gpu's zou zijn dat ze nog geen deftige driver stack hebben. Het is dus juist ARM die kan profiteren van open in de kernel gebakken drivers omdat ze al een achterstand hebben. Nu blijkt ook nog dat de huidige drivers vrij puur zijn en eenvoudig om te reverse-engineeren. Met een beetje hoop komt dit best nog goed hoor.
Trouwens, waarom is het voor alle andere randapparatuur geen probleem als de drivers open zijn, maar voor GPU's wel? Ook voor wifi-chips werden argumenten aangehaald van uw eigen technologie niet uit handen geven, dit terwijl de graphics drivers situatie nu een heel pak beter is sinds ze praktisch allemaal open source zijn. Dat niet alle code zomaar vrijgegeven kan worden omdat ze die niet zelf geschreven hebben snap ik, maar een bedrijf als AMD doet best wel moeite om open drivers te voorzien, en bij deze ziet men gelijdelijk aan toch een inhaalbeweging komen. Voornamelijk bij de low-end is dit al zichtbaar.
Trouwens, waarom is het voor alle andere randapparatuur geen probleem als de drivers open zijn, maar voor GPU's wel? Ook voor wifi-chips werden argumenten aangehaald van uw eigen technologie niet uit handen geven, dit terwijl de graphics drivers situatie nu een heel pak beter is sinds ze praktisch allemaal open source zijn. Dat niet alle code zomaar vrijgegeven kan worden omdat ze die niet zelf geschreven hebben snap ik, maar een bedrijf als AMD doet best wel moeite om open drivers te voorzien, en bij deze ziet men gelijdelijk aan toch een inhaalbeweging komen. Voornamelijk bij de low-end is dit al zichtbaar.
Reverse engineering op deze manier lijkt me verboden omdat men hier probeert een kloon van de software te maken. Overigens is wat dat betreft software tamelijk uniek. Alles wat je koopt mag je uit elkaar halen en kijken hoe het werkt maar bij software mag dat niet.
Het is met software helemaal niet zo anders als met hardware. Je kan een stuk hardware ook wel uit elkaar halen in een research lab, maar een kopie ervan uitbrengen is een ander verhaal.
[Reactie gewijzigd door Dreamvoid op zondag 22 januari 2012 12:56]
Lijkt me niet verboden.
Elke andere open source driver die niet door de fabrikant gemaakt is (en dat zijn er veel) is op een gelijkaardige manier gemaakt.
Elke andere open source driver die niet door de fabrikant gemaakt is (en dat zijn er veel) is op een gelijkaardige manier gemaakt.
In bepaalde delen van de wereld (waaronder de VS) is het niet zondermeer toegestaan om software te reverse-engineeren.
Sterker nog, wanneer er een beveiliging is geïmplementeerd, is het in sommige gevallen verboden om erover te schrijven wat je hebt aangetroffen of hoe je het zelf hebt uitgeplozen.
Dus als er ook maar een triviale beveiliging van wat dan ook in zit, begeef je je juridisch al op glad ijs.
En ik kan me goed voorstellen dat in videodrivers een bepaalde kopieerbeveiliging verwerkt is (HDCP bijvoorbeeld)
Sterker nog, wanneer er een beveiliging is geïmplementeerd, is het in sommige gevallen verboden om erover te schrijven wat je hebt aangetroffen of hoe je het zelf hebt uitgeplozen.
Dus als er ook maar een triviale beveiliging van wat dan ook in zit, begeef je je juridisch al op glad ijs.
En ik kan me goed voorstellen dat in videodrivers een bepaalde kopieerbeveiliging verwerkt is (HDCP bijvoorbeeld)
Kopiëren is niet toegestaan, valt onder het copyright. Reverse engineering is wel toegestaan bij software. Niet alleen bij drivers maar denk bijvoorbeeld ook aan Samba, die doet perfect de Windows netwerk omgeving na zonder dat daar een regel code van Microsoft inzit.
Ik heb veel respect voor deze uhm, reverse engineers. Het kost enorm veel tijd en je loopt in principe het wiel opnieuw uit te vinden. Daarnaast heb je veel minder bronnen tot je beschikking als iets toch anders werkt dan je verwacht. Kan je niet even aan een ander vragen of hij weet waarom het spaak loopt. Uiteindelijk heb je veelal een sub-optimaal resultaat dus het zal ook niet echt het gevoel geven dat je lonend werk hebt verricht.
Ik heb veel respect voor deze uhm, reverse engineers. Het kost enorm veel tijd en je loopt in principe het wiel opnieuw uit te vinden. Daarnaast heb je veel minder bronnen tot je beschikking als iets toch anders werkt dan je verwacht. Kan je niet even aan een ander vragen of hij weet waarom het spaak loopt. Uiteindelijk heb je veelal een sub-optimaal resultaat dus het zal ook niet echt het gevoel geven dat je lonend werk hebt verricht.
Developers hebben ook al een opensource 3d driver voor de FIMG 3DSE, de gpu in de samsung galaxy spica, gemaakt:
https://github.com/tom3q/openfimg/wiki
De driver is nog niet helemaal af, maar werkt al wel aanzienlijk beter dan de driver van Samsung!
https://github.com/tom3q/openfimg/wiki
De driver is nog niet helemaal af, maar werkt al wel aanzienlijk beter dan de driver van Samsung!
[Reactie gewijzigd door The_Double op zondag 22 januari 2012 14:05]
Ik heb het nog even nagezocht, zie artikel 6.
http://eur-lex.europa.eu/...=CELEX:31991L0250:NL:HTML
http://eur-lex.europa.eu/...=CELEX:31991L0250:NL:HTML
Hmm, ik hoop dat ze het van de Xorg kamer naar Janson of zo verplaatsen, want het zou wel eens druk kunnen worden bij die lezing
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 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
