En rad kod gav Meteor Lake 72 procent högre prestanda

Permalänk
Medlem
Skrivet av GuessWho:

Det hade också varit intressant om Linux hade get ~ 70% bättre prestanda i nästan allt gällande spel och arbete än Windows.

Undrar hur många som skulle kunna tänka sig att byta till Linux då ?

Vad sägs om över 100%?

https://www.phoronix.com/review/adl-linux516-windows

Många har redan bytt till Linux genom SteamOS, men så länge spelen/spelmotorerna fortsätter att vara Windows-binärer, så lär inte prestandan vara något att bli upphetsad över.

Mer öppen källkod hade varit något!

Permalänk
Medlem
Skrivet av walkir:

Vad sägs om över 100%?

https://global.discourse-cdn.com/clearlinux/original/2X/f/f1515848e077ecf759b273c91048826c465f598b.png

https://www.phoronix.com/review/adl-linux516-windows

Många har redan bytt till Linux genom SteamOS, men så länge spelen/spelmotorerna fortsätter att vara Windows-binärer, så lär inte prestandan vara något att bli upphetsad över.

Mer öppen källkod hade varit något!

Över 100% är helt klart en imponerande skillnad.

Frågan är hur relevant testet är för användares upplevelse av datorn och det de gör på den ?
För jag tror att det hade kunnat bli "the year of Linux desktop" om folk plötsligt fick 50-100% (eller mer) extra prestanda i det som de gör mest och/eller tycker är viktigast.

Jag har varit lite sugen på att skaffa en Steam Deck, framförallt Steam Deck OLED med bättre batteritid och bättre skärm verkar trevlig.
Men inte säker på om jag skulle använda den tillräckligt för att motivera kostnaden.

Men har tänkt tanken att skaffa en Steam Deck skulle kunna vara ett steg på väg bort från Windows beroendet.

Angående spel är väl också en sak att Nvidia är störst på dedikerade grafikkort.
Men deras Linux drivrutiner är inte lika bra som Windows drivrutinerna?

Permalänk
Medlem
Skrivet av dlq84:

Holy magic numbers, batman.

Väldigt intressant att vissa delar är const/defs, mellan andra är magic numbers.. nästan som att de vill hindra att folk ska förstå vad siffrorna betyder..

Permalänk
Datavetare
Skrivet av GuessWho:

Över 100% är helt klart en imponerande skillnad.

Frågan är hur relevant testet är för användares upplevelse av datorn och det de gör på den ?
För jag tror att det hade kunnat bli "the year of Linux desktop" om folk plötsligt fick 50-100% (eller mer) extra prestanda i det som de gör mest och/eller tycker är viktigast.

Jag har varit lite sugen på att skaffa en Steam Deck, framförallt Steam Deck OLED med bättre batteritid och bättre skärm verkar trevlig.
Men inte säker på om jag skulle använda den tillräckligt för att motivera kostnaden.

Men har tänkt tanken att skaffa en Steam Deck skulle kunna vara ett steg på väg bort från Windows beroendet.

Angående spel är väl också en sak att Nvidia är störst på dedikerade grafikkort.
Men deras Linux drivrutiner är inte lika bra som Windows drivrutinerna?

Angående det markerade, tror det väldigt mycket beror på vad man refererar till här.

När det handlar om saker som är skrivet native till Linux, vilket tyvärr rätt sällan gäller spel men är normalfallet för allt som har med CUDA att göra, så är prestanda typiskt bättre under Linux. Hur mycket beror på område, machine-learning med PyTorch se allt från 10 till 50-60 % bättre prestanda under Linux.

Både Unity och Unreal Engine rekommenderar Nvidias propretära GPU-drivare om man kör native Linux. Så även 3D stödet är bäst med Nvidia, fast det förutsätter just "native Linux".

Menar man istället: försöka köra Windows binärer under Linux med olika former av emulering av DirectX lär det mer handla om vilken GPU man testat dessa lager mest med. Givet att Valve primärt lär prioritera Steam Deck för Proton så blir det då fördel Radeon här.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
99:e percentilen
Skrivet av Djhg2000:

Clickbait-titel (det är upp till 72% ökning i en specifik last) och Tom's Hardware som källa istället för Phoronix, vad är det som händer egentligen?

Skrivet av Magnus303:

72% högre prestanda? Genomsnittet var ju 7%. En clickbait på över 10 ggr sanningen alltså!

Mm, Phoronix rubrik är betydligt mer nyanserad och rättvisande:

One-Line Patch For Intel Meteor Lake Yields Up To 72% Better Performance, +7% Geo Mean

SweClockers rubrik för framtida referens:

En rad kod gav Meteor Lake 72 procent högre prestanda

Hade varit intressant att höra vad @alundberg tänker kring detta.

Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Medlem
Skrivet av GuessWho:

Angående spel är väl också en sak att Nvidia är störst på dedikerade grafikkort.
Men deras Linux drivrutiner är inte lika bra som Windows drivrutinerna?

Har inga bra erfarenheter av NVIDIA-kort och Linux. Det bästa är om man kan köra "nouveau"-drivaren som följer med i kerneln, men då tappar man mycket prestanda jämfört med den officiella drivrutinen (som för min del mest har fört med sig timmar av felsökning innan jag bara har gått tillbaka till "noveau").

Grafik från AMD har funkat väldigt bra sedan de bytte från en binär drivrutin (likt vad NVIDIA fortfarande kör) till AMDGPU-drivrutinen. Eftersom den är helt öppen och inkluderad i kerneln så går den aldrig sönder för att den hamnar ur synk med kernelversionen under systemuppdateringar, och den har mycket bra stöd för moderna API:er som Wayland och DMABUF.

Vidare fungerar AMDs kort bra om man ska använda VGA Passthrough till en virtuell maskin med Windows för att spela de få spel som inte funkar i Linux. NVIDIAs kort gav väldigt länge bara felkod 43 om man försökte använda dem i en virtuell maskin. Har hört något rykte om att det ska vara löst nu men har inget installerat NVIDIA-kort att testa det med.

