Geforce-grafikkort får stöd för virtualisering

Permalänk
Inaktiv

Har halvt glömt bort den men har en halvskrotad 6700K-baserad dator det nog får bli att labba lite med. 1080Ti, 2x16GB RAM samt leta någon ledig SSD. Skönt att inte behöva använda min ordinarie dator för detta.

Nu har jag inte använt Linux på riktigt sedan KDE3 fortfarande var aktuell och KDE4 var en buggig röra. Har nog hänt en del sedan dess så att bara hitta "rätt" distro lär väl ta sin tid även det.

Skrivet av pa1983:

Jo jag har pratat med polare om just någon form av hårvaruviritualiseringstöd i GPU'n, ska vi kalla det SMT för GPU'er!
Jag du förstår poängen, hade en GPU kunnat se ut som två så hade det ju varit nice att kunna aktivera det och ge ett VM tillgång till GPU'n utan att hosten blir av med den sedan skulle man ju helst då med kunna diktera vilken eller vilka portar för bild VM'et ska ha.

Tror själv att det finns en marknad för detta och den som ger vanliga konsumenter detta utan extra taxa kommer ha en fördel bland med tech savy konsumenter och prosumers som behöver tex flera OS samtidigt med bra prestanda på alla.

Möjligheterna är ju nästan oändliga.

Att kunna erbjuda GPU i host och en virtualiserad session vore rimligt, kommer fortfarande inte konkurrera med Tesla. Ypperligt tillfälle för Nvidia att gå före både AMD och Intel i mitt tycke.

Permalänk
Hedersmedlem
Skrivet av anon185723:

Windows 10 har en tendens att samla in en massa personlig information. De flesta väljer nog att ha linux i grunden och Windows i en vm för att ha bättre koll på sin dator. Man vill kunna ha datorn på utan att någon annan hos microsoft väljer när den ska uppdateras och startas om. Man vill helt enkelt inte ha microsoft som sitter och ändrar på en massa viktiga inställningar utan att fråga en efter en uppdatering.

Grund operativsystemet i min burk agerar som en hypervisor. Den hanterar alla virtuella maskiner och containers som körs simultant. Jag är kort sagt inte så sugen på att köra Windows 10 som grund. För att sedan emulera samma virtuella maskiner och containers som jag har i linux.

Vill jag spela startar jag Windows i en VM. Vill jag göra något annat så kan jag starta Linux i en VM. Det kan vara enklare att ha bild, mus och tangentbord på värddatorn ifall man behöver felsöka. Men annars ser tyvärr ingen poäng med att slösa en PCI-E slot och dess lanes för den möjligheten.

En terminal räcker för mig och då duger COM porten och SSH för mig. Om jag vill in i bios så kan jag använda IPMI som kommer med de bra moderkorten i dag. Men de flesta är i dag mer moderna än mig och kör ett helt webbläsargränssnitt för att hantera värdmaskinen. Så att de kan konfigurera maskinen i webbläsaren på samma sätt som de flesta konfigurerar sina routers.

Jag vill inte gå till att använda en KVM switch istället för typ PuTTY. Hade min processor haft integrerad grafik så kanske jag skulle ha övervägt att ha bild på min värddatorn. Men känner jag mig själv rätt så kommer jag förmodligen att slå av det för att spara ström. : /

Mycket spam av mig, men tack att du frågar. : )

Ja men, alltså, hur kommer du åt denna "terminal"? Har du en VT100 på skrivbordet bredvid din tangentbord/mus/bildskärm-setup som du använder för att spela spel?

Eller har du två datorer eller något?

Permalänk
Inaktiv
Skrivet av pv2b:

Eller har du två datorer eller något?

Jag har som sagt en fysisk dator som kör ett operativsystem. Det operativsystemet kör flera virtuela maskiner och containers. En virtuel maskin = dator. Istället för att låta operativsystemet använda ett grafikkort så ger den bort nästan all hårdvara till olika virtuela datorer.

Skrivet av pv2b:

Ja men, alltså, hur kommer du åt denna "terminal"?

En av dessa Virtuela maskiner är som sagt en helt fungerande Windows 10 installation med nvidia grafik. För att spela med den så har jag självklart ljud, mus och tangentbord i min Windows 10vm.

I min Windows 10 VM kan jag uppräta en anslutning till min värd maskin. Kort och gott så använder jag mina vms och även min telefon som en terminal till värdmaskinen.

Många väljer att installera ett färdigt packet för att styra sin värdmaskin igenom webläsaren. Typ Proxmox, Unraid , EXSI, TrueNAS... osv... På så sätt sliper de ha en bildskärm, mus och tangentbord dedikerad till värdmaskinen. Vars enda syfte är att hantera virtuella datorer och olika tjänster.

Tydligare
Permalänk
Medlem
Skrivet av pa1983:

Men problemet anser jag är att AMD tyst har fuckat sina kort likt nvidia offecielt alltid gjort så man måste dölja hypervisorn annars installeras driversen inte korrekt, saknas massa i kontrollpanelen bland annat och jag tappade lät 50% prestanda efter 20.4 drivers vilket jag inte var ensam om så AMD är dött för passtrough anser jag.

Åhå, detta var nytt för mig. Har du länk till mer info? Det är ju illa om de börjat göra så, undrar också varför, jag menar vad har de att segmentera? Nvidia gjorde ju en stor grej av passthrough-stödet på Quadro för flera år sen, då finns det en logik i att låsa det på konsumentkorten, men jag har inte sett AMD göra nåt liknande.

Citat:

Bara betala Nvidia taxen men supportet är så mycket bättre även om nvidia är rövhål så har dom i alla fall features dom kan segmentera XD

Jo jag har också kört nvidia för passthrough mest, ibland är det bättre med en förutsägbar och kompetent motståndare än en mindre pålitlig vän... å andra sidan föredrar jag AMD i Linux p.g.a. trevligare drivare (Linus berömda finger etc.).

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem
Skrivet av Oegat:

Åhå, detta var nytt för mig. Har du länk till mer info? Det är ju illa om de börjat göra så, undrar också varför, jag menar vad har de att segmentera? Nvidia gjorde ju en stor grej av passthrough-stödet på Quadro för flera år sen, då finns det en logik i att låsa det på konsumentkorten, men jag har inte sett AMD göra nåt liknande.

Jo jag har också kört nvidia för passthrough mest, ibland är det bättre med en förutsägbar och kompetent motståndare än en mindre pålitlig vän... å andra sidan föredrar jag AMD i Linux p.g.a. trevligare drivare (Linus berömda finger etc.).

Har inga bevis mer än att jag och andra användare rapporterat att dom får dölja hypervisorn. Märkte det i början på förra året då delar av kontrollpanelen försvan så gick int att confa saker som skärm tex osv som ställde till problem.
Reinstall av driversen med dåld hypervisor, alltså samma trick nvidia users fick köra fungerar.
Krävs också vid clean install av ett VM.

Sedan har jag och andra märkt kattastrof i prestanda efter 20.4 driversen, fungerar men prestandan suger.

Möjligt att det finns work arounds men "fördelarna" amd hade med att man inte behövde dölja hypervisorn verkar borta, och har nvidia nu låst upp detta plus att deras kort inte har reset buggar och prestanda problem så ser jag noll fördlen till AMD numera, det verkar borta.

Mitt RX5700 hatar linux Mint i alla fall, testat 5.4 till 5.11 kernel, kör en egenkompilerad 5.9 gentoo kernel för tillfälet då den varit stabiliast.
Testat nyare firmwares också. Får mycket gpu resets och krasher som följd, efter en dag, efter 2 veckor så när som helst.
I går när jag skulle starta mpv så krashade den totalt.
Kortet har fungerat fint annars men i linux, nopp katastrof.

Och det är samma där, igen verkar veta orsaken men folk lider av problemet.

Apr 5 18:58:01 voyager kernel: [141249.253816] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=156334, emitted seq=156337 Apr 5 18:58:01 voyager kernel: [141249.253850] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process mpv pid 60241 thread mpv:cs0 pid 60285 Apr 5 18:58:01 voyager kernel: [141249.253853] amdgpu 0000:0c:00.0: amdgpu: GPU reset begin! Apr 5 18:58:05 voyager kernel: [141253.253820] amdgpu 0000:0c:00.0: amdgpu: failed to suspend display audio Apr 5 18:58:05 voyager kernel: [141253.677088] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002 Apr 5 18:58:06 voyager kernel: [141253.982819] [drm] Register(0) [mmUVD_RBC_RB_RPTR] failed to reach value 0x00000150 != 0x00000000 Apr 5 18:58:06 voyager kernel: [141254.288592] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002 Apr 5 18:58:08 voyager kernel: [141256.572096] amdgpu 0000:0c:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state! Apr 5 18:58:08 voyager kernel: [141256.572098] amdgpu 0000:0c:00.0: amdgpu: Failed to disable smu features except BACO. Apr 5 18:58:08 voyager kernel: [141256.572101] amdgpu 0000:0c:00.0: amdgpu: Fail to disable dpm features! Apr 5 18:58:08 voyager kernel: [141256.572125] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block <smu> failed -62 Apr 5 18:58:08 voyager kernel: [141256.583688] [drm] free PSP TMR buffer Apr 5 18:58:08 voyager kernel: [141256.622762] amdgpu 0000:0c:00.0: amdgpu: GPU BACO reset Apr 5 18:58:11 voyager kernel: [141258.861038] amdgpu 0000:0c:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state! Apr 5 18:58:11 voyager kernel: [141258.861040] amdgpu 0000:0c:00.0: amdgpu: Failed to enter BACO state! Apr 5 18:58:11 voyager kernel: [141258.861062] [drm:amdgpu_device_gpu_recover.cold [amdgpu]] *ERROR* ASIC reset failed with error, -62 for drm dev, 0000:0c:00.0 Apr 5 18:58:11 voyager kernel: [141258.861094] amdgpu 0000:0c:00.0: amdgpu: GPU reset(1) failed Apr 5 18:58:11 voyager kernel: [141258.861119] amdgpu 0000:0c:00.0: amdgpu: GPU reset end with ret = -62 Apr 5 18:58:21 voyager kernel: [141269.222080] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=156337, emitted seq=156337 Apr 5 18:58:21 voyager kernel: [141269.222112] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process mpv pid 60241 thread mpv:cs0 pid 60285 Apr 5 18:58:21 voyager kernel: [141269.222116] amdgpu 0000:0c:00.0: amdgpu: GPU reset begin! Apr 5 18:58:25 voyager kernel: [141273.222081] amdgpu 0000:0c:00.0: amdgpu: failed to suspend display audio

Mitt RX5700 plågar mig med sådana fel av olika slag men i slutändan blir det en GPU reset och crash.
Vissa kernels kan gå i 1-2 veckor, andra kommer inte ens till skrivbordet innan de krashar efter login.

Igen mängd googlande har gett en lösning.
Inte alls imponerad av AMD's opensås effort.

Efter att jag testat 3st AMD kort nu sedan 2017 så kommer jag gå tillbaks till Nvidia som jag kört i linux i 20 år för det fungerar alltid i alla fall, aldrig haft problem som kvarstår med nvidia.

Kortet fungerar av allt att dömma i passtrough och windows så linux driversen är enda gemensam problemet.

Mitt hinder just nu är cash och bristande tillgång på vettiga kort, så bara vänta på bättre tider.

Permalänk
Medlem
Skrivet av DasIch:

Det skulle funka alldeles utmärkt. Om du vill köra det på en dator som du använder samtidigt, typ din gaming-rig eller dylikt, så kan du inte använda grafikkortet till båda sakerna samtidigt. Har du inte problem med extra sladdar kan du dock ha en KVM-switch och använda iGPU.
På en server är det förstås inga problem. Såvitt jag vet är inte prestandaförlusten mer än några få procent. Värt att poängtera är dock att virtuella maskiner inte är vattentäta. Det är säkrare men inte hundraprocentigt. Är du orolig för skadlig kod (vilket man bör vara när det kommer till kryptobrytning) är det alltså inte säkert att du är skyddad.

OK, tack för info. Det är något jag får ta och undersöka! Det finns verkligen så mycket användningsområden med att köra mer och mer virtuellt.

Permalänk
Medlem
Skrivet av pa1983:

Har inga bevis mer än att jag och andra användare rapporterat att dom får dölja hypervisorn. Märkte det i början på förra året då delar av kontrollpanelen försvan så gick int att confa saker som skärm tex osv som ställde till problem.
Reinstall av driversen med dåld hypervisor, alltså samma trick nvidia users fick köra fungerar.
Krävs också vid clean install av ett VM.

Sedan har jag och andra märkt kattastrof i prestanda efter 20.4 driversen, fungerar men prestandan suger.

Möjligt att det finns work arounds men "fördelarna" amd hade med att man inte behövde dölja hypervisorn verkar borta, och har nvidia nu låst upp detta plus att deras kort inte har reset buggar och prestanda problem så ser jag noll fördlen till AMD numera, det verkar borta.

Mitt RX5700 hatar linux Mint i alla fall, testat 5.4 till 5.11 kernel, kör en egenkompilerad 5.9 gentoo kernel för tillfälet då den varit stabiliast.
Testat nyare firmwares också. Får mycket gpu resets och krasher som följd, efter en dag, efter 2 veckor så när som helst.
I går när jag skulle starta mpv så krashade den totalt.
Kortet har fungerat fint annars men i linux, nopp katastrof.

Och det är samma där, igen verkar veta orsaken men folk lider av problemet.

Apr 5 18:58:01 voyager kernel: [141249.253816] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=156334, emitted seq=156337 Apr 5 18:58:01 voyager kernel: [141249.253850] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process mpv pid 60241 thread mpv:cs0 pid 60285 Apr 5 18:58:01 voyager kernel: [141249.253853] amdgpu 0000:0c:00.0: amdgpu: GPU reset begin! Apr 5 18:58:05 voyager kernel: [141253.253820] amdgpu 0000:0c:00.0: amdgpu: failed to suspend display audio Apr 5 18:58:05 voyager kernel: [141253.677088] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002 Apr 5 18:58:06 voyager kernel: [141253.982819] [drm] Register(0) [mmUVD_RBC_RB_RPTR] failed to reach value 0x00000150 != 0x00000000 Apr 5 18:58:06 voyager kernel: [141254.288592] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x00000001 != 0x00000002 Apr 5 18:58:08 voyager kernel: [141256.572096] amdgpu 0000:0c:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state! Apr 5 18:58:08 voyager kernel: [141256.572098] amdgpu 0000:0c:00.0: amdgpu: Failed to disable smu features except BACO. Apr 5 18:58:08 voyager kernel: [141256.572101] amdgpu 0000:0c:00.0: amdgpu: Fail to disable dpm features! Apr 5 18:58:08 voyager kernel: [141256.572125] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block <smu> failed -62 Apr 5 18:58:08 voyager kernel: [141256.583688] [drm] free PSP TMR buffer Apr 5 18:58:08 voyager kernel: [141256.622762] amdgpu 0000:0c:00.0: amdgpu: GPU BACO reset Apr 5 18:58:11 voyager kernel: [141258.861038] amdgpu 0000:0c:00.0: amdgpu: Msg issuing pre-check failed and SMU may be not in the right state! Apr 5 18:58:11 voyager kernel: [141258.861040] amdgpu 0000:0c:00.0: amdgpu: Failed to enter BACO state! Apr 5 18:58:11 voyager kernel: [141258.861062] [drm:amdgpu_device_gpu_recover.cold [amdgpu]] *ERROR* ASIC reset failed with error, -62 for drm dev, 0000:0c:00.0 Apr 5 18:58:11 voyager kernel: [141258.861094] amdgpu 0000:0c:00.0: amdgpu: GPU reset(1) failed Apr 5 18:58:11 voyager kernel: [141258.861119] amdgpu 0000:0c:00.0: amdgpu: GPU reset end with ret = -62 Apr 5 18:58:21 voyager kernel: [141269.222080] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vcn_dec timeout, signaled seq=156337, emitted seq=156337 Apr 5 18:58:21 voyager kernel: [141269.222112] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process mpv pid 60241 thread mpv:cs0 pid 60285 Apr 5 18:58:21 voyager kernel: [141269.222116] amdgpu 0000:0c:00.0: amdgpu: GPU reset begin! Apr 5 18:58:25 voyager kernel: [141273.222081] amdgpu 0000:0c:00.0: amdgpu: failed to suspend display audio

Mitt RX5700 plågar mig med sådana fel av olika slag men i slutändan blir det en GPU reset och crash.
Vissa kernels kan gå i 1-2 veckor, andra kommer inte ens till skrivbordet innan de krashar efter login.

Igen mängd googlande har gett en lösning.
Inte alls imponerad av AMD's opensås effort.

Efter att jag testat 3st AMD kort nu sedan 2017 så kommer jag gå tillbaks till Nvidia som jag kört i linux i 20 år för det fungerar alltid i alla fall, aldrig haft problem som kvarstår med nvidia.

Kortet fungerar av allt att dömma i passtrough och windows så linux driversen är enda gemensam problemet.

Mitt hinder just nu är cash och bristande tillgång på vettiga kort, så bara vänta på bättre tider.

Förstår, ja tyvärr är det en del lotteri med vilka generationer och kort som funkar bra hos AMD. Jag kör nu på ett gammalt 7790 (tidigt GCN2) som har åldrats fint i Linux, men det är ju inte så användbar info för den som vill vara prestandamässigt uppdaterad 2021...

Ändå underligt att om de valt att begränsa, men om det som du beskriver går att jobba runt med att dölja hypervisorn, så är det svårt att hitta någon annan förklaring. Men jag har fortfarande svårt att se deras motiv. Det ger ett ganska tafatt intryck, precis som de plötsliga regressionerna mellan generationer (resetbugg mm.) ger.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX