Skrivet av anon185723:
Låter som att du vill hålla AMD ansvariga för varje Linux Distribution och fork. Linux är gigantisk och gratis för många människor. En gigantisk del av communityn drivs av många ideella medlemmar och vinstjagande företag. AMD har ingen rätt att bara ta full kontroll över varje distrubution och styra dess arbete.
Det jag säger är väl ändå raka motsatsen? Det man bör förvänta sig av "bra Linux-stöd" är att de så kallade stabila Enterprise-distrona får stöd, allt utöver det får nog räknas in i "klassledande Linux-stöd" vilket idag bara Intel uppfyller på något realistiskt sätt.
Nvidia garanterar bara stöd för aktuella Ubuntu LTS och motsvarande för RedHat och SuSE (använder folk fortfarande SuSE??), är inget mer än det jag förväntar mig från AMD.
Skrivet av anon185723:
Nu verkar dock AMD lyckats med att dag 1 att få Ubuntu att fungera bra enligt Wendel och många andra techreveiwers. Att en liten ny nystartad youtuber inte kan får det senaste grafikkortet att fungera day one på sin favorit fork av en distro är inget konstigt. Alla kan inte bara släppa sitt arbete och samarbete och uppdatera sina paket för att AMD eller Nvidia ber om det. De ansvariga utgivarna av varje distro väljer i sin egen takt om och när de vill släppa sin senaste version.
Tycker faktiskt Level1Tech borde ta sig en funderade hur vettigt deras video är, vad de gjort här är inte journalistik utan det är ren PR för AMD. Man väljer att enbart visa de saker som fungerar bra, nämner inte vad som krävs för att få ens det att fungera och på slutet nämner man i förbifarten att "visst finns det problem kvar" men inga konkreta exempel ges.
Det enda "amatörerna" på Linux för everyone försökte sig på var att använda en funktion, Vulkan, som enligt den officiella dokumentation ska fungera på AMDs GPUer sedan årtal tillbaka förutsatt att man har en driver för aktuell krets.
Finns en beskrivning hos L1T runt den "superenkla" processen att använda AMDs drivers ihop med Ubuntu 20.10, som alltså inte är en LTS version, senaste är 20.04, men är tydligen sannolikare att få igång sakerna på 20.10. Givet noteringar likt detta
If you download the AMD driver package from AMD.com, you’ll see many (MANY) packages as part of the download – LLVM, Xorg, dkms/kernel module implementation for Kernel 5.6 – I think, but not totally sure, this is a backport of some of the stuff in Kernel 5.10 for distros on “older” (haha, relative term) kernels, etc. This is why, if you try to use the amdgpu dkms on a 5.8.x kernel, you’ll get compile errors. And ultimately errors installing the amdgpu-dkms package.
vet jag inte. 90-talet vill ha tillbaka sin Linux-upplevelse... Nvidias jättekomplicerade process för 20.04LTS består i att köra
$ sudo ubuntu-drivers autoinstall
$ sudo reboot
alt. använda det grafiska verktyget för pakethantering och installera Nvidias driver där. För Intel räcker "sudo apt update && sudo apt dist-upgrade" för att få det senaste.
Skrivet av anon185723:
Nvidia har tyvärr inte varit något bättre än AMD på linux sidan. Det har varit så illa med Nvidia stöd på linux så att Linus torvalds själv gav Nvidia fingret. Men det spelar ingen roll eftersom det krävs samarbete från båda sidorna för att få hårdvara att fungera. Speciellt med alla Distrubutioner och forks som inte ger några pengar till utveckling.
Vill man ha en perfekt fungerande upplevelse med sitt operativsystem så får man betala som alla andra. Windows har växt och blivit så enormt tack vare microsofts otroliga stöd och arbete. Microsoft har satsat enormt mycket pengar och tid för att få alla drivrutinsutvecklare nöjda. Att kräva att få allt serverat gratis i ett operativsystem som man inte betalar för är lite väll oförskämt. Man får kort sagt så mycket stöd som man betalar för sitt operativsystem. Det enda Linux community har velat ha av varje grafikkortstillverkare är dokumentation och öppenkällkod. Så att linux communityn själva kan arbeta på drivrutiner i sin egna takt.
https://www.youtube.com/watch?v=_36yNWw_07g
Linux är större än någonsin. Givet att mobilerna tar en allt större del av folks datoranvändningen är ju Linux (då kärnan i Android är Linux) redan idag väsentligt större än Windows.
På backend undrar jag hur länge Windows kommer vara relevant. Allt fler som bygger lösningar som inte längre tar med Windows som ett OS man behöver bry sig om för själva driftsättning. Windows är fortfarande viktigt som desktop OS, så det kommer stödjas väldigt länge som ett OS där man kan utveckla produkter på, men i server-rummet och framförallt i molnet är Linux normen. Till och med i Azure står Linux för >50 % och i det klart större AWS totaldominerar Linux.
Värt att nämna här är att Nvidias GPU-drivrutiner är tillräckligt stabila för att Microsoft och Amazon vågar bygga GPGPU-delarna av sina moln på dessa. Tror de flesta totalt missat vad Torvalds klagade över (det är förövrigt 8 år sedan, kanske läge att släppa det?).
Klagomålet var inte att Nvidia hade dåligt stöd för sina kretsar i Linux, tvärtom hade de redan då bättre stöd är alla utom möjligt Intel. Problemet var modellen Nvidia använde för sitt drivrutinsstöd, out-of-tree-blob, rimmar väldigt illa med Torvalds vision och rätt annorlunda val runt drivrutinsmodell i Linux.
Linux har by-design inte en stabil ABI för drivrutiner, Torvalds anser att fördelarna med att man då kan fixa dåliga designbeslut utan att vara begränsad av ABI-kontrakt överväger nackdelarna med att modellen i praktiken omöjliggör det Windows, BSD, MacOS etc tillåter: en binär-blob med i teorin perfekt kompatibilitet mellan alla patch-versionen av ett OS.
Att Nvidia dels är så dominerande in GPUer och dels lyckades skapa väldigt bra propretära drivrutiner till Linux var ett slagträ för de som anser att även Linux bör gå till en stabil driver ABI-modell. Jag tror Torvalds val är det rätta här, andra OS har svårt att hänga med Linux i utvecklingen och en del kommer ned till att man just kan rätta till dåliga designbeslut på ett sätt andra bara kan göra när de släpper nya huvudversioner där man släpper bakåtkompatibilitet runt drivers. Nvidia är medveten om implikationerna i deras beslut, därför garanterar man bara stöd på en handfull distributioner och bara enstaka LTS-versioner av dessa.
Skrivet av Snubb1:
Jag har inget att invända mot ditt inlägg mer än att de som använder en LTS och måste ha en stabil arbetsstation troligtvis inte köper nytt grafikkort den dagen det släpps utan väntar till stödet har hunnit mogna oavsett om det gäller AMD eller Nvidia GPU:er.
För många arbetsstationer så testas eventuell ny hårdvara noggrant innan de kan rullas ut i skarp miljö.
Jag tror även att du är medveten om hur hårdvarustöd fungerar i linux miljön där kernel uppdateras för nytt hårdvarustöd och så även mesa mm för nytt grafikkortsstöd utöver det finns amdgpu-pro för det som behöver en certifierad drivrutin till sin arbetsstation.
Finns tyvärr fall där man har behov av väldigt ny HW även om man kör Linux. Skulle t.ex. aldrig köpa gammal HW till en bärbara och om jag jobbade professionellt med GPGPU vore det vansinne att välja något annat än Ampere idag. Endera får man lösa det som Nvidia, d.v.s. out-of-tree driver likt hur det fungerar på Windows, eller så gör man som Intel där man ser till att få in stöd för nya kretsar 6-12 månader innan släpp (GPU i Ice Lake fanns nästan ett år innan lansering, även Xe som är en helt ny mikroakritektur fanns i kernel.org kärnan långt innan släpp av första krets).
Finns ju inget motsatsförhållande mellan öppen källkod och certifierad drivrutin. AMD har trots begränsade resurser valt att jobba på flera olika drivrutinsstackar under Linux, det är både förvirrande för användarna och dåligt utnyttjande av resurser. Nvidia har en officiell stack, den propretära där man byter ut även saker som Mesa.
Intel har gjort två byten genom åren, men de har bara aktivt arbetet på den senaste stacken och för userland delen har de kört Mesa i princip sedan projektet startade i mitten på 90-talet. Intel har certifierat sina implementationer av OpenCL, OpenGL och Vulkan hos Khronos. AMD borde välja en av sina stackar och göra detsamma.
AMD lär också bestämma sig var deras strategi för GPGPU är, just nu är deras kort rätt oanvändbara där då de ger olika bud vad som gäller beroende på vem och när man frågar. För ca ett år sedan var ju OpenCL helt dött enligt dem HIP var framtiden och SYCL var inget man trodde på.
Nu verkar man insett att när Intel (och även andra som t.ex. Xilinx som AMD nu äger) pushar hårt för SYCL så är HIP nog rätt DoA givet att HIP är en CUDA-rip-off och kan därför aldrig bli bättre än ett någon utdaterad CUDA medan SYCL faktiskt ser ut att lyckas med det ingen lyckats innan: göra något som har flera signifikanta fördelar över CUDA!
Officiellt stödjer man ännu inte SYCL, hållningen är att man kan få stöd för SYCL via OpenCL. Det är till stor del sant, OpenCL är två saker: en runtime och en driver-backend. SYCL ersätter helt runtime-delen och som backend kan man använda OpenCL (vilket Intel officiellt använder i OneAPI), men finns även backends för att köra på Vulkan-compute-shaders, DX12-compute-shaders samt CUDA.
Såg lite mörkt ut för det projektet, Apple skapade OpenCL och mycket gick på sparlåga när de lämnade projektet för Metal-compute. Ovanpå visade Nvidia att OpenCL 2.x inte är möjligt att implementera på något vettigt sätt på dGPUer (så lite spännande att AMD hävdar fullt OpenCL 2.x stöd...), så det blev aldrig något OpenCL 2.x stöd för Nvidia. Khronos har sagt att Nvidia är korrekt, AMD och Intel är båda skylda då de pushat in saker i OpenCL 2.x då det var vettig för deras integrerade GPU-lösningar där GPU och CPU delar RAM.
Lösningen från Khronos blev OpenCL 3.0, feature-mässigt är det identiskt med OpenCL 1.2 fast med kravet att använda SPIR-V som indata till driver-delen av OpenCL. Att kräva SPIR-V är superbra, det gör att gränssnittet blir betydligt mindre tvetydigt jämfört med innan där drivers jobbade direkt med OpenCL-koden.
Ett problem man då löser är att många OpenCL program är inte skrivna mot specifikationen, de är skrivna mot en viss implementationer, typiskt AMDs då de länge var den enda tillverkaren med högpresterande OpenCL. Har rättat flera OpenCL-kernels som Phoronix använder, de fungerade på AMD men inte Intel. I 100 % av fallen var orsaken att OpenCL koden innehöll saker som kompilerade med AMDs driver men de följde inte specifikationen vilket Intels driver noterade och gav ett fel.
Med SPIR-V är det Khronos som typiskt tillhandahåller kompilatorn. Så översättningen från OpenCL/SYCL eller vad man nu använder utförs av en och samma kompilator avsett GPU, utdata är SPIR-V (en form av virtuell maskinkod). Drivers översätter sedan SPIR-V till GPU-specifik maskinkod som del av köra programmet -> långt bättre kompatibilitet + långt mindre dubbeljobb då GPU-drivers inte behöver en full kompilator.
Nvidia (Jensen) har gjort en del uttalanden om OneAPI, tror de är oroande över att deras totala dominas på GPGPU-scenen kan komma till ett slut. Runtime-delen av OpenCL är ett tågvrak jämfört med CUDA, enda vettiga konkurrent tidigare var Metal-compute men det är bundet till MacOS/iOS.
SYCL är riktigt trevligt. Bl.a. då det är ren ISO C++17/20, inga extensioner som är fallet i både CUDA och OpenCL. Man har också kikat på saker som ofta ställer till det för folk i CUDA, t.ex. optimal schemaläggning av flera kernels där utdata i vissa är indata i andra. Man måste hantera beroenden manuellt i CUDA/OpenCL, något som gör det utmanande att få en optimal lösning, SYCL är designat så man kan bygga en DAG av ingående kernels vid kompileringen och automatiskt generera optimal schemaläggning!
Kuriosa om OpenCL