Intel har rent allmänt utmärkt stöd i de flesta fall. Historiskt har de varit lite släpande på enstaka punkter, som OpenCL, men deras grafik har alltid fungerat (nysläppta kretsar har behövt absolut senaste kerneln men inte mer än så). Inte haft chansen att testa något av deras lösa kort men de borde fungera lika bra eftersom det är samma drivare som till senaste generationerna av integrerad grafik.

TL;DR: NVIDIA och Linux innebär mycket problem, använd ett kort från AMD (eller Intel) istället om du kan.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem

Clickbait, genomsnittet var endast 7% vid 100 test.

Lite som att hävda att nätverket blev 350% snabbare hemma när man bockat ut NAT, japp det blev det men man offrade säkerheten och det lär inte vara annorlunda här.
Prestandan är vad den är, det går inte att höja prestandan på kislet som redan är tillverkar, men man kan ta genvägar i mjukvaran.

Permalänk
Datavetare
Skrivet av Djhg2000:

Har inga bra erfarenheter av NVIDIA-kort och Linux. Det bästa är om man kan köra "nouveau"-drivaren som följer med i kerneln, men då tappar man mycket prestanda jämfört med den officiella drivrutinen (som för min del mest har fört med sig timmar av felsökning innan jag bara har gått tillbaka till "noveau").

Grafik från AMD har funkat väldigt bra sedan de bytte från en binär drivrutin (likt vad NVIDIA fortfarande kör) till AMDGPU-drivrutinen. Eftersom den är helt öppen och inkluderad i kerneln så går den aldrig sönder för att den hamnar ur synk med kernelversionen under systemuppdateringar, och den har mycket bra stöd för moderna API:er som Wayland och DMABUF.

Vidare fungerar AMDs kort bra om man ska använda VGA Passthrough till en virtuell maskin med Windows för att spela de få spel som inte funkar i Linux. NVIDIAs kort gav väldigt länge bara felkod 43 om man försökte använda dem i en virtuell maskin. Har hört något rykte om att det ska vara löst nu men har inget installerat NVIDIA-kort att testa det med.

Intel har rent allmänt utmärkt stöd i de flesta fall. Historiskt har de varit lite släpande på enstaka punkter, som OpenCL, men deras grafik har alltid fungerat (nysläppta kretsar har behövt absolut senaste kerneln men inte mer än så). Inte haft chansen att testa något av deras lösa kort men de borde fungera lika bra eftersom det är samma drivare som till senaste generationerna av integrerad grafik.

TL;DR: NVIDIA och Linux innebär mycket problem, använd ett kort från AMD (eller Intel) istället om du kan.

När testade du Intel eller Nvidia på Linux senast?

T.ex. det kring OpenCL. Nvidia vägrade OpenCL 2.x, men orsaken var att man lyckats stoppa in saker där som i praktiken var rätt hopplös att implementera på ett bra sätt på något annat än Intels/AMDs iGPUer.

Dessa problem är fixade i OpenCL 3.x, som Nvidia och Intel båda stödjer i deras Linux drivare men vad jag kan se har inte AMD inte implementerat något efter OpenCL 2.x.

Intel har numera väldigt bra OpenCL stöd då de använder OpenCL 3.x som "low-level driver" till SyCL (högnivå ersättare till OpenCL, SyCL är betydligt mer likt CUDA i abstraktionsnivå). SyCL används sedan som GPU/FPGA/NPU lager mot OneAPI.

AMD har så här långt inte alls brytt sig om SyCL utöver det stöd som Xilinx hade innan de blev köpta av AMD. HipSyCL leds av Heidelberg University.

Så när man pratar om "bra GPU-stöd" måste man väldigt mycket göra distinktionen "native Linux stöd" vs "köra windows binärer via Proton". Den förra har bäst stöd på Nvidia följt av Intel, den sista lär rimligen ha bäst stöd på Radeon.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av GuessWho:

Över 100% är helt klart en imponerande skillnad.

Frågan är hur relevant testet är för användares upplevelse av datorn och det de gör på den ?
För jag tror att det hade kunnat bli "the year of Linux desktop" om folk plötsligt fick 50-100% (eller mer) extra prestanda i det som de gör mest och/eller tycker är viktigast.

Jag har varit lite sugen på att skaffa en Steam Deck, framförallt Steam Deck OLED med bättre batteritid och bättre skärm verkar trevlig.
Men inte säker på om jag skulle använda den tillräckligt för att motivera kostnaden.

Men har tänkt tanken att skaffa en Steam Deck skulle kunna vara ett steg på väg bort från Windows beroendet.

Angående spel är väl också en sak att Nvidia är störst på dedikerade grafikkort.
Men deras Linux drivrutiner är inte lika bra som Windows drivrutinerna?

Skrivet av Djhg2000:

Har inga bra erfarenheter av NVIDIA-kort och Linux. Det bästa är om man kan köra "nouveau"-drivaren som följer med i kerneln, men då tappar man mycket prestanda jämfört med den officiella drivrutinen (som för min del mest har fört med sig timmar av felsökning innan jag bara har gått tillbaka till "noveau").

Grafik från AMD har funkat väldigt bra sedan de bytte från en binär drivrutin (likt vad NVIDIA fortfarande kör) till AMDGPU-drivrutinen. Eftersom den är helt öppen och inkluderad i kerneln så går den aldrig sönder för att den hamnar ur synk med kernelversionen under systemuppdateringar, och den har mycket bra stöd för moderna API:er som Wayland och DMABUF.

Vidare fungerar AMDs kort bra om man ska använda VGA Passthrough till en virtuell maskin med Windows för att spela de få spel som inte funkar i Linux. NVIDIAs kort gav väldigt länge bara felkod 43 om man försökte använda dem i en virtuell maskin. Har hört något rykte om att det ska vara löst nu men har inget installerat NVIDIA-kort att testa det med.

Intel har rent allmänt utmärkt stöd i de flesta fall. Historiskt har de varit lite släpande på enstaka punkter, som OpenCL, men deras grafik har alltid fungerat (nysläppta kretsar har behövt absolut senaste kerneln men inte mer än så). Inte haft chansen att testa något av deras lösa kort men de borde fungera lika bra eftersom det är samma drivare som till senaste generationerna av integrerad grafik.

TL;DR: NVIDIA och Linux innebär mycket problem, använd ett kort från AMD (eller Intel) istället om du kan.

Efter att Nvidia släppte 555-drivrutinen för inte så längesedan så ser det ut som att även de är ett vettigt alternativ.
Så om intresse finns så föreslår jag att man kollar lite noggrannare på ämnet.

Visa signatur

Marantz NR1605, Rotel RB1090, Ino Audio piPs
SMSL SP200 THX Achromatic Audio Amplifier 888, SMSL M400, Audio-Gd NFB-11 (2015), Objective2+ODAC RevB, Audeze LCD-2 Rosewood, Monoprice M1060, ATH-M40x, Sennheiser HD660S, DROP X KOSS ESP/95X, Koss KPH30i, DROP X HiFiMan HE4XX

Permalänk
Medlem
Skrivet av Yoshman:

När testade du Intel eller Nvidia på Linux senast?

T.ex. det kring OpenCL. Nvidia vägrade OpenCL 2.x, men orsaken var att man lyckats stoppa in saker där som i praktiken var rätt hopplös att implementera på ett bra sätt på något annat än Intels/AMDs iGPUer.

Dessa problem är fixade i OpenCL 3.x, som Nvidia och Intel båda stödjer i deras Linux drivare men vad jag kan se har inte AMD inte implementerat något efter OpenCL 2.x.

Intel har numera väldigt bra OpenCL stöd då de använder OpenCL 3.x som "low-level driver" till SyCL (högnivå ersättare till OpenCL, SyCL är betydligt mer likt CUDA i abstraktionsnivå). SyCL används sedan som GPU/FPGA/NPU lager mot OneAPI.
https://www.khronos.org/assets/uploads/blogs/2020-blog-sycl-03.jpg

AMD har så här långt inte alls brytt sig om SyCL utöver det stöd som Xilinx hade innan de blev köpta av AMD. HipSyCL leds av Heidelberg University.

Så när man pratar om "bra GPU-stöd" måste man väldigt mycket göra distinktionen "native Linux stöd" vs "köra windows binärer via Proton". Den förra har bäst stöd på Nvidia följt av Intel, den sista lär rimligen ha bäst stöd på Radeon.

Jag använder en laptop med Intel-grafik (och NVIDIA Optimus men den GPUn gör oftast inte mer än slangar ut bilder via DMABUF till externa skärmanslutningar med nouveau-drivaren) varje dag, så jag är ganska väl bekant med situationen. Det är dock inte en maskin som är representativ för NVIDIAs binära drivrutin eftersom den efter alla dessa år fortfarande bara har sönder saker i Debian när den ska försöka (och fatalt misslyckas med att) samsas med Intels drivare Mesa-stacken.

Jag har dock även ett GeForce 1050 som jag använder för testning ibland, men varje gång hittills har det åkt ur maskinen när jag tröttnar på att deras binära drivare är så dålig. DKMS-fel orsakade av förändringar i senaste Linux-kärnan, krascher som inte går att felsöka när spåret slutar vid deras binära blob, trasigt Wayland som bara halvt fungerar för att NVIDIA satte sig på tvären och tvingade mjukvarustacken att ha stöd för just deras special-API istället för att följa standarden, etc. Jag har liksom bättre saker att göra än att försöka balansera korthuset som NVIDIA kallar en stabil drivrutin.

OpenCL på Intel var ett exempel på ett historiskt problem. Ett annat exempel är hur de var sena med att byta till Gallium-arkitekturen i Mesa. Det betyder inte att det är ett problem längre, det var ett exempel på att Intel inte heller har ett fläckfritt förflutna med Linux.

GPGPU på AMD har varit deras akilleshäl ett bra tag nu, men det har ganska liten påverkan på spel. Har inte följt utvecklingen där på några månader men deras idé med ROCm som mellanlager och tunna översättningslager mot vanligare API:er är en chansning som vi kanske inte har sett slutet av än.

Sedan kan man fortsätta stoppa huvudet i sanden och säga att NVIDIAs binära drivare fungerar bra i Linux, men då gör man NVIDIA en björntjänst. NVIDIA spelar inte efter samma regler som resten av marknaden, och den största anledningen till att folk anstränger sig för att för NVIDIA att fungera med Linux ändå är för att NVIDIA har en så stor del av Windows-marknaden.

Edit: Det är ju egentligen hela Mesa-stacken som NVIDIAs drivrutin har sönder, inte bara Intels drivrutin. Fixat i texten.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
Skrivet av backspace:

Efter att Nvidia släppte 555-drivrutinen för inte så längesedan så ser det ut som att även de är ett vettigt alternativ.
Så om intresse finns så föreslår jag att man kollar lite noggrannare på ämnet.

Jag har starka tvivel på att den kan samarbeta med Mesa, men ser ut som att den har bättre förutsättningar för att inte ha sönder Wayland iallafall. Kommer att testa den i nästa omgång med mitt 1050-kort, tack för tipset!

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Medlem
Skrivet av Djhg2000:

Jag har starka tvivel på att den kan samarbeta med Mesa, men ser ut som att den har bättre förutsättningar för att inte ha sönder Wayland iallafall. Kommer att testa den i nästa omgång med mitt 1050-kort, tack för tipset!

Du får gärna återkoppla om du vill när du har provat.
Jag är nämligen nyfiken men eftersom jag sitter med ett AMD-kort så det blir ju inte att jag kan testa själv.
Kanske kan starta en ny tråd i Linux-delen av forumet.

Visa signatur

Marantz NR1605, Rotel RB1090, Ino Audio piPs
SMSL SP200 THX Achromatic Audio Amplifier 888, SMSL M400, Audio-Gd NFB-11 (2015), Objective2+ODAC RevB, Audeze LCD-2 Rosewood, Monoprice M1060, ATH-M40x, Sennheiser HD660S, DROP X KOSS ESP/95X, Koss KPH30i, DROP X HiFiMan HE4XX

