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

Linux-kernel 4.12 komt uit met ondersteuning voor Pascal-3d-versnelling

Door , 29 reacties

Maandag is een nieuwe versie van de Linux-kernel uitgekomen met nummer 4.12. De release introduceert ondersteuning voor 3d-versnelling voor Nvidia's GTX 1000-gpu's in de opensource Nouveau-driver. Verder maakt ondersteuning voor Vega-gpu's van AMD deel uit van de kernel.

Volgens Linus Torvalds is deze release historisch gezien een van de grotere. Alleen 4.9 zou meer commits hebben gehad. De omvang zou in het huidige geval toe te schrijven zijn aan de toevoeging van de header files voor de ondersteuning van AMD's Vega, die de helft van de release vormen. De huidige amdgpu-driver biedt eerst ondersteuning, in de toekomst moeten er meer verbeteringen komen. Ondersteuning voor het aansturen van een monitor komt volgens Phoronix pas in versie 4.14 van de kernel.

De ondersteuning voor 3d-versnelling voor Nvidia-gpu's van de Pascal-generatie is evenmin geheel compleet. Zo is er nog geen ondersteuning voor het aanpassen van de kloksnelheid van een kaart, waardoor prestaties initieel zullen tegenvallen. Andere wijzigingen in de nieuwe kernel zijn onder meer dat Intels grafische i915-driver standaard gebruikmaakt van atomic modesetting, waardoor van tevoren niet-ondersteunde configuraties herkend en vermeden kunnen worden.

Ook zijn er twee nieuwe i/o schedulers in de vorm van Kyber en bfq. Volgens Heise moet die laatste voornamelijk tot prestatiewinsten leiden bij traditionele hdd's en niet zozeer bij ssd's. Met de toevoeging van deze en andere vernieuwingen komt het totale aantal regels in de kernel neer op 24,2 miljoen.

Door Sander van Voorst

Nieuwsredacteur

03-07-2017 • 11:21

29 Linkedin Google+

Reacties (29)

Wijzig sortering
Dat "ondersteuning" verhaal komt mij de strot uit. In ieder geval bij AMD.

Ondersteuning, in het geval van AMD grafische kaarten, betekent alleen ondersteuning door de kernel en de open source driver AMDGPU (dus geen ondersteuning door de closed source AMDGPU PRO driver ontwikkeld door AMD).

De RX 4xx serie heeft nog steeds geen generieke closed source Linux driver (zoals de R9 en R7 series). Zie hier : http://support.amd.com/en-us/download/linux. Alleen maar closed source AMDGPU PRO drivers voor de CentOS, RHEL, SLED/SLES 12 SP2 en Ubuntu ​16.04 distributies. Omdat de closed source driver nog teveel afhankelijk is van functionaliteit in oudere kernels. En AMD naar het schijnt slechts een (1) dev actief heeft op de AMDGPU PRO Linux driver.
Hetzelfde is van toepassing op de RX 5xx serie.

Waar ik mij het meest aan erger met de open source AMDGPU driver :
1) artefacts op de desktop : vensters en widgets met troep erin, tooltips met troep erin.
2) fans altijd op hoge snelheid en op maximale snelheid bij het afspelen van video, film, en in-browser CSS animaties met 2D of 3D versnelling. Het verlichte woord "Fan-Stop" op beide RX 480 grafische kaarten komt in Linux echt nooit aan. In Windows 8.1 wel.
3) geen OpenCL GPU rendering

Sinds een aantal maanden heeft de closed source AMDGPU PRO driver installer een command line switch om alleen de OpenCL driver te installeren op elke Linux distributie. Nuttig. Helaas is echter OpenCL 1.2 en geen OpenCL 2.0. Weer een halfhartige poging van AMD. Er is alleen een OpenCl 2.0 driver voor Red Hat Enterprise 6.5 en Ubuntu 14.04 : http://support.amd.com/en...Pages/OpenCL2-Driver.aspx.
Oudere respons van AMD personeel : https://community.amd.com/thread/205476. Er is echter geen verbetering.

Verder is er ook nog een strijd tussen AMD en Linux kernel devs over DC (vroeger DAL) enabling van de Linux kernel. Er is nog steeds geen overeenkomst in deze strijd : http://www.phoronix.com/s..._item&px=AMDGPU-DC-DRM-No

En de kwaliteit van de source code van de closed source drivers schijnt niet best te zijn :
..... I will certainly not help proprietary crap, if I don’t have a solid base to work with, and a bit of help from their side. I wish good luck to those who want to try those drivers, I’ve got a look inside, and got a blame face. .....
Reden genoeg voor Suse om support voor de closed source AMDGPU PRO driver in ieder geval te stoppen : https://lizards.opensuse....fglrx-rpms-end-of-an-era/

Er zijn natuurlijk altijd dappere individuen. :
https://github.com/volumetricsteve/AMDGPU-INSTALL
https://linuxconfig.org/g...ning-with-amdgpu-on-linux
https://aur.archlinux.org...n&SO=a&PP=50&do_Search=Go
Maar dat is zeker geen ideale oplossing. Er zijn vaak meer problemen dan met de open source driver. Wat niet zou moeten verbazen want AMD durft het niet aan. Zelfs op Ubuntu 16.04 (de eerste en langst door AMDGPU PRO ondersteunde distro) is de closed source driver niet zonder problemen.
Al eens naar ROCM gekeken?

Enige jammere is dat je processor toch iets of wat een nieuwere generatie moet zijn.

https://github.com/RadeonOpenCompute/ROCm

:)
De ondersteuning van distros door ROCM is zelfs nog minder dan AMDGPU PRO. Tenzij dat veranderd is. De distros die ik gebruik zijn (net zoals bij AMD GPU PRO) niet ondersteund.
Op het moment gebruik ik een i7-6850K. En upgrade naar de 16-core 32-thread Threadripper 1998. En ook weg van GPU rendering na het fiasco van 2 x RX 480.

Een HPC Blender renderfarm heb ik ook absoluut geen trek in : https://www.cineca.it/en/content/blender-render-farm
Er wordt (zoals zo vaak in Linux land) weer allerlei onrealistische en/of niche zaken erbij gehaald.
"support for" met de kernel is altijd de open source versie, omdat die included is. Voor die kernel versie moet je er niet vanuit gaan dat je Linux kan installeren als je een Vega kaart hebt. Dat is wat "supported" betekent.
Dat AMD de drivers links laat liggen is al algemeen bekend, omdat ze zich focussen op Windows. Daarnaast maken ze wel veel contributies voor de open source drivers, wat ik persoonlijk toch veel liever heb. Binary drivers installeren kan een nachtmerrie zijn en als je al een open source operating systeem gebruikt, wil je niet snel een closed source GPU driver.
3D acceleration was al lange tijd beschikbaar voor de open source drivers voor Polaris, en zelfs beter in sommige applicaties dan de closed source variant.
"De ondersteuning voor 3d-versnelling voor Nvidia-gpu's van de Pascal-generatie is eveneens niet geheel compleet. Zo is er nog geen ondersteuning voor het aanpassen van de kloksnelheid van een kaart, waardoor prestaties initieel zullen tegenvallen."

Waarom maken ze eerst niet iets af voordat ze het uitbrengen? Is hier een verklaring voor? :)
In software werk je in iteraties. De drivers zijn 'af' in het opzicht dat ze ondersteuning bieden voor de pascal GPUs. Daar ben ik heel blij mee, want dan kan ik mijn videokaart tenminste gebruiken.

Betere performance is altijd gewenst, maar ik denk dat NVIDIA (of wie de drivers ook heeft geschreven) het belangrijk vond om z.s.m. hun hardware te kunnen laten werken, en betere performance pas in latere iteraties toe te voegen.
Nu kunnen consumenten hun hardware tenminste gebruiken, al dan niet zo efficient als maar kan.
Helaas is het verhaal hier iets anders. De in-kernel driver voor nVidia hardware word niet geschreven door nVidia, maar is een reverse engineered driver genaamd 'nouveau'.
nVidia draagt hier wel aan bij voor hun Tegra chips, maar daar houd het al vrij snel op.

De reden dat de nouveau kernel driver sinds Maxwell nog geen reclocking support heeft is omdat nVidia sinds deze generatie signed firmware blobs vereist.
Nouveau heeft hiervoor wel al de nodige code klaar staan, maar nVidia heeft na jaren nog steeds de benodigde firmware blobs niet vrijgegeven.
Als gevolg hiervan kan de kernel driver alleen t/m de Kepler generatie reclocken. Voor alle nieuwere generaties wachten ze nog steeds op nVidia.

Wil je met Maxwell en nieuwer dus een beetje goede performance hebben is de losse closed-source nVidia driver eigenlijk je enige optie tot nVidia deze firmware eindelijk eens vrijgeeft.

[Reactie gewijzigd door Omar007 op 3 juli 2017 12:41]

Dat is precies wat nVidia wil, over de closed source driver hebben zij de controle én je hebt geen kans op uitlekken van geheimen (ontwerpdetaïls). Je ziet dat aan alles wat nVidia doet. Vroeger ondersteunde nVidia ook de open source driver maar rond de tijd van de overname van ATI door AMD is dat opeens sterk afgenomen. Toen is ook het nouveau-project begonnen en tussen de 1 en 2 jaar daarna stopte nVidia helemaal met bijdragen aan de oudere (pre-nouveau) opensource driver. Aan nouveau hebben ze, bij mijn weten, nooit bijgedragen.

AMD is hier heel anders in. Zij kiezen al sinds de overname van ATI ervoor om zoveel mogelijk vrij te geven voor zover dat mogelijk is want, net als nVidia waarschijnlijk, gedeeltelijk zijn zij afhankelijk van derden (code, patenten, componenten) waardoor zij bepaalde zaken niet vrij mogen geven. In het verleden was de closed-source driver van ATI/AMD dan ook veel beter als de open-source variant (die toen niet veel voorstelde) maar dat verschil is veel minder geworden. AMD beseft ook dat ze in deze de sympathie van de gebruikers nodig hebben en, zeker voor de linux-drivers, ook van de coders-community. Linux is voor zowel AMD als nVidia maar een niche. In hoeverre AMD in staat is meer in de Linux-drivers te investeren.
Dat is één helft van het verhaal, vanuit kernel maintanance is het juist belangrijk dat ze met deze commit nagenoeg de volledige impact op de kernel hebben afgevangen voor de voortschrijdende ondersteuning van deze gpu generaties.

Traditioneel is er altijd de nodige onenigheid van enerzijnds de kernel maintainers en anderzijds de GPU leveranciers die het iets minder nauw nemen met hun coding standaards om tijdig driver updates uit te brengen.

Beide partijen hebben uiteraard hun redenen bij de voor en tegens, maar zorgt toch voor het nodige impact. Driver patches worden niet geaccepteerd, driver patcher verhogen complexiteit code, driver patches dit, driver patches dat.... te veel om op te noemen.

Lang verhaal kort: de patch op de kernel moet zo snel mogelijk en bij voorkeur zo lean mogelijk landen. Daarna uitbreiden in bijvoorkeur behapbare patches t.b.v. code reviews.
Ik gebruik de 1030 nu icm een experimentele LE build; werk allerminst goed maar is "bruikbaar". Geen hevc support en booten gaat brak. Fijn om te lezen dat er aan ondersteuning vd de 1000-series gpu's gewerkt wordt . De 1030 gpu is in mijn beleving een prachtige oplossing die een low-power 8k gpu met hevc support naar de htpc gebruiker brengt. Dit icm nvidia purevideo, spatial temporal deinterlacin: live tv heeft er nog nooit zo mooi uitgezien.

Voor wie nu meteen met intel hd graphics aan komt zetten, geloof me, komt niet in de buurt van purevideo. Werkt op papier allemaal, hoe het er uitziet is een heel ander verhaal (zelfde als raspberry, amlogic soc's etc).
Je kan ook de proprietary nvidia drivers gebruiken uiteraard. Sowieso een beetje de vraag hoeveel van die features (volledig) ondersteund worden in de OSS driver, gezien sommigen nogal wat eisen (bijv. de encryptie van HDCP).
Ik denk dat de encryptie van HDCP geen prioritair heeft.
En ik zie liever support voor cuda in de kernel.
Tja, ik zou ook graag m'n kaart overclocken zonder dat ie X nodig heeft.

Voor bijv. Netflix als je 4k wilt in de toekomst is HDCP 2.2 met encryptie vereist. Voor nu ondersteund alleen Edge dat echter.

Prioriteit ligt daarmee heel erg aan hoe je het gebruikt.
Ik heb mijn 1050 nooit werkend gekregen op die build.
Maar er is nu gelukkig hoop ;)
Ikzelf heb ook een GT1030 (geen CUDA/HEVC-encoding helaas :-\ ) Dit alles werkt voorlopig wel, maar het is nog maar de vraag hoeveel nieuwe Nvidia Linux videodrivers er komen. Ook bij Intel is de Linuxondersteuning (qua developers) minimaal, er staan nog genoeg aandachtspunten open. Wat htpc's aangaat zit Linux aardig in de hoek waar de klappen vallen. Het is nog afwachten hoe de 'eenvoudige' GPUs van AMD uit dit alles komen.
Nvidia is gewoon rondweg arrogant en irritant om mee te werken als bedrijf.

