5 ms·

> Both AMD and Nvidia drivers are dumpster fires in terms of stability (and for Nvidia, I've tried both nouveau and the binary drivers) I've had great experien

> Both AMD and Nvidia drivers are dumpster fires in terms of stability (and for Nvidia, I've tried both nouveau and the binary drivers) I've had great experience with the mainline amdgpu driver, and find it ridiculous to group AMD and nvidia together in this context today. With amdgpu AMD has moved much closer to intel on the mainline linux gpu support front.

the8472 6y ago
Afaik AMD is buggy when passed to virtualized guest. nvidia also requires hacks to make it work. Intel is the only party where it's supported out of the box. Edit: incorrect terminology
- formerly_proven 6y ago
  Doesn't nVidia explicitly disable this feature unless it's a Quadro?
  - the8472 6y ago
    There are several ways to virtualize a card. Splitting the card into multiple virtual units only works with the pro/datacenter models. Passing through the whole card works if you trick the guest driver by hiding virtualization.
- tjoff 6y ago
  That is a wholly different use case though. And I'd rather take AMDs difficulties in that regard over nVidia who are actively fighting it. Don't give money to someone that shits on you.
- pengaru 6y ago
  Judging from mainline's commit log for linux/drivers/gpu/drm/amd/amdgpu there's been a steady flow of SR-IOV related fixes/updates up to and including v5.8 so it's at least not being ignored. I admit I haven't used amdgpu in this capacity, but just the fact that we can scrutinize amdgpu's history in mainline is a huge improvement over the past.
- zamadatix 6y ago
  This comment conflates pretty much everything it mentions: - Intel GPUs support mediated virtualization passthrough through GVT-G not SR-IOV - Nvidia blocks passthrough as a feature gatekeep in the driver. You can work around this block by hiding some info from the guest (the hacks mentioned). Consumer Nvidia cards do not support SR-IOV, special models that do require the proprietary driver and a license to SR-IOV (no hacks to workaround this) - AMD works fine under passthrough but requires specific models for SR-IOV (though this works on the official open driver). SR-IOV is still unstable. - None of this is really relevant to the original topic
  - the8472 6y ago
    Thanks for the correction. I only played around with it for a few evenings and intel was the only thing I managed to virtualize. I think they're relevant because being able to virtualize it is an aspect of not being a dumpster fire.
  - Namidairo 6y ago
    > AMD works fine under passthrough but requires specific models for SR-IOV Did they ever ship a fix in mainline for their cards becoming stuck in unusable states without powering off the host? (I believe the fix involved a sequence of commands for a PSP reset) At least I believe AMD engineers were being helpful in giving details on it though.
    - zamadatix 6y ago
      Made in 5.6 earlier this year finally.
mixedCase 6y ago
Using the 5700XT with amdgpu has been a complete shit show since day one, and you have success depending on your set-up since QA appears to be "if it works on a dev's machine ship it". Mainline (let alone stable kernels) was almost unusable for like 4-5 months after release, you were completely out of luck unless you followed the right incantations and used a precise firmware binary that had been available at some point at an AMD developer's personal repo but you later had to get through someone else's Dropbox. After that period it got stable-ish for me. Occasionally Mesa/kernel updates made some games stop working or freeze the system but workarounds. Yesterday I swapped a monitor for a higher res one, and I triggered a bug where DPM essentially shits its pants and you have to switch to manual power management. Meaning a year after release the card can't handle basic multi-monitor stuff. I've had AMD CPUs exclusively ever since Athlon II, always coupled with Nvidia cards. I wanted to support them also in GPUs given their open source work but for me it's been a complete mess. If Intel GPUs are actually any good and don't shit the bed I'll sell this card for whatever I can get.
- vondur 6y ago
  I've been making sure to run the latest kernels and latest mesa Mesa, and my 5700xt has been great. But, I agree that the 5700 series had some serious issues in its original kernel releases.
- 1_player 6y ago
  You don't believe him? https://gitlab.freedesktop.org/drm/amd/-/issues/929 https://gitlab.freedesktop.org/drm/amd/-/issues/929 https://gitlab.freedesktop.org/drm/amd/-/issues/892 https://gitlab.freedesktop.org/drm/amd/-/issues/892 I built a PC in June and bought a 5500XT and it's bloody unusable. It hangs if I plug a monitor, it hangs randomly, it hangs when idle, it's not a hardware defect since Windows is fine with it. Sorry but the Linux community has been bashing NVIDIA and praising AMD because "opensource" while there are critical bugs like that one that have been open for a year. It makes my blood boil. My opensource friendly 5500XT is on a shelf and I'm using an NVIDIA card in its place. And you better believe I will not be giving AMD my custom again.
pjmlp 6y ago
Kind of, not if you are serious about GPGPU and not stuck with a laptop card. However the 3D programming experience still beats Intel drivers.

the8472 6y ago

Afaik AMD is buggy when passed to virtualized guest. nvidia also requires hacks to make it work. Intel is the only party where it's supported out of the box. Edit: incorrect terminology

formerly_proven 6y ago
Doesn't nVidia explicitly disable this feature unless it's a Quadro?
- the8472 6y ago
  There are several ways to virtualize a card. Splitting the card into multiple virtual units only works with the pro/datacenter models. Passing through the whole card works if you trick the guest driver by hiding virtualization.
tjoff 6y ago
That is a wholly different use case though. And I'd rather take AMDs difficulties in that regard over nVidia who are actively fighting it. Don't give money to someone that shits on you.
pengaru 6y ago
Judging from mainline's commit log for linux/drivers/gpu/drm/amd/amdgpu there's been a steady flow of SR-IOV related fixes/updates up to and including v5.8 so it's at least not being ignored. I admit I haven't used amdgpu in this capacity, but just the fact that we can scrutinize amdgpu's history in mainline is a huge improvement over the past.
zamadatix 6y ago
This comment conflates pretty much everything it mentions: - Intel GPUs support mediated virtualization passthrough through GVT-G not SR-IOV - Nvidia blocks passthrough as a feature gatekeep in the driver. You can work around this block by hiding some info from the guest (the hacks mentioned). Consumer Nvidia cards do not support SR-IOV, special models that do require the proprietary driver and a license to SR-IOV (no hacks to workaround this) - AMD works fine under passthrough but requires specific models for SR-IOV (though this works on the official open driver). SR-IOV is still unstable. - None of this is really relevant to the original topic
- the8472 6y ago
  Thanks for the correction. I only played around with it for a few evenings and intel was the only thing I managed to virtualize. I think they're relevant because being able to virtualize it is an aspect of not being a dumpster fire.
- Namidairo 6y ago
  > AMD works fine under passthrough but requires specific models for SR-IOV Did they ever ship a fix in mainline for their cards becoming stuck in unusable states without powering off the host? (I believe the fix involved a sequence of commands for a PSP reset) At least I believe AMD engineers were being helpful in giving details on it though.
  - zamadatix 6y ago
    Made in 5.6 earlier this year finally.

mixedCase 6y ago

Using the 5700XT with amdgpu has been a complete shit show since day one, and you have success depending on your set-up since QA appears to be "if it works on a dev's machine ship it". Mainline (let alone stable kernels) was almost unusable for like 4-5 months after release, you were completely out of luck unless you followed the right incantations and used a precise firmware binary that had been available at some point at an AMD developer's personal repo but you later had to get through someone else's Dropbox. After that period it got stable-ish for me. Occasionally Mesa/kernel updates made some games stop working or freeze the system but workarounds. Yesterday I swapped a monitor for a higher res one, and I triggered a bug where DPM essentially shits its pants and you have to switch to manual power management. Meaning a year after release the card can't handle basic multi-monitor stuff. I've had AMD CPUs exclusively ever since Athlon II, always coupled with Nvidia cards. I wanted to support them also in GPUs given their open source work but for me it's been a complete mess. If Intel GPUs are actually any good and don't shit the bed I'll sell this card for whatever I can get.

vondur 6y ago
I've been making sure to run the latest kernels and latest mesa Mesa, and my 5700xt has been great. But, I agree that the 5700 series had some serious issues in its original kernel releases.
1_player 6y ago
You don't believe him? https://gitlab.freedesktop.org/drm/amd/-/issues/929 https://gitlab.freedesktop.org/drm/amd/-/issues/929 https://gitlab.freedesktop.org/drm/amd/-/issues/892 https://gitlab.freedesktop.org/drm/amd/-/issues/892 I built a PC in June and bought a 5500XT and it's bloody unusable. It hangs if I plug a monitor, it hangs randomly, it hangs when idle, it's not a hardware defect since Windows is fine with it. Sorry but the Linux community has been bashing NVIDIA and praising AMD because "opensource" while there are critical bugs like that one that have been open for a year. It makes my blood boil. My opensource friendly 5500XT is on a shelf and I'm using an NVIDIA card in its place. And you better believe I will not be giving AMD my custom again.

pjmlp 6y ago

Kind of, not if you are serious about GPGPU and not stuck with a laptop card. However the 3D programming experience still beats Intel drivers.