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?

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

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.

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."

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.

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.

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.

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.

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.).

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.

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

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.

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.

19.12.3 är släppt!

https://www.amd.com/en/support/kb/release-notes/rn-rad-win-19...

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