De drivers op linux zijn zo closed source dat je beter met Nvidia kaarten op windows kan blijven hangen.

Een voorbeeld is dat je bij windows gewoon je kaart kan undervolten / power limit kan aanpassen terwijl dit in linux maar kan tot aan de "waarde" die default in de profielen is meegeleverd.

zelfs met nvidia-smi of nvidia-settings kan je een kaart niet op het gewenste niveau brengen (bv op linux kan ie niet lager dan 100 watt onder load terwijl op windows je zonder moeite op 55-60 watt kan komen).
Het gaat hier niet alleen om overklokken, maar ook de dynamische kloksnelheden die niet werken onder Nouveau. Dit kost dus performance met een onaangepaste kaart.
In software werk je in iteraties. De drivers zijn 'af' in het opzicht dat ze ondersteuning bieden voor de pascal GPUs. Daar ben ik heel blij mee, want dan kan ik mijn videokaart tenminste gebruiken.
Ja er is ondersteuning maar:
Ondersteuning voor het aansturen van een monitor komt volgens Phoronix pas in versie 4.14 van de kernel.

Wat die ondersteuning dan inhoud laat het artikel achterwege. Blijkbaar is de gpu dus wel al bruikbaar voor gpu-gebaseerde berekeningen (rendering) maar nog niet voor normaal gebruik (of gaming).
Nu kunnen consumenten hun hardware tenminste gebruiken, al dan niet zo efficient als maar kan.
Als er nog geen ondersteuning is voor een monitor kan de gewone consument er nog niets mee, dat is meer iets voor niche-gebruikers en bepaalde bedrijven.
Misschien is het ook deels kijken hoe dit performt en draait?
De vraag is eerder waarom het onderdeel van kernel is.

Gewoon losse kernel module je dynamisch kunt laden en als je wilt statisch mee compilen.
het is een losse module, die je wel of niet mee kan laten compileren, of als losse file achteraf apart kan inladen als je systeem draait.

maar het zit wel in de zelfde broncode, en is daarom onderdeel van de karnel.
Nu heb je iig beeld en een GUI beschikbaar. Net zoals de Vega GPU's van AMD. Het werkt, maar niet 100%, daar wordt aan gewerkt. Het is toch ook prima als je een Tesla koopt die initieel max 150 km/u kan, maar via een software update een topsnelheid van 250 km/u kan halen? In beide gevallen kan je gewoon van punt A naar punt B komen.
"Ook zijn er twee nieuwe i/o schedulers in de vorm van Kyber en bfq."
Dat laatste is handig voor m'n lappie met een traditionele HDD, maar moet ik zelf nog handmatig de I/O scheduler aanzetten of herkent het automatisch de HW en selecteert de juiste I/O scheduler?
Het lijkt een handmatige actie.
https://wiki.archlinux.or...e_the_BFQ_I.2FO_Scheduler
BFQ is an I/O scheduler and must explicitly be enabled in order to use it.
Net even geprobeerd, met deze kernel werken de volume knoppen aan de buitenkant van de Asus Zenbook Flip eindelijk, maar de Wifi adapter niet meer. Ik wacht nog even op een volgende release. Nu weer terug naar 4.11.8.
Volgens mij heeft de closed-source driver wel al volledige support. Het gaat hier alleen over de open-source driver nouveau, die overigens wel vaak standaard gebruikt wordt.
Dus er is driver support voor AMD Vega GPU's, maar je kunt er nog geen displays mee aansturen. Het grote gros van de gebruikers heeft er dus nog niets aan.
Is het niet een beetje vreemd om drivers die zo incompleet zijn alvast mee te nemen in een kernel?
Het grote gros van de gebruikers heeft er dus nog niets aan.
Het grootste deel van de gebruikers heeft niet eens een Vega GPU....
Daarnaast lijkt de huidige Vega FE voor een groot deel gericht op compute taken, en daar heb je geen display-aansturing voor nodig. Die gebruikers kunnen wellicht wel aan de slag.

[Reactie gewijzigd door Zer0 op 3 juli 2017 12:32]

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*