Cookies op Tweakers

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

Meer informatie

Windows Subsystem for Linux krijgt ondersteuning voor DX12 en apps met gui

Tijdens zijn Build-evenement voor ontwikkelaars heeft Microsoft aangekondigd dat het gpu-acceleratie naar het Linux-subsysteem van Windows 10 brengt. Daarvoor krijgt WSL2 ondersteuning voor DirectX 12 en kan het ook Linux-programma's met gui draaien.

In een blogartikel geeft Microsoft de details over de komst van de hardwarematige grafische acceleratie naar het Windows Subsystem for Linux 2. WSL2 is vanaf de May 2020 Update onderdeel van Windows 10 en bevat bijvoorbeeld een Linux-kernel, maar het subsysteem draait standaard alleen command-line tools. Voor applicaties met een grafische userinterface moet een gebruiker externe toepassingen zoals X11 gebruiken.

Microsoft werkt eraan om dat te veranderen. De stap is het gevolg van Microsofts werk aan gpu-virtualisatie. Het bedrijf ontwikkelt hiervoor een Linux-kerneldriver die een gpu via het wddm gpu-paravirtualization-protocol beschikbaar maakt voor de usermode van Linux.

Volgens Microsoft krijgen applicaties in de Linux-omgeving daardoor dezelfde toegang tot de gpu als Windows-applicaties. Microsoft benadrukt verder dat het om de volledige D3D 12-api gaat die dezelfde functionaliteit en prestaties biedt als op Windows, minus de overhead die het gevolg is van virtualisatie.

Microsoft meldt verder dat het de OpenCL- en OpenGL-lagen voor DX12 waar het aan werkt, ook gaat gebruiken om hardwareacceleratie op basis van die standaarden naar het Linux-subsysteem te brengen. Dat zal gebeuren via de opensource Mesa-bibliotheek. Microsoft maakt de gpu-kerneldriver voor Linux opensource beschikbaar, maar de DirectX-core en D3D 12-bibliotheken blijven gesloten.

Microsoft werkt verder samen met Nvidia aan cuda-ondersteuning voor het Windows Subsysteem voor Linux. Die ondersteuning verschijnt met de komst van Nvidia's komende wddm v2.9-driver. De uitbreiding van WSL 2 is bedoeld om ontwikkelaars die Linux-tools gebruiken binnenboord te houden bij Windows 10.

Tegelijkertijd toont het de veranderde houding van Microsoft richting opensource aan. Recent zei Microsoft-president Brad Smith dat zijn bedrijf 'aan de verkeerde kant van de geschiedenis stond toen opensource explodeerde aan het begin van de eeuw'.

Door Olaf van Miltenburg

Nieuwscoördinator

20-05-2020 • 10:51

151 Linkedin

Submitter: Sp3ci3s8472

Reacties (151)

Wijzig sortering
Linux kernel maintainers hebben al aangeven dat dit niet zomaar de kernel in gaat:
https://www.phoronix.com/...oft-DXGKRNL-Uphill-Battle

Lang verhaal kort:
- Standaard worden er geen koppelingen in de Kernel opgenomen die koppelen met gesloten componenten
- Dit kan lijden tot een divide-and-conquer, triple-E, situatie waarbij Linux afhankelijk wordt van componenten buiten hun invloedsfeer
- Er is zorg om patenten, aangezien Micorsoft hier een stukje van zijn NT kernel naarbinnen probeert te fietsen.

Je kunt er ook vanuit gaan dat de FSF en de SFC al vast meelezen en overleggen met ontwikkelaars over mogelijke schending van de GPL.

Edit.

Ik vermoed dat Microsoft zich hier nog wel eens in heeft vergist. Balmer's "Linux is Cancer" was een hele heldere vervloeking van het open model dat Linux vertegenwoordigd, en hoe meer Windows daar mee wilt koppelen, des te meer het gaat schuren.

Super edit.

Super interessante ontwikkeling in de zaak;
https://www.phoronix.com/...soft-Writing-Wayland-Comp

We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux.

Het lijkt er dus op dat ze intern gesproken hebben over het uitgeven van DirectX als onderdeel van de Linux kernel. Wat dus GPL 2.0 zou betekenen.

[Reactie gewijzigd door Eonfge op 20 mei 2020 14:13]

Die uitspraak van Balmer was in een tijd de verkoop van Windows nog het primaire verdienmodel was. Sinds een hele tijd focust Microsoft zich vooral op cloud services. Welk lokaal OS daar onder ligt maakt dan niet meer zo veel uit. Daarom komen ze ook met verschillende initiatieven om het voor o.a. Linux gebruikers makkelijk te maken om deze online diensten te gebruiken.

Daarnaast is Microsoft sowieso druk bezig om hun diensten op Android (Linux-kernel) aan de man te brengen. De stap om je applicaties ook op een desktop of server versie van Linux werkend te krijgen lijkt mij dan ook niet zo heel erg moeilijk.

[Reactie gewijzigd door Titan_Fox op 20 mei 2020 11:56]

Even advocaat van de duivel spelen;
Dit is niet hoe Embrace, Extend and Extinguish werkt.
De Extend fase zou ervoor moeten zorgen dat gebruikers afhankelijk worden van de (propriëtaire/gesloten) toevoegingen die je als duivel doet, zodat mensen niet meer terug kunnen / willen.
Bijvoorbeeld Android. AOSP is een prima werkende Android versie en alles daaraan is te forken / vrij, libre en open te houden, maar hoe groot is het marktaandeel van AOSP telefoons ? Als Google vandaag besluit om Android alleen nog maar achter gesloten deuren door te ontwikkelen (Extinguish fase), dan zijn bijna alle Android gebruikers opeens vendor-locked. Een fork van AOSP die dan door de community verder doorontwikkeld wordt zal steeds verder afwijken van Google Android, en alle apps die rusten op Google Play Services zullen op een gegeven moment niet meer werken op AOSP. (Ik ga er hierbij vanuit dat Google op dat moment ook Google Play Services verder dicht gaat spijkeren zodat dingen als microG niet meer haalbaar zijn)
Vanaf dat moment wordt AOSP net zo'n buitenbeentje als Sailfish; het werkt prima, maar je mist een hoop (native) features die Google Android (en Apple IOS) wel hebben.

Voor Microsoft Linux zou dit betekenen dat ze zoveel mogelijk willen bijdragen aan essentiële dingen zoals de Linux kernel, Git etc. om afhankelijkheid te creëren. Vervolgens interessante nieuwe features toevoegen (zoals binairy blob DirectX ofzo) om zo te zorgen dat 3e partijen afhankelijkheden gaan creëren op jouw (propriëtaire) toevoegingen. Zodra de meerderheid van de gebruikers in sterke mate afhankelijk is van jouw bijdragen / diensten / platform ( Kernel code / DirectX, Visual Studio Code / Github om maar wat te noemen ) trek je de stekker eruit, en kunnen mensen niet meer terug zonder eerst jaren terug in de tijd te gaan qua features / gebruiksgemak.

Ik zeg niet dát het gaat gebeuren, maar tot nu gaat alles zoals ik het zou doen al ik Microsoft was en een tripple-E strategie zou hebben aangaande Linux / Open Source…

Zo, nu kan het alu hoedje weer af.
Ik zie niet helemaal wat dit te maken heeft met de kernel development in de reacties hierboven. Microsoft gebruikt een custom kernel voor WSL/WSL2 en kan daar instoppen wat ze willen. Er is helemaal geen noodzaak om 1) DX12 open source te maken 2) Linux kernel dev deze aanpassing over te nemen. Sterker nog, dit zijn aanpassingen voor een hele specifieke use-case (nl WSL) die daarbuiten weinig toegevoegde waarde heeft, zeker niet voor Linux-core. Er zijn wel toepassingen te verzinnen voor andere virtualisatie oplossingen, maar dat is niet per definitie een zorg voor de linux kernel development (of Microsoft).

Dat gezegd hebbende, ALS Microsoft het voorelkaar krijgt om op deze manier near-native performance te geven met virtualisatie, dan zijn er wel redenen voor MS om mogelijkheden en oplossingen te verzinnen dit wel in de kernel te krijgen omdat dit dan in een klap Windows bovenaan zet als Linux virtualisatie platform. (je hoeft maar met Linux GUI gewerkt te hebben onder VMware ESX om te weten hoe ruk het kan zijn)
Microsoft gebruikt een custom kernel voor WSL/WSL2 en kan daar instoppen wat ze willen.
Dat is niet correct. Ten eerst wordt voor WSL versie 1 helemaal geen Linux kernel gebruikt maar een door Microsoft zelf geschreven interface laag die Linux kernel API/ABI calls omzet naar hun NT kernel equivalenten. Feitelijk exact hetzelfde als dat Wine doet op Linux, maar dan precies de andere kant op.

WSL2 maakt inderdaad wel gebruik van een Linux kernel die voor zover ik weet draait in een afgeslankte versie van Hyper-V. Het is zeer waarschijnlijk dat deze kernel door Microsoft aangepast is, maar dat betekend niet dat ze er zomaar in mogen stoppen wat ze willen want ze moeten gewoon aan de GPL voldoen. De GPL zegt dat je aanpassingen aan de code weer moet delen met de rest van de wereld, je mag niet zomaar de code aanpassen en daarna doen wat je wilt zoals dat bijvoorbeeld wel mag met een BSD licentie.

Er zijn hier wel wegen omheen door bijvoorbeeld DKMS te gebruiken en daar wordt door anderen in hun reacties ook over gesproken. Ik snap dus ook niet dat je een +2 krijgt.

[Reactie gewijzigd door rbr320 op 20 mei 2020 12:05]

Nee, dat mag dus niet: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. ". Buiten de kernel mag wel. Je mag geen blobs in de kernel stoppen tenzij je kan aantonen dat je ontwikkelaars de hele dag in een hex-editor changes doorvoeren op die blob.
Uhm, heb je de GPL licentie gelezen, gpl v2 om precies te zijn? Daar staat in dat de source code beschikbaar moet zijn als je het distributeerd
Dat dus
Hmmm. Nou, dit lijkt heel mooi, maar het schuurt toch wel. Dit wordt een kernel implementatie om vervolgens tegen closed-source binary blob userspace drivers aan te babbelen. Lijkt mij wat gek...

https://lore.kernel.org/l...JvP6A@mail.gmail.com/T/#t
Dat is niet anders als met de NVIDIA drivers echter.
Klopt. Daarom ook dat NVidia bijvoorbeeld nog geen Wayland ondersteund. Dit nieuwe display protocol hangt op een stukje Kernel functionaliteit genaamd Direct Rendering Manager, en NVidia weigert daarmee te koppelen.

NVidia is zo zuur op Linux, dat de laatst render servers die ik heb opgetuigd allemaal zijn uitgerust met AMD kaarten. 10% performance verlies is het echt wel waard als je daarvoor veel minder koppijn hebt.
En daarom kreeg NVidia ook de vinger van Torvalds. Dat het kan betekent niet dat het een goed idee is voor het bedrijf of de klanten. In het geval van Nvidia is het echter geen goed idee voor de klanten van Nvidia HW want de support is gewoon minder.
Als je Triple-E er inderdaad bij wil halen, zitten we al een hele tijd bij Extend.
Microsoft is al sinds 2015 een grote sponsor van Linux. Linux VM's zijn de grootste afnemers in Azure (ik meen vorige week gelezen te hebben dat 51% van de VMcores voor een Linux VM is).

Er lopen al jaren geen (proxy) rechtszaken tussen Microsoft en Linux (distributeurs). Binnen de Microsoft community zijn er mensen die zich afvragen of er wellicht een grote distributeur opgekocht gaat/zou moeten worden door Microsoft.
De houding van Microsoft t.o.v. open source is gigantisch veranderd. Sterker nog, de gehele houding van Microsoft naar computing is enorm veranderd.
Microsoft zelf vol in op hun cloud platform. Of dit nu Azure, Office365 of Dynamics365 is, daar zit voor Microsoft het goed te verdienen geld.

Microsoft is groot geworden met de desktop voor eindgebruikers. Desktops zijn al zo goed als EOL, steeds meer bedrijven stappen over op laptops en alleen serieuze gamers zullen een desktop PC hebben. Normale mensen hebben een laptop of een tablet om op te werken.
Op laptops is MS nog wel groot, op tablets niet.
Microsoft kan bijna geen geld meer verdienen met het verkopen van Windows op de desk/laptop, terwijl de clouddiensten ieder jaar met 10-tallen procenten groeit, mede dankzij Linux.

Daarom denk ik (maar hoop ik ook) dat de derde E (Extinguish) verleden tijd is. Microsoft ziet dat het Linux in Azure nodig heeft, als ze Linux dus gaan Extinguishen, schieten ze zichzelf (meerdere keren) in de voet.

[Reactie gewijzigd door walteij op 20 mei 2020 13:17]

Dat je op Linux voor Windows ontwikkeld hoeft nog niet te betekenen dat het crossplatform is, kan ook gewoon crosscompiled zijn. Het testen van software is het sowieso handiger op een kale installatie in een VM.
Daarnaast bestaat er meer software dan alleen voor desktops, smartphones of websites. Microcontrollers, IoT-devices of aansturing van industriële machines is een zeer grote markt waar je alleen in laatste Windows zult aantreffen. Met de sector waar je zelf in bevind komt dan ook het verschil in wat de meeste programmeurs die je kent, gebruiken. In mijn omgeving is Windows vooral nuttig voor ontwikkelaars omdat Outlook en Word erop draaien.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True