Permalänk
Datavetare
Skrivet av Djhg2000:

Jag använder en laptop med Intel-grafik (och NVIDIA Optimus men den GPUn gör oftast inte mer än slangar ut bilder via DMABUF till externa skärmanslutningar med nouveau-drivaren) varje dag, så jag är ganska väl bekant med situationen. Det är dock inte en maskin som är representativ för NVIDIAs binära drivrutin eftersom den efter alla dessa år fortfarande bara har sönder saker i Debian när den ska försöka (och fatalt misslyckas med att) samsas med Intels drivare Mesa-stacken.

OK, är jag med. Optimus är, och lär tyvärr förbli, ett rejält sorgebarn när det kommer till Linux-stöd. Som jag förstår finns ingen direkt standard för iGPU och dGPU interagerar med varandra, så går inte göra en fullt fungerande allmängiltig lösning.

Att du specifikt får problem med Mesa-stacken är inte heller speciellt konstigt. Vad är Mesa? Ju det är en, av potentiellt många, implementationer av OpenCL, OpenGL, Vulkan etc.

Det normala är ju att man behöver just en sådan implementation och för varje specifik applikation kan man bara använda just en implementation (om man inte specifikt skriver applikationen att kunna hantera flera).

Nvidias binära drivrutin har en helt separat implementation av alla dessa API som inte alls beror på Mesa, vilket är helt enligt hur dessa tekniker är tänkt att fungera. Resultatet i en iGPU/dGPU lösning där enda kretsen använder Mesa och den andra använder något annat lär då bli: en kommer inte fungera och det är "by design".

Haft en enda laptop med Optimus under de år jag körde Linux (Ubuntu) som primärt desktop OS, blev "aldrig mer"... När jag skriver att Nvidia har bästa Linux native stöd är det helt i fallet "datorn har bara Nvidia GPU", vilket inkludera iGPU i deras Tegra-plattform.

Positiva är att det ändå finns ett sätt att köra Linux på laptops med Optimus med riktigt bra stöd: WSL2. Nvidia har otroligt bra WSL2 drivare, är faktiskt lite komiskt att sitta på en Windows-dator och se hur t.ex. PyTorch/CUDA program kör betydligt snabbare under Ubuntu/WSL2 än "native" Windows 11 när båda i slutändan använder samma kernel-driver (den i Windows).

WSL2 prestanda är typiskt >95 % av att köra "native", men fattar att en del vill undvika Windows av skäl som inte är tekniska.

Sen vad det gäller Intel och "bra GPGPU" stöd: det var ju inte jättebra för 10 år sedan och även idag behöver man minst en GPU från Brodwell för att OneAPI alls ska fungera, en från Ice Lake eller senare för att det ska fungera riktigt bra logiskt och en Arc för att det också ska prestera riktigt bra.

Men på modern iGPU lär Intel idag nog ha den mest kompletta OpenCL implementation man hittar. Detta då detta, ihop med SyCL, är en fundamental del av GPU-stödet i deras OneAPI.

Skrivet av Djhg2000:

Jag har dock även ett GeForce 1050 som jag använder för testning ibland, men varje gång hittills har det åkt ur maskinen när jag tröttnar på att deras binära drivare är så dålig. DKMS-fel orsakade av förändringar i senaste Linux-kärnan, krascher som inte går att felsöka när spåret slutar vid deras binära blob, trasigt Wayland som bara halvt fungerar för att NVIDIA satte sig på tvären och tvingade mjukvarustacken att ha stöd för just deras special-API istället för att följa standarden, etc. Jag har liksom bättre saker att göra än att försöka balansera korthuset som NVIDIA kallar en stabil drivrutin.

Har för mig jag läst något kring Wayland och Nvidias stöd för detta i deras propretära drivare (som är relativt nytt). Om jag inte missminner mig så är det i nuläget bara komplett från Turing och framåt (har bara testat med 2070 och 3090). Vad det nu var som saknades så skulle det fixas för äldre senare.

Skrivet av Djhg2000:

OpenCL på Intel var ett exempel på ett historiskt problem. Ett annat exempel är hur de var sena med att byta till Gallium-arkitekturen i Mesa. Det betyder inte att det är ett problem längre, det var ett exempel på att Intel inte heller har ett fläckfritt förflutna med Linux.

GPGPU på AMD har varit deras akilleshäl ett bra tag nu, men det har ganska liten påverkan på spel. Har inte följt utvecklingen där på några månader men deras idé med ROCm som mellanlager och tunna översättningslager mot vanligare API:er är en chansning som vi kanske inte har sett slutet av än.

Linux på skrivbordet är en nischmarknad, ur ett kommersiellt perspektiv är den irrelevant utanför Android. Så inte direkt konstigt att Intel, Nvidia och AMD prioriterar stödet för datacenter/servers. Är trist, framförallt under de 15-16 åren jag själv körde Linux på skrivbordet, men samtidigt förstår jag varför (de få gånger jag gjort native GUI saker i Linux tänker man bara WTF!, välj ett sätt och håll er till det).

AMD har ju också varit extremt sega på att stödja ROCm/HIP på konsument-serien och stödet för deras APU lades väl till bara för någon månad sedan?

Skrivet av Djhg2000:

Sedan kan man fortsätta stoppa huvudet i sanden och säga att NVIDIAs binära drivare fungerar bra i Linux, men då gör man NVIDIA en björntjänst. NVIDIA spelar inte efter samma regler som resten av marknaden, och den största anledningen till att folk anstränger sig för att för NVIDIA att fungera med Linux ändå är för att NVIDIA har en så stor del av Windows-marknaden.

Edit: Det är ju egentligen hela Mesa-stacken som NVIDIAs drivrutin har sönder, inte bara Intels drivrutin. Fixat i texten.

Håller inte med. Nvidias binära drivare är "bäst" i bemärkelsen: de implementerar Vulkan, OpenGL och OpenCL på ett väldigt korrekt sätt med ofta bättre prestanda (när man kör "native" och inte via Proton) än motsvarande på Windows.

Där de spelar i en egen liga är GPGPU. CUDA är bundet till deras GPUer, samtidigt som det är mer moget och i praktiken de-facto standard för GPGPU. Tyvärr verkar de andra bränt sig på OpenCL (som ställt mot CUDA inte är bra, det är allt för krångligt att använda) och stödet för Khronos SyCL (som är riktigt bra, här finns delar som är tekniskt bättre än CUDA) så är dåligt samarbete här.

Nvidias GPUer stödjer SyCL, fast p.g.a. att Intel, inte Nvidia, implementera stöd. Ändå rätt tänkt, Intel fattar att de behöver också stödja Nvidias GPU i OneAPI och Nvidia har massor med anledningar att inte hjälpa till (OneAPI verkar vara det enda Nvidia lite oroar sig för som konkurrent till CUDA).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Djhg2000:

Har inga bra erfarenheter av NVIDIA-kort och Linux. Det bästa är om man kan köra "nouveau"-drivaren som följer med i kerneln, men då tappar man mycket prestanda jämfört med den officiella drivrutinen (som för min del mest har fört med sig timmar av felsökning innan jag bara har gått tillbaka till "noveau").

Grafik från AMD har funkat väldigt bra sedan de bytte från en binär drivrutin (likt vad NVIDIA fortfarande kör) till AMDGPU-drivrutinen. Eftersom den är helt öppen och inkluderad i kerneln så går den aldrig sönder för att den hamnar ur synk med kernelversionen under systemuppdateringar, och den har mycket bra stöd för moderna API:er som Wayland och DMABUF.

Vidare fungerar AMDs kort bra om man ska använda VGA Passthrough till en virtuell maskin med Windows för att spela de få spel som inte funkar i Linux. NVIDIAs kort gav väldigt länge bara felkod 43 om man försökte använda dem i en virtuell maskin. Har hört något rykte om att det ska vara löst nu men har inget installerat NVIDIA-kort att testa det med.

Intel har rent allmänt utmärkt stöd i de flesta fall. Historiskt har de varit lite släpande på enstaka punkter, som OpenCL, men deras grafik har alltid fungerat (nysläppta kretsar har behövt absolut senaste kerneln men inte mer än så). Inte haft chansen att testa något av deras lösa kort men de borde fungera lika bra eftersom det är samma drivare som till senaste generationerna av integrerad grafik.

TL;DR: NVIDIA och Linux innebär mycket problem, använd ett kort från AMD (eller Intel) istället om du kan.

KVM passtrough med nvidia har fungerat i flera år. Kör själv ett 3090 sen två år i passtrough till en Windows burk som agerar spelserver med steamlink

Visa signatur

You think you know. What's to come. What you are. You haven't even begun.

Permalänk
Medlem
Skrivet av Yoshman:

OK, är jag med. Optimus är, och lär tyvärr förbli, ett rejält sorgebarn när det kommer till Linux-stöd. Som jag förstår finns ingen direkt standard för iGPU och dGPU interagerar med varandra, så går inte göra en fullt fungerande allmängiltig lösning.

Jodå, det finns. DRI PRIME är det vanligaste sättet att välja vilken GPU som ska göra de faktiska beräkningarna och fungerar med alla andra Mesa-kompatibla drivare, inklusive nouveau. Underliggande teknik som behövs är bland annat DMABUF för att dela minne mellan drivare, vilket NVIDIAs binära drivare inte har och sannolikt inte kan ha med en enkel DKMS-baserad drivare.

Skrivet av Yoshman:

Att du specifikt får problem med Mesa-stacken är inte heller speciellt konstigt. Vad är Mesa? Ju det är en, av potentiellt många, implementationer av OpenCL, OpenGL, Vulkan etc.

Det normala är ju att man behöver just en sådan implementation och för varje specifik applikation kan man bara använda just en implementation (om man inte specifikt skriver applikationen att kunna hantera flera).

Nvidias binära drivrutin har en helt separat implementation av alla dessa API som inte alls beror på Mesa, vilket är helt enligt hur dessa tekniker är tänkt att fungera. Resultatet i en iGPU/dGPU lösning där enda kretsen använder Mesa och den andra använder något annat lär då bli: en kommer inte fungera och det är "by design".

Visst, men det är skillnad på att ha en stack som är separat från Mesa och att ha en stack som inte bara är inkompatibel med Mesa utan även aktivt har sönder Mesa genom att skriva över kritiska filer med sina egna. Det gör att man inte kan hoppa mellan NVIDIAs egna och nouveau utan att installera om hela stacken mellan bytena. NVIDIA har försökt göra det möjligt att byta stack dynamiskt genom deras projekt "glvnd", men det har vad jag vet aldrig fungerat bra.

Skrivet av Yoshman:

Haft en enda laptop med Optimus under de år jag körde Linux (Ubuntu) som primärt desktop OS, blev "aldrig mer"... När jag skriver att Nvidia har bästa Linux native stöd är det helt i fallet "datorn har bara Nvidia GPU", vilket inkludera iGPU i deras Tegra-plattform.

Med mina senaste tre laptops (Thinkpad T530, W530 och P50) så har det varit NVIDIA Optimus för att det inte riktigt fanns något val. Genom åren har det dock hänt mycket med nouveau och med Wayland som sista pusselbiten för att abstrahera en CRTC (kort förklarat är det i praktiken en skärmutgång) till ett objekt som kan refereras till i en godtycklig render-pipeline, och genom DMABUF kan bilden även korsa minnesrymder. Med andra ord kan man numera utan problem använda sin integrerade Intel-GPU och slanga vidare bilden till en utgång på sin NVIDIA-GPU (naturligtvis förutsatt att man använder nouveau och har KMS aktiverat, vilket är standard i så gott som alla distributioner).

Så förutom den haltande prestandan med nouveau så fungerar det nästan klockrent. Allt man behöver göra är att sätta miljövariabeln "DRI_PRIME" till "1" (eller annan rendernod om man har fler än två) och starta programmet som ska använda NVIDIA-grafiken som rendernod. Om man alltid vill göra det för ett specifikt program kan man redigera .desktop-filen och lägga till "DRI_PRIME=1" i början på "Exec="-raden.

Externa skärmutgångar bara fungerar om man kör Wayland och många skrivbordsmiljöer kan hantera det i X11 men kanske med lite pyssel. Åter igen om man kör nouveau. Om man använder NVIDIAs drivare så har man tur om det fungerar överhuvudtaget.

Skrivet av Yoshman:

Positiva är att det ändå finns ett sätt att köra Linux på laptops med Optimus med riktigt bra stöd: WSL2. Nvidia har otroligt bra WSL2 drivare, är faktiskt lite komiskt att sitta på en Windows-dator och se hur t.ex. PyTorch/CUDA program kör betydligt snabbare under Ubuntu/WSL2 än "native" Windows 11 när båda i slutändan använder samma kernel-driver (den i Windows).

WSL2 prestanda är typiskt >95 % av att köra "native", men fattar att en del vill undvika Windows av skäl som inte är tekniska.

Fast att säga att man kör Linux när man använder WSL2 är bara tekniskt korrekt. Linux-kärnan där kör i en egen miljö ovanpå NT-kerneln med en drös kompatibilitetslager, det är långt från samma sak som att ge Linux kontroll över hårdvaran.

Skrivet av Yoshman:

Sen vad det gäller Intel och "bra GPGPU" stöd: det var ju inte jättebra för 10 år sedan och även idag behöver man minst en GPU från Brodwell för att OneAPI alls ska fungera, en från Ice Lake eller senare för att det ska fungera riktigt bra logiskt och en Arc för att det också ska prestera riktigt bra.

Men på modern iGPU lär Intel idag nog ha den mest kompletta OpenCL implementation man hittar. Detta då detta, ihop med SyCL, är en fundamental del av GPU-stödet i deras OneAPI.

Nu sitter jag ju med en Skylake i min laptop (ThinkPad P50) och mina stationära datorer kör både CPU och GPU från AMD, så vad som har hänt med Intel på nyare kretsar har jag inte upplevt själv.

Med det är ändå det som är charmen med Linux på en laptop; man behöver inte ha senaste hårdvaran för att saker ska kännas rimligt snabbt.

Skrivet av Yoshman:

Har för mig jag läst något kring Wayland och Nvidias stöd för detta i deras propretära drivare (som är relativt nytt). Om jag inte missminner mig så är det i nuläget bara komplett från Turing och framåt (har bara testat med 2070 och 3090). Vad det nu var som saknades så skulle det fixas för äldre senare.

I så fall hjälper det inte mig som inte sitter på något nyare än Pascal.

Skrivet av Yoshman:

Linux på skrivbordet är en nischmarknad, ur ett kommersiellt perspektiv är den irrelevant utanför Android. Så inte direkt konstigt att Intel, Nvidia och AMD prioriterar stödet för datacenter/servers. Är trist, framförallt under de 15-16 åren jag själv körde Linux på skrivbordet, men samtidigt förstår jag varför (de få gånger jag gjort native GUI saker i Linux tänker man bara WTF!, välj ett sätt och håll er till det).

AMD har ju också varit extremt sega på att stödja ROCm/HIP på konsument-serien och stödet för deras APU lades väl till bara för någon månad sedan?

Förutom att Steam Deck har rört om i soppan nu. Folk upptäcker att det ändå är en hel del spel som fungerar riktigt bra med Linux och att deras favoritwebbläsare för det mesta fungerar precis som i Windows.

Att det finns flera toolkits att välja på där GTK3, GTK4, Qt5, Qt6, wxWidgets, Elementary, etc. alla är vanliga är mer av en fördel snarare än ett problem. Jag är i allmänhet pessimistiskt inställd till "one size fits all"-mentaliteten och just den breda skaran av toolkits är ett ypperligt exempel på varför.

  • GTK3 är stabilt och välanvänt så det finns mycket dokumentation

  • GTK4 har stora underliggande förändringar som gör det snabbare, men som krävde nya koncept för vissa delar och att man rev ut några gamla

  • Qt5 är lik GTK3 gammalt och stabilt med mycket dokumentation, fast med annan struktur och med mindre krav på fönsterhanteraren som gör att program är mer portabla till andra plattformar som Windows, Mac och Android

  • Qt6 är likt GTK4 en större underliggande förändring med nya funktioner, fast mer bakåtkompatibelt med kunskaperna från Qt5

  • wxWidgets går sin egen väg och är huvudsakligen visuellt identisk på alla plattformar och då även i Windows

  • Elementary har även de gått sin egen väg och har större fokus på att vara snabbt och snyggt ner till varje pixel, på bekostnad av (visuell) kompatibilitet med andra skrivbordsmiljöer än Enlightenment

I detta fall är mångfalden av lösningar ett symptom på att det går att göra något bättre själv om man är missnöjd med vad som existerar. Det är inte ett fel att man inte alltid tycker som alla andra. I slutändan fungerar alla ovannämnda toolkits ovanpå både X11 och Wayland, så man kan blanda dem bäst man vill. Kanske vill man använda KDE Plasma men gillar videospelaren Totem från GNOME och då går det alldeles utmärkt att bara göra det.

Skrivet av Yoshman:

Håller inte med. Nvidias binära drivare är "bäst" i bemärkelsen: de implementerar Vulkan, OpenGL och OpenCL på ett väldigt korrekt sätt med ofta bättre prestanda (när man kör "native" och inte via Proton) än motsvarande på Windows.

Det är väl lite här som skon klämmer; även om de skulle ha den mest korrekta implementationen av API:er så är de sämt på att integrera med resten av ekosystemet. De har sina egna system för att hantera funktioner istället för att använda de existerande systemen, och EGLStreams är ett av väldigt många exempel på hur NVIDIA tror att ekosystemet kretsar runt dem.

Andra har redan förklarat EGLStreams bättre än vad jag kan göra i ett foruminlägg så jag länkar till denna artikel från en KDE-utvecklare istället.

Skrivet av Yoshman:

Där de spelar i en egen liga är GPGPU. CUDA är bundet till deras GPUer, samtidigt som det är mer moget och i praktiken de-facto standard för GPGPU. Tyvärr verkar de andra bränt sig på OpenCL (som ställt mot CUDA inte är bra, det är allt för krångligt att använda) och stödet för Khronos SyCL (som är riktigt bra, här finns delar som är tekniskt bättre än CUDA) så är dåligt samarbete här.

Nvidias GPUer stödjer SyCL, fast p.g.a. att Intel, inte Nvidia, implementera stöd. Ändå rätt tänkt, Intel fattar att de behöver också stödja Nvidias GPU i OneAPI och Nvidia har massor med anledningar att inte hjälpa till (OneAPI verkar vara det enda Nvidia lite oroar sig för som konkurrent till CUDA).

Vi kan iallafall vara överens om att GPGPU är en riktig röra även utanför Linux.

Men även här är det ju precis som du säger inte NVIDIA som arbetar med ekosystemet, utan ekosystemet som behöver arbeta med NVIDIA. Ponera att NVIDIA istället skulle ha samma marknadsandel som Matrox har, skulle de ha haft i närheten av samma svar på sitt egocentriska beteende då?

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Hedersmedlem
Skrivet av Djhg2000:

Med det är ändå det som är charmen med Linux på en laptop; man behöver inte ha senaste hårdvaran för att saker ska kännas rimligt snabbt.

Fast är det verkligen så stor skillnad numera? Icke-grafisk linux är förstås blixtsnabb (och oerhört stabil), men de stora grafiska miljöerna blir ju allt tyngre samtidigt som Windows (verkliga) systemkrav blir allt blygsammare (de har väl varit ungefär samma sedan Vista?). Hur gammal dator behöver man för att Windows skall kännas långsamt?

Permalänk
Medlem
Skrivet av Elgot:

Fast är det verkligen så stor skillnad numera? Icke-grafisk linux är förstås blixtsnabb (och oerhört stabil), men de stora grafiska miljöerna blir ju allt tyngre samtidigt som Windows (verkliga) systemkrav blir allt blygsammare (de har väl varit ungefär samma sedan Vista?). Hur gammal dator behöver man för att Windows skall kännas långsamt?

Jag använder nog inte Windows tillräckligt mycket längre för att ha en bra uppfattning om hur det skalar med hårdvaran, men Windows 10 på min ThinkPad P50 upplever jag som betydligt trögare än Debian med KDE Plasma 5. Det är inte så mycket konkret data jag har att gå på, utan mer en känsla av att jag spenderar mer tid på att vänta i Windows än i Debian.

Förmodligen är en bidragande faktor hur Windows har en tendens att abstrahera tunga arbetslaster till en generisk roterande markör i muspekaren, till skillnad från i KDE där till exempel att starta ett nytt program gör att programmets ikon har et animerat skuttande bredvid muspekaren istället. En annan möjlig faktor är att på mina maskiner har jag även CPU-last per logisk kärna som en stapelgraf i aktivitetsfältet som gör att jag omedelbart ser tunga arbetslaster och kan reagera därefter.

Något som inte bara är ett visuellt intryck är dock hur Windows 10 envisas med att plötsligt sätta igång med sina egna saker i tid och otid. Saker som att börja installera uppdateringar medan man väntar på att Steam uppdaterar klart ett spel, så hastigheten på nedladdningen går nedåt och systemet blir mindre responsivt. Har även hänt medan jag har arbetat i DaVinci Resolve så det totalt sabbar flödet i redigeringen utan en omedelbart uppenbar anledning.

På den tekniska fronten har ändå många skrivbordsmiljöer blivit riktigt snabba med Wayland. När man han utnyttja den ofta rätt kompetenta grafiken som sitter i moderna datorer för att rita fönster så känns det snabbare även om själva arbetslasterna i bakgrunden är ungefär lika långsamma som tidigare. Här går utvecklingen fortfarande ganska snabbt och det är numera möjligt att rita fönster genom Vulkan både i GTK4 och Qt6 om man har hårdvara som klarar det.

Visa signatur

Mjölnir: Ryzen 9 3900X | X570-I | Ballistix Sport 32GB | Powercolor RX 5500XT 4GB ITX | Kolink Sattelite
Server: Ryzen 5 1400 | X470-F | Ballistix Sport 24GB | ASUS HD 7790 2GB | Sapphire RX 470 8GB ME | NZXT Switch 810

Permalänk
Datavetare
Skrivet av Djhg2000:

Jodå, det finns. DRI PRIME är det vanligaste sättet att välja vilken GPU som ska göra de faktiska beräkningarna och fungerar med alla andra Mesa-kompatibla drivare, inklusive nouveau. Underliggande teknik som behövs är bland annat DMABUF för att dela minne mellan drivare, vilket NVIDIAs binära drivare inte har och sannolikt inte kan ha med en enkel DKMS-baserad drivare.

Fick kolla upp vad DRI Prime är. Det är ingen standard på det sätt jag menade, d.v.s. en standard för hur man på HW-nivå exponerar iGPU/dGPU integration. D.v.s. det är ingen motsvarighet till hur Linux-kärnan kan reda ut hur saker hänger ihop på t.ex. PCIe-bussen.

DRI Prime är ett API där man, tyvärr nog med en hel del reverse engineering försökt klämma in stöd för detta i ett ramverk högre nivåer kan använda. Positiva är väl att man kan få ordning på det med open source drivarna, man kan ju diktera standard. Och Nvidia har ju något att förhålla sig till om de bryr sig om att fixa stöd i deras binär-drivare.

Skrivet av Djhg2000:

Förutom att Steam Deck har rört om i soppan nu. Folk upptäcker att det ändå är en hel del spel som fungerar riktigt bra med Linux och att deras favoritwebbläsare för det mesta fungerar precis som i Windows.

Steam deck är för mig en parallel till Android och Chromebooks. Ja, det bygger på Linux men det är egentligen inte vad vi som kört Linux på server/skrivbordet menar.

Steam deck är inte heller något som egentligen tar spel mer till Linux, det är något som cementerar att man som spelutvecklare inte behöver bry sig om Linux som plattform. De som bryr sig om att spela på Linux får hålla till godo med att köra Windows-versionen via ett kompatibilitetslager. Det är långt enklare för spelutvecklaren, man slipper framförallt support på en liten plattform!

Skrivet av Djhg2000:

Att det finns flera toolkits att välja på där GTK3, GTK4, Qt5, Qt6, wxWidgets, Elementary, etc. alla är vanliga är mer av en fördel snarare än ett problem. Jag är i allmänhet pessimistiskt inställd till "one size fits all"-mentaliteten och just den breda skaran av toolkits är ett ypperligt exempel på varför.

  • GTK3 är stabilt och välanvänt så det finns mycket dokumentation

  • GTK4 har stora underliggande förändringar som gör det snabbare, men som krävde nya koncept för vissa delar och att man rev ut några gamla

  • Qt5 är lik GTK3 gammalt och stabilt med mycket dokumentation, fast med annan struktur och med mindre krav på fönsterhanteraren som gör att program är mer portabla till andra plattformar som Windows, Mac och Android

  • Qt6 är likt GTK4 en större underliggande förändring med nya funktioner, fast mer bakåtkompatibelt med kunskaperna från Qt5

  • wxWidgets går sin egen väg och är huvudsakligen visuellt identisk på alla plattformar och då även i Windows

  • Elementary har även de gått sin egen väg och har större fokus på att vara snabbt och snyggt ner till varje pixel, på bekostnad av (visuell) kompatibilitet med andra skrivbordsmiljöer än Enlightenment

Det där illustrerar precis vad problemet är med att designa GUI-applikationer på Linux är.

Som tur är finns idag en "lösning", vill man stödja Linux så skriv allt med Electron. Det har sina begränsningar, men det är ofta den enda affärsmässigt vettiga lösningen. Går att göra bra saker, se VS Code, Discord, Slack, m.fl.

Skrivet av Djhg2000:

Vi kan iallafall vara överens om att GPGPU är en riktig röra även utanför Linux.

Nej

Det är egentligen ingen röra på någon plattform, men kanske inte det resultat man helst vill se.

CUDA är de-facto standard på både Linux och Windows. Metal compute är vad som gäller på MacOS.

OpenCL finns kvar, men används mest för legacy och av flera som low-level driver till SyCL. Khronos SyCL är den enda verkliga moderna standard inom detta område med någon relevans, den används av Intel och ARM-tillverkarna men lider kraftigt av att de två största GPU-tillverkarna inte själva stödjer den (Intel gör Nvidia stödet och Heidelberg University gör AMD stödet).

Positiva är att för många områden, t.ex. AI via PyTorch/Tensorflow/Keras, behöver man inte bry sig speciellt mycket. Blender och kringliggande tekniker har liknande stöd. Det lager de flesta jobbar mot är på en högre abstraktion än dessa GPGPU-lager, så blir mest upp till varje GPU-tillverkare att fixa "drivers" för sitt stöd.

Men ja, lite röra är det ändå. T.ex. med NPU. Apple, Intel, Qualcomm och AMD har alla NPUer i sina senaste bärbara. Av dessa är det bara Intel som har någorlunda komplett stöd för deras NPU (som ironiskt nog är den på pappret sämsta kretsen). Qualcomm har visst stöd, Apple och AMD har i nuläget inget stöd alls i de populära ramverken (Apple stödjer bara NPU via sitt eget Accelerate och AMD bara via DirectML, ingen av dessa används i t.ex. PyTorch).

"Lösning" här är: kör Nvidia, det fungerar överallt. Metal compute fungerar i stort sätt överallt om man är på MacOS.

Skrivet av Djhg2000:

Men även här är det ju precis som du säger inte NVIDIA som arbetar med ekosystemet, utan ekosystemet som behöver arbeta med NVIDIA. Ponera att NVIDIA istället skulle ha samma marknadsandel som Matrox har, skulle de ha haft i närheten av samma svar på sitt egocentriska beteende då?

Frågan är väl ändå rätt irrelevant? Nvidia gör det i praktiken alla vinstdrivande föredrag drömmer om: de är så tekniskt överlägsna att de inte behöver följa standarder, de är i praktiken standarden inom GPGPU.

Är "utmanarna" som får/bör hålla sig till standarder.

Annat exempel är DirectX. Det är ingen "standard", det är vad Microsoft säger att det ska vara och alla som gör spel får i praktiken rätta in sig i ledet och designa efter det. Linux har fått välja "loser-lösningen" här och bygga ett kompatibilitetslager som säkerställer att man aldrig kommer kunna slå Windows på denna punkt.

MacOS har valt den rejält tunga uppförsbacken att köra sitt eget race, men här ser vi redan att när spel och spelmotorer faktiskt gör jobbet att köra på Metal så fungerar det riktigt bra. WoW, Baldurs Gate 3, Resident Evil 4 (alla är "native" både för CPU och GPU) är alla exempel på där Mac:ar, givet sin GPU-kapacitet, överpresterar mot iGPU på Windows.

Skrivet av Djhg2000:

På den tekniska fronten har ändå många skrivbordsmiljöer blivit riktigt snabba med Wayland. När man han utnyttja den ofta rätt kompetenta grafiken som sitter i moderna datorer för att rita fönster så känns det snabbare även om själva arbetslasterna i bakgrunden är ungefär lika långsamma som tidigare. Här går utvecklingen fortfarande ganska snabbt och det är numera möjligt att rita fönster genom Vulkan både i GTK4 och Qt6 om man har hårdvara som klarar det.

Av alla problem Linux har/har haft måste väl ändå prestanda i 2D-grafik vara en av de saker man inte haft något relevant problem med? Var då aldrig något jag tänkte på under de år (2002-2020) som Linux (initialt Debian, sen Gentoo för att stanna med Ubuntu sedan 2005) var mitt primära desktop OS.

Började resan med PIII, sedan ett gäng Phenom och på slutet Intel Core och därmed alltid Intels iGPU (i.e. inget kraftfullt på GPU-sidan).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer