AMD släpper drivrutinen Radeon Software Adrenalin 2020 Edition

CrossFire

Var någonstans kan man aktivera flera kort stöd i spel?

inte ens i sökrutan kan jag hitta inställningarna. någon som hittat?

Skrivet av Yoshman:

Svårt att se hur man kan jämföra vad som krävs för RDNA korten idag med hur det någonsin sett ut för Skylake. Skylake släpptes hösten 2015, i samband med det fick aktuell LTS version för Ubuntu, då 14.04 (specifikt 14.04.4), officiellt stöd för iGPU i Skylake. Det är relevant om man använder Linux professionellt då jag har svårt att se något företag köra Linux och inte hålla sig till någon form av LTS version (på mitt jobb för man välja mellan Windows 10 och Ubuntu 18.04 LTS).

Samma sak gäller Ice Lake och 18.04 LTS. Plattformen fanns inte april 2018, men det lades till i en 18.04.x senare release så om man tar det senaste idag finns stödet. Det är så det borde fungera, man ska inte behöva bygga en egen kärna och egna bibliotek.

Förhoppningsvis kommer det in out-of-the-box stöd för RDNA i Ubuntu 20.04LTS. Knappast jämförbart när en har stöd direkt vid release i LTS-versioner (utgår från att motsvarande även hände om man kör t.ex. Redhat) och den andra kanske få out-of-the-box stöd ungefär ett år efter att produkten nådde marknaden.

Nu får vi ha i åtanke att Ubuntu sedan version 14.04 LTS har "HWE stack" (HardWare Enablement stack) för att lösa kompatibilitet med nyare hårdvara, vilket består av kernel och Mesa från en senare version av Ubuntu. Så när de säger att Skylake fungerar i 14.04 LTS med HWE som i blogginlägget du länkade betyder det att det fungerar med backportad kod från Ubuntu 15.10. Enligt samma princip kommer även Ubuntu 18.04 LTS att få stöd för RDNA när det väl kommer med HWE.

Kommer dock själv ihåg vilket pyssel det var att få igång grafiken från Skylake i Debian Jessie runt början av 2016, det behövdes bleeding edge av både kernel och Mesa för att få ett någorlunda stabilt system. Dessa behövde några uppdateringar till innan systemet verkligen var redo för dagligt bruk och det sänkte verkligen mitt intryck av Intel.

Skrivet av Yoshman:

Vad det gäller Nvidia. Hur är det på något sätt relevant för de som använder GPUn professionellt huruvida stöden levereras i form av prioritera binärer eller källkoden ligger på github? Nvidias Linux-stöd är just nu klassledande (för GPGPU på servers, föredrar Intel som för desktop-grafik), med undantag för OpenCL där Intel är ensamma om certifierat stöd för OpenCL 2.1, AMD och Nvidia är fast på 1.2. Fast OpenCL är i praktiken en återvändsgränd, CUDA är (tyvärr då det är låst till Nvidia) de-facto standard inom allt fler GPGPU-områden och Nvidias CUDA-tool-chain är otroligt välputsad (och med officiellt stöd för både Windows och flertalet Linux-distron, bl.a. Ubuntus LTS:er).

Det är relevant eftersom utvecklarna blir låsta av NVIDIA. Jag har hört om flera utvecklare som har slagit i en vägg när de ska debugga sin mjukvara eftersom de inte kan fixa fel i drivrutinen när de hittar dem. Valve har ju på egen hand patchat både Intel och AMDs drivrutiner i Linux medan de behöver övertyga NVIDIA innan något händer med deras drivrutin. Croteam har använt AMDs drivare för experiment med Vulkan och det har enligt dem själva öppnat en helt ny värld.

Men särskilt på senare tid har jag hört från flera håll hur utvecklare av ingenjörsverktyg bara blir mer och mer irriterade på NVIDIA när de arbetar med CUDA. Problem som NVIDIA vägrar fixa leder till ett ständigt växande berg av workarounds och tuggummilösningar.

CUDA är dock inte låst till NVIDIA i praktiken, genom ROCm (som dessutom har öppen källkod) finns det officiellt stöd för CUDA v8 på AMD-kort. Förhoppningen med ROCm är dock att få stöd för modernare version av OpenCL, och med stöd för OpenCL C 2.0 är de ändå en bit på väg. Mesa har ju visserligen också stöd för OpenCL 1.2 men den implementationen är mycket buggigare än den i ROCm.

FPS overlay fungerar nu via adrenalin för dom som har väntat: Performance / Metric overlay , enable

Senast redigerat 2019-12-15 04:50

Lustigt! jag var med om två svartskärmar i morse.
Skedde i Chrome, FF verkar fungerar bättre.
Också sett att en service "Origin Webbhelper" krånglat, satt Origin till att inte starta automatiskt.

Skrivet av Djhg2000:

Nu får vi ha i åtanke att Ubuntu sedan version 14.04 LTS har "HWE stack" (HardWare Enablement stack) för att lösa kompatibilitet med nyare hårdvara, vilket består av kernel och Mesa från en senare version av Ubuntu. Så när de säger att Skylake fungerar i 14.04 LTS med HWE som i blogginlägget du länkade betyder det att det fungerar med backportad kod från Ubuntu 15.10. Enligt samma princip kommer även Ubuntu 18.04 LTS att få stöd för RDNA när det väl kommer med HWE.

Kommer dock själv ihåg vilket pyssel det var att få igång grafiken från Skylake i Debian Jessie runt början av 2016, det behövdes bleeding edge av både kernel och Mesa för att få ett någorlunda stabilt system. Dessa behövde några uppdateringar till innan systemet verkligen var redo för dagligt bruk och det sänkte verkligen mitt intryck av Intel.

Vad som brukade strula en hel del var bärbara med Intel+Nvidia GPU (Optimus), det strulade även på Ubuntu om man backar 6-7 år. Idag verkar man fått även den kombinationen om man håller sig till de stora LTS-varianterna, men kan garanterat variera med laptop-modell.

Testade precis en Ryzen 3750H + Nvidia 1660Ti bärbar. Även där verkade dual-GPU stödet fungerar fint på Ubuntu 19.10 (APU varianten av Vega 10 strulade på 18.04). Tyvärr var OpenCL helt trasigt på APU Vega 10, det var även fallet under Windows 10 och tydligen ett känt problem (fungerade dock bra med 1660Ti, har läst att man med lite manuellt pillade ska kunna få igång OpenCL på APU Vega). Både under Windows 10 och Ubuntu 19.10 hade Vega 10 problem med strömsparfunktioner. Tyvärr hade datorn jag testade samma begränsning som t.ex. 15" Surface Laptop 3, AMDs generella drivare går inte att installera så man är fast med det som levereras av datortillverkaren.

"Unfortunately, the AMD driver can’t be updated from AMD directly, and instead will be released by Microsoft."

Skrivet av Djhg2000:

Det är relevant eftersom utvecklarna blir låsta av NVIDIA. Jag har hört om flera utvecklare som har slagit i en vägg när de ska debugga sin mjukvara eftersom de inte kan fixa fel i drivrutinen när de hittar dem. Valve har ju på egen hand patchat både Intel och AMDs drivrutiner i Linux medan de behöver övertyga NVIDIA innan något händer med deras drivrutin. Croteam har använt AMDs drivare för experiment med Vulkan och det har enligt dem själva öppnat en helt ny värld.

Men särskilt på senare tid har jag hört från flera håll hur utvecklare av ingenjörsverktyg bara blir mer och mer irriterade på NVIDIA när de arbetar med CUDA. Problem som NVIDIA vägrar fixa leder till ett ständigt växande berg av workarounds och tuggummilösningar.

Då verkar vi ha lyssnat på väldigt olika delar av marknaden. Vad jag kan se i presentationer kring GPGPU, från utveckling av GPGPU-stöd i applikationer och egen erfarenhet från att utveckla GPGPU-kod är att Nvidias försprång bara ökar just då deras verktyg och support för CUDA är milsvid bättre än vad någon annan har just nu. Det är trist då man blir låst till Nvidia, men något man helt enkelt får leva med när målet är att lösa aktuella problem idag.

Sen kan ju min och många andras bild vara annorlunda då en pragmatisk hållning och betyder att man får "offra" sig lite och hålla sig till de smaker av Linux som faktiskt är tänkta för professionellt bruk. LTS versionerna av Ubuntu har officiellt stöd från Nvidia, "trots" binärdrivers (märkligt att det är så konstigt på Linux när det är en självklarhet på Windows och MacOS) har det fungerat lysande för egen del.

Skrivet av Djhg2000:

CUDA är dock inte låst till NVIDIA i praktiken, genom ROCm (som dessutom har öppen källkod) finns det officiellt stöd för CUDA v8 på AMD-kort. Förhoppningen med ROCm är dock att få stöd för modernare version av OpenCL, och med stöd för OpenCL C 2.0 är de ändå en bit på väg. Mesa har ju visserligen också stöd för OpenCL 1.2 men den implementationen är mycket buggigare än den i ROCm.

Var faktiskt väldigt förvånad över svaret från AMD-gänget på SweC 20-års firande: de sa rakt ut att OpenCL inte längre är en prioritet, istället rekommenderas just CUDA ihop med ROCm. Detta är något som observerats av projekt, t.ex. PyTorch där man skiter i OpenCL stöd då AMD är på väg bort från det och för just det området har Intel specialdesignade ramverk för deras produkter som är mer effektiva.

CUDA är vad Nvidia bestämmer sig för att det ska vara, det är också helt designat runt Nvidias GPU-design. Primärt är det en teknik för att köra en variant av C och C++ på grafikkort, så självklart är det möjligt att skapa något likt vad AMD gjort där de kompilerar CUDA-program till något som kan köras på GCN och RDNA.

Så ställ dig frågan själv: om du bygger ett kommersiellt system där CUDA är en kritiskt komponent, skulle då på något rimligt sätt kunna motivera att köra detta på något annat än Nvida GPUer givet ovan?

Sedan har inte AMD en CUDA-kompilator, vad man har är verktyg som kan göra en översättning (transpile) av CUDA kod till ett AMD tillverkat GPGPU ramverk (som är extremt nära CUDA i funktion). Ramverk gör det möjligt att skriva mot en specifikation som väldigt effektivt kan köras mot CUDA på Nvidia GPUer och mot ROCm API på AMD, problemet är att man just nu inte har en lösning för att köra på Intel och alla ARM-varianter + det är inte helt automatisk översättning och just nu skrivs det mesta direkt mot CUDA.

TL;DR av detta är att AMD stödjer inte CUDA, man har verktyg för att ta CUDA och konvertera det till något som går att köra på en AMD GPU. AMDs HIP-ramverk är helt rätt tänkt, men tror ändå just det spåret är DoA p.g.a. att AMD helt enkelt inte har resurser nog att driva något sådant på egen hand.

Ställde även frågan om AMD jobbar med SYCL, en öppen standard som är en långt bättre 1:1 mappning mot CUDA än OpenCL. Intel, Xlinx, m..fl. implementerar SYCL med en OpenCL back-end men det är inte ett måste, AMD skulle kunna köra deras ROCm API direkt. Märkligt nog verkar AMD inte jobba med SYCL för tillfället, största intresset för detta verkar komma från ARM-gänget.

Senast redigerat 2019-12-15 12:09
Skrivet av Yoshman:

Vad som brukade strula en hel del var bärbara med Intel+Nvidia GPU (Optimus), det strulade även på Ubuntu om man backar 6-7 år. Idag verkar man fått även den kombinationen om man håller sig till de stora LTS-varianterna, men kan garanterat variera med laptop-modell.

Testade precis en Ryzen 3750H + Nvidia 1660Ti bärbar. Även där verkade dual-GPU stödet fungerar fint på Ubuntu 19.10 (APU varianten av Vega 10 strulade på 18.04). Tyvärr var OpenCL helt trasigt på APU Vega 10, det var även fallet under Windows 10 och tydligen ett känt problem (fungerade dock bra med 1660Ti, har läst att man med lite manuellt pillade ska kunna få igång OpenCL på APU Vega). Både under Windows 10 och Ubuntu 19.10 hade Vega 10 problem med strömsparfunktioner. Tyvärr hade datorn jag testade samma begränsning som t.ex. 15" Surface Laptop 3, AMDs generella drivare går inte att installera så man är fast med det som levereras av datortillverkaren.

"Unfortunately, the AMD driver can’t be updated from AMD directly, and instead will be released by Microsoft."

Optimus är ett helt eget kapitel av flerlagers möglig skräpkod i Linux. På min Lenovo T530 från 2012 har jag valen (1) fungerade strömsparläge och Wayland utan ljud över DP/HDMI och prestanda som motsvarar Intels integrerade grafik med Nouveau, (2) vara låst till gammal kernel och krasch ner i strömsparläge med NVIDIAs egna drivrutin, eller (3) Ubuntu LTS. Jag är egentligen inte nöjd med någon av alternativen men senaste månaden har jag behövt bråka med NVIDIAs drivrutin och det är ju nästan så att man blir gråhårig av alla dumma små problem som fortfarande finns kvar 7 år efter datorns tillverkningsdatum.

Hade datorn inte varit så trevlig i övrigt hade den ersatts med något utan NVIDIA för många år sedan. Det är egentligen ett helt tangentiellt diskussionsämne men Lenovo har verkligen tappat riktningen med sin ThinkPad T-serie och efter att ha varit lojal ThinkPad-användare väldigt länge har jag till slut tappat hoppet och börjat snegla på Dell Latitude istället.

Mina direkta erfarenheter av Vega 11 sträcker sig däremot inte till Windows 10 mer än några timmar för testning, så jag har svårt att uttala mig om något där annat än att drivrutinen inte hade några uppenbara problem med Solid Edge ST9, KeyShot 6 eller PlanetSide 2 (innan DX11-patchen om det är relevant). Från vad jag har hört ligger Vega 10 sämre till än Vega 11 men den enda jag känner med Vega 10 och Linux verkar vara nöjd numera, så jag antar att situationen har förbättrats. Vega 11 är riktigt stabil för mig i Debian Sid.

Skrivet av Yoshman:

Då verkar vi ha lyssnat på väldigt olika delar av marknaden. Vad jag kan se i presentationer kring GPGPU, från utveckling av GPGPU-stöd i applikationer och egen erfarenhet från att utveckla GPGPU-kod är att Nvidias försprång bara ökar just då deras verktyg och support för CUDA är milsvid bättre än vad någon annan har just nu. Det är trist då man blir låst till Nvidia, men något man helt enkelt får leva med när målet är att lösa aktuella problem idag.

Sen kan ju min och många andras bild vara annorlunda då en pragmatisk hållning och betyder att man får "offra" sig lite och hålla sig till de smaker av Linux som faktiskt är tänkta för professionellt bruk. LTS versionerna av Ubuntu har officiellt stöd från Nvidia, "trots" binärdrivers (märkligt att det är så konstigt på Linux när det är en självklarhet på Windows och MacOS) har det fungerat lysande för egen del.

En del av den starkaste kritiken jag har hört mot CUDA är genom en gemensam vän till utvecklingsledaren av en inom fältet stor simuleringsmjukvara. Kan tyvärr inte vara mer specifik än så utan att avslöja vilken det är, men han verkar vara nära stadiet att leta efter en ursäkt att motivera för sin chef att göra om beräkningskoden till något annat än CUDA. Huvudanledningen åter igen hur NVIDIA vägrar anstränga sig för att fixa de buggar som han bråkar med och att han inte kan fixa dem själv utan drivrutinens källkod.

En stor del med problematiken i en färdigkompilerad drivare är ju just att du inte kan fixa problemen själv. Om du dessutom kan fixa samma problem för andra stärks även plattformen som helhet, så det ligger i hårdvarutillverkarens intresse att ha en öppen drivrutin. Men om det faktum att din mjukvaruprodukt fungerar enbart för att NVIDIA fortsätter uppdatera drivrutinen till att fungera med din utvecklingsplatform (till exempel Ubuntu LTS) kan NVIDIA likaså bestämma sig för att dina beräkningskort plötsligt är för gamla och sluta uppdatera drivrutinen. Med en öppen drivare kan och har drivrutiner hållits vid liv långt efter att korten ansetts uråldriga, se till exempel Quadro2 EX eller FireGL 7800. Inget vettigt företag skulle köpa in dessa kort idag men trots det kan du köra en modern distro tillsammans med dem.

En trevlig liten bonus med öppen drivare är att gammal hårdvara kan få stöd för moderna funktioner som inte fanns när hårdvaran tillverkades. Här finns det få uppenbara exempel men RADV gav support för Vulkan med GCN 1.0 och nyare innan AMD hann släppa AMDVLK för samma hårdvara. R600g ger kort ur Radeon HD 5800/6900 stöd för hårdvaruaccelererad OpenGL 4.5. Nouveau ger många NVIDIA-kort stöd för VAAPI utan att behöva gå via VDPAU. Det låter kanske inte så imponerande men det demonstrerar hur öppna drivare inte bara slutar utvecklas när tillverkarens intresse svalnar och produkterna når EOL.

Skrivet av Yoshman:

Var faktiskt väldigt förvånad över svaret från AMD-gänget på SweC 20-års firande: de sa rakt ut att OpenCL inte längre är en prioritet, istället rekommenderas just CUDA ihop med ROCm. Detta är något som observerats av projekt, t.ex. PyTorch där man skiter i OpenCL stöd då AMD är på väg bort från det och för just det området har Intel specialdesignade ramverk för deras produkter som är mer effektiva.

CUDA är vad Nvidia bestämmer sig för att det ska vara, det är också helt designat runt Nvidias GPU-design. Primärt är det en teknik för att köra en variant av C och C++ på grafikkort, så självklart är det möjligt att skapa något likt vad AMD gjort där de kompilerar CUDA-program till något som kan köras på GCN och RDNA.

Så ställ dig frågan själv: om du bygger ett kommersiellt system där CUDA är en kritiskt komponent, skulle då på något rimligt sätt kunna motivera att köra detta på något annat än Nvida GPUer givet ovan?

Sedan har inte AMD en CUDA-kompilator, vad man har är verktyg som kan göra en översättning (transpile) av CUDA kod till ett AMD tillverkat GPGPU ramverk (som är extremt nära CUDA i funktion). Ramverk gör det möjligt att skriva mot en specifikation som väldigt effektivt kan köras mot CUDA på Nvidia GPUer och mot ROCm API på AMD, problemet är att man just nu inte har en lösning för att köra på Intel och alla ARM-varianter + det är inte helt automatisk översättning och just nu skrivs det mesta direkt mot CUDA.

TL;DR av detta är att AMD stödjer inte CUDA, man har verktyg för att ta CUDA och konvertera det till något som går att köra på en AMD GPU. AMDs HIP-ramverk är helt rätt tänkt, men tror ändå just det spåret är DoA p.g.a. att AMD helt enkelt inte har resurser nog att driva något sådant på egen hand.

Ställde även frågan om AMD jobbar med SYCL, en öppen standard som är en långt bättre 1:1 mappning mot CUDA än OpenCL. Intel, Xlinx, m..fl. implementerar SYCL med en OpenCL back-end men det är inte ett måste, AMD skulle kunna köra deras ROCm API direkt. Märkligt nog verkar AMD inte jobba med SYCL för tillfället, största intresset för detta verkar komma från ARM-gänget.

Nu var jag lite otydlig i mitt inlägg, det var alltså min förhoppning att stöden för OpenCL skulle förbättras med tiden. Om AMD lyckas få ihop en kompilator för CUDA eller om ROCm fungerar som ersättare för OpenCL på fler plattformar än AMD skulle de också kunna vara lösningar. SYCL har jag faktiskt inget minne av att jag har hört om förut (men har sannolikt läst om SYCL på Phoronix) så intresset från marknaden verkar ha varit ganska lågt.

Men om det finns en öppen implementation av CUDA för AMD är det nog ganska lätt att motivera en evaluering av stödet om det betyder att man inte längre sitter i NVIDIAs järngrepp. Buggar som hittas i CUDA-implementationen kan då åtgärdas på plats allteftersom de upptäcks och NVIDIA tappar kontrollen över CUDAs utveckling. Kanske ser vi en utökning av CUDA på ROCm som innehåller de buggfixar NVIDIA inte vill implementera, men under ett nytt namn (kanske till och med "GPGPU Open Unified Device Architecture" )?

Vad jag kan se är en öppen kompilator sista steget innan NVIDIA faktiskt börjar tappa kontrollen över CUDA. Det kommer inte att gå fort i början men när proppen lossnar är NVIDIA ute på hal is. Det är ironiskt nog samma läxa som 3dfx vägrade ta till sig av och NVIDIA tycks upprepa den gång på gång; proprietära APIer fungerar bara så länge marknaden spelar med (3D Vision, PhysX, RTX, etc.).

Skrivet av Djhg2000:

Optimus är ett helt eget kapitel av flerlagers möglig skräpkod i Linux. På min Lenovo T530 från 2012 har jag valen (1) fungerade strömsparläge och Wayland utan ljud över DP/HDMI och prestanda som motsvarar Intels integrerade grafik med Nouveau, (2) vara låst till gammal kernel och krasch ner i strömsparläge med NVIDIAs egna drivrutin, eller (3) Ubuntu LTS. Jag är egentligen inte nöjd med någon av alternativen men senaste månaden har jag behövt bråka med NVIDIAs drivrutin och det är ju nästan så att man blir gråhårig av alla dumma små problem som fortfarande finns kvar 7 år efter datorns tillverkningsdatum.

Hade datorn inte varit så trevlig i övrigt hade den ersatts med något utan NVIDIA för många år sedan. Det är egentligen ett helt tangentiellt diskussionsämne men Lenovo har verkligen tappat riktningen med sin ThinkPad T-serie och efter att ha varit lojal ThinkPad-användare väldigt länge har jag till slut tappat hoppet och börjat snegla på Dell Latitude istället.

Mina direkta erfarenheter av Vega 11 sträcker sig däremot inte till Windows 10 mer än några timmar för testning, så jag har svårt att uttala mig om något där annat än att drivrutinen inte hade några uppenbara problem med Solid Edge ST9, KeyShot 6 eller PlanetSide 2 (innan DX11-patchen om det är relevant). Från vad jag har hört ligger Vega 10 sämre till än Vega 11 men den enda jag känner med Vega 10 och Linux verkar vara nöjd numera, så jag antar att situationen har förbättrats. Vega 11 är riktigt stabil för mig i Debian Sid.

Här för man göra ett val: vara kärring mot strömmen och propsa på att köra just sin favoritdistro, eller följa med majoriteten och få något som fungerar väldigt nära 100 % av fallen.

Själv har jag varken tid eller ork att pilla med datorn. Den ska fungerar och kör whatever som fungerar bäst, vilket sedan 2006 varit Ubuntu. Kraven är självklart olika, för mig är Windows 10 rätt oanvändbart i jobbet men har full förståelse för att det är ett relativt unikt läge och hade Windows fungerat hade det varit ett självklart val.

Skrivet av Djhg2000:

En del av den starkaste kritiken jag har hört mot CUDA är genom en gemensam vän till utvecklingsledaren av en inom fältet stor simuleringsmjukvara. Kan tyvärr inte vara mer specifik än så utan att avslöja vilken det är, men han verkar vara nära stadiet att leta efter en ursäkt att motivera för sin chef att göra om beräkningskoden till något annat än CUDA. Huvudanledningen åter igen hur NVIDIA vägrar anstränga sig för att fixa de buggar som han bråkar med och att han inte kan fixa dem själv utan drivrutinens källkod.

En stor del med problematiken i en färdigkompilerad drivare är ju just att du inte kan fixa problemen själv. Om du dessutom kan fixa samma problem för andra stärks även plattformen som helhet, så det ligger i hårdvarutillverkarens intresse att ha en öppen drivrutin. Men om det faktum att din mjukvaruprodukt fungerar enbart för att NVIDIA fortsätter uppdatera drivrutinen till att fungera med din utvecklingsplatform (till exempel Ubuntu LTS) kan NVIDIA likaså bestämma sig för att dina beräkningskort plötsligt är för gamla och sluta uppdatera drivrutinen. Med en öppen drivare kan och har drivrutiner hållits vid liv långt efter att korten ansetts uråldriga, se till exempel Quadro2 EX eller FireGL 7800. Inget vettigt företag skulle köpa in dessa kort idag men trots det kan du köra en modern distro tillsammans med dem.

En trevlig liten bonus med öppen drivare är att gammal hårdvara kan få stöd för moderna funktioner som inte fanns när hårdvaran tillverkades. Här finns det få uppenbara exempel men RADV gav support för Vulkan med GCN 1.0 och nyare innan AMD hann släppa AMDVLK för samma hårdvara. R600g ger kort ur Radeon HD 5800/6900 stöd för hårdvaruaccelererad OpenGL 4.5. Nouveau ger många NVIDIA-kort stöd för VAAPI utan att behöva gå via VDPAU. Det låter kanske inte så imponerande men det demonstrerar hur öppna drivare inte bara slutar utvecklas när tillverkarens intresse svalnar och produkterna når EOL.

Jobbar man professionellt med GPGPU lär det sista vara ett totalt icke-problem. Är inte ekonomiskt försvarbart att sitta på gammal junk. Känns också som du kanske extrapolerar generella problem med CUDA lite väl mycket från en enda punkt. Ta utbildning inom GPGPU, CUDA är ju mer självklart där än vad Python numera är som första programmeringsspråk.

Skrivet av Djhg2000:

Nu var jag lite otydlig i mitt inlägg, det var alltså min förhoppning att stöden för OpenCL skulle förbättras med tiden. Om AMD lyckas få ihop en kompilator för CUDA eller om ROCm fungerar som ersättare för OpenCL på fler plattformar än AMD skulle de också kunna vara lösningar. SYCL har jag faktiskt inget minne av att jag har hört om förut (men har sannolikt läst om SYCL på Phoronix) så intresset från marknaden verkar ha varit ganska lågt.

Men om det finns en öppen implementation av CUDA för AMD är det nog ganska lätt att motivera en evaluering av stödet om det betyder att man inte längre sitter i NVIDIAs järngrepp. Buggar som hittas i CUDA-implementationen kan då åtgärdas på plats allteftersom de upptäcks och NVIDIA tappar kontrollen över CUDAs utveckling. Kanske ser vi en utökning av CUDA på ROCm som innehåller de buggfixar NVIDIA inte vill implementera, men under ett nytt namn (kanske till och med "GPGPU Open Unified Device Architecture" )?

Vad jag kan se är en öppen kompilator sista steget innan NVIDIA faktiskt börjar tappa kontrollen över CUDA. Det kommer inte att gå fort i början men när proppen lossnar är NVIDIA ute på hal is. Det är ironiskt nog samma läxa som 3dfx vägrade ta till sig av och NVIDIA tycks upprepa den gång på gång; proprietära APIer fungerar bara så länge marknaden spelar med (3D Vision, PhysX, RTX, etc.).

Att AMD inte pushar SYCL är definitivt ett problem för det initiativet då de just nu är enda realistiska datacenter-alternativet till Nvidia. Får se vad som händer när Intels dGPUer hittar ut.

Svårt att se hur en öppen kompilator för CUDA kommer göra något att än bara stärka Nvidias position. Det är ju inte alls jämförbart med Glide på 3Dfx tiden. 3Dfx var överlägsna så länge som spelen använde Glide då de wrappers som fanns sög. 3Dfx hängde inte med när DX blev standard.

I CUDA fallet verkar ju övriga marknaden kasta in handduken, d.v.s. som om Glide vunnit och alla andra varit tvungna att försöka hänga på med olika wrappers.

PhysX är ju en standardfiness i bl.a. UE. Visst, blev ingen kommersiell succé och inget som längre körs på GPUer. Men det beror mer på att just fysik är ett exempel på något som bättre hanteras med SIMD på CPU än med GPGPU.

Var RTX tar vägen vet vi väl ännu inte? Det har redan gjort succé inom renderingsvärlden (OptiX). Till och med Blender stödjer ju redan detta. Tyvärr är OptiX, till skillnad från DXR, bundet till Nvidia så ännu ett exempel på där Nvidia drar ifrån de övriga
Spel kommer köra raytracing framöver, men borde inte förvåna någon att den första generationen som stödjer DXR kommer vara för seg och för begränsade när det väl slår igenom på bred front. Exakt samma har varit fallet för alla större teknikskiften, t.ex. när HW T&L kom.

Senast redigerat 2019-12-15 21:27
Skrivet av Yoshman:

Här verkar det som du för göra samma val som många andra: vara kärring mot strömmen och propsa på att köra just din favorit distro, eller följa med majoriteten och få något som fungerar väldigt nära 100 % av fallen.

Själv har jag varken tid eller ork att pilla med datorn. Den ska fungerar och kör whatever som fungerar bäst, vilket sedan 2006 varit Ubuntu. Kraven är självklart olika, för mig är Windows 10 rätt oanvändbart i jobbet men har full förståelse för att det är ett relativt unikt läge och hade Windows fungerat hade det varit ett självklart val.

Tja, om du står ut med alla dumheter som Ubuntu gör är det väl trevligt, men nu ska vi inte börja med "min distro är bättre än din distro" heller. Oavsett är väl Linuxanvändare också helt fel grupp att övertyga om att det finns ett operativsystem som verkligen passar alla. Eller snarare "my system, my rules" som det hette när jag gav mig in i *nix.

Skrivet av Yoshman:

Jobbar man professionellt med GPGPU lär det sista vara ett totalt icke-problem. Är inte ekonomiskt försvarbart att sitta på gammal junk. Känns också som du kanske extrapolerar generella problem med CUDA lite väl mycket från en enda punkt. Ta utbildning inom GPGPU, CUDA är ju mer självklart där än vad Python numera är som första programmeringsspråk.

Jovisst, men AMDs Linuxdrivare täcker hela deras sortiment av GPUer. Det sista är ju mycket riktigt mer intressant för hemmafixare.

Skrivet av Yoshman:

Att AMD inte pushar SYCL är definitivt ett problem för det initiativet då de just nu är enda realistiska datacenter-alternativet till Nvidia. Får se vad som händer när Intels dGPUer hittar ut.

Svårt att se hur en öppen kompilator för CUDA kommer göra något att än bara stärka Nvidias position. Det är ju inte alls jämförbart med Glide på 3Dfx tiden. 3Dfx var överlägsna så länge som spelen använde Glide då de wrappers som fanns sög. 3Dfx hängde inte med när DX blev standard.

I CUDA fallet verkar ju övriga marknaden kasta in handduken, d.v.s. som om Glide vunnit och alla andra varit tvungna att försöka hänga på med olika wrappers.

PhysX är ju en standardfiness i bl.a. UE. Visst, blev ingen kommersiell succé och inget som längre körs på GPUer. Men det beror mer på att just fysik är ett exempel på något som bättre hanteras med SIMD på CPU än med GPGPU.

Var RTX tar vägen vet vi väl ännu inte? Det har redan gjort succé inom renderingsvärlden (OptiX). Till och med Blender stödjer ju redan detta. Tyvärr är OptiX, till skillnad från DXR, bundet till Nvidia så ännu ett exempel på där Nvidia drar ifrån de övriga
Spel kommer köra raytracing framöver, men borde inte förvåna någon att den första generationen som stödjer DXR kommer vara för seg och för begränsade när det väl slår igenom på bred front. Exakt samma har varit fallet för alla större teknikskiften, t.ex. när HW T&L kom.

Skillnaden en öppen kompilator gör är att man kan använda CUDA helt utan NVIDIAs kod. Det är signifikant eftersom företag som riskerar att bli utan support från NVIDIA om samarbetet bryter ihop har något att falla tillbaka på. Naturligtvis kommer den ökande användningen av CUDA att gynna NVIDIA, men en del av den ökande användningen kommer också att vara på kort från AMD. Vlket håll nettoresultatet för NVIDIA går åt kan bara framtiden avgöra.

Fast analogin med 3dfx handlar ju precis om hur Glide fungerade jättebra tills ett tillverkarneutralt API tog över. Hela magin låg i att de satsade allt på Glide, vilket gjorde att de blev beroende av att styra marknaden till deras egna proprietära API. Den bristande flexibiliteten gjorde att de inte kunde anpassa sig tillräckligt snabbt efter att marknaden tog över kontrollen.

Det som hände med 3D Vision var att marknaden vägrade anpassa sig efter NVIDIA. Det som hände med PhysX var att marknaden vägrade anpassa sig efter NVIDIA. RTX visar redan tecken på att historien upprepar sig igen när NVIDIA gick ut med hela 21 spel som skulle lanseras med stöd för RTX och omkring 10 som faktiskt går att köpa nu över ett år senare, där en utvecklare dessutom har dragit tillbaka löftet om RTX.

Nu börjar det ju även dyka upp spelmotorer och APIer med pathtracing som fungerar helt oberoende av RTX. Det luktar 3dfx/NVIDIA-flopp lång väg och jag undrar hur länge de har tänkt utveckla APIer som bara deras kort kan köra innan de går omkull. Just nu klarar de sig på att ha den snabbaste hårdvaran men jag ser hela deras strategi som självmål efter självmål.

CUDA är det enda proprietära APIt de har lyckats hålla på och den tiden börjar närma sitt slut med den satsning AMD gör på ROCm. Efter att ha skummat igenom lite om SYCL verkar det ju vara relativt lätt att implementera genom ROCm, SYCL 1.2.1 är ju anpassat för att kunna köras mot hårdvara designad för OpenCL 1.2 och uppåt, vilket ROCm har haft en brygga för sedan ROCm 1.5. Om steget nu är så litet mellan OpenCL 1.2 och SYCL som marknadsföringsmaterialet försöker påskina bör det mesta av koden för att gå mellan ROCm och SYCL redan vara skriven.

Med det sagt verkar ROCm smyga in lite i bakgrunden. Bland annat TensorFlow och PyTorch ska ju kunna använda ROCm rakt av när ROCm 3.0 släpps. Det är inte utvecklingen jag hade velat se (och misstänker att du håller med mig på den punkten) men då finns det i alla fall två tillverkarspecifika APIer i lite beräkningsmjukvara; CUDA och ROCm. Fragmenterad marknad är dåligt men ändå ett steg över monopol.

Testade de nya drivrutinerna med min nya dator med ett 5700XT och det gick inte att använda, så buggigt har jag aldrig vart med om tidigare. Både Halo Reach och RDR2 slutade uppdatera bilden efter ca 5 sekunder medan ljudet fortsatte i bakgrunden. Om jag alt-tabbade så spelet tappade fokus så började bilden uppdateras igen men så fort spelet fick tillbaka fokus så stannade bilden efter ett par sekunder igen.

Då jag nedgraderade drivrutinerna till tidigare version försvann problemet.

Skrivet av knobbly:

Testade de nya drivrutinerna med min nya dator med ett 5700XT och det gick inte att använda, så buggigt har jag aldrig vart med om tidigare. Både Halo Reach och RDR2 slutade uppdatera bilden efter ca 5 sekunder medan ljudet fortsatte i bakgrunden. Om jag alt-tabbade så spelet tappade fokus så började bilden uppdateras igen men så fort spelet fick tillbaka fokus så stannade bilden efter ett par sekunder igen.

Då jag nedgraderade drivrutinerna till tidigare version försvann problemet.

Ja, det verkar ganska trasigt i nuläget:

RX 5700 XT Random Black Screens When Gaming
https://community.amd.com/thread/243837

Drabbades själv av det där med senaste drivaren mitt i ett parti Apex Legends.

Hjälper detta mot skärmproblemen?

Bra tips!
Skall testa om det händer igen, på senare har det dock "tyvärr" fungerat bra, så testet kanske dröjer.

hänger sig

@KorpiSavu: jag har ett rx5700xt och efter ca 2 minuter hänger sig datorn , för att sedan stänga ner spelet.
felet uppstod radeonsoftware.exe undantagskod 0x c00000005 och en massa annan text

men med gammal 2019 programvara så fungerar det

Skrivet av bryggarn:

@KorpiSavu: jag har ett rx5700xt och efter ca 2 minuter hänger sig datorn , för att sedan stänga ner spelet.
felet uppstod radeonsoftware.exe undantagskod 0x c00000005 och en massa annan text

men med gammal 2019 programvara så fungerar det

Prova att avinstallera med DDU. Sen installerar du enbart drivrutinerna. EJ mjukvaran.