RadeonSI Lands Bits In Mesa 20.2 For Better Dealing With GPU Virtualization

[phoronix]

Phoronix: RadeonSI Lands Bits In Mesa 20.2 For Better Dealing WIth GPU Virtualization

Well known open-source AMD graphics driver developer Marek Olšák has landed a set of 15 patches into Mesa 20.2 for improving the RadeonSI driver's handling within virtualized environments...

http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Better-Deal-Virt

[Danny3]

I don't get it...
If this requires SR-IOV to work and no normal AMD cards have this, how is this going to work with Navi / Vega ?
Or we're talking about the professional versions only ?

[agd5f]

It doesn't require SR-IOV. You can use it on bare metal as well. It's just that the main use case for pre-emption at this point is SR-IOV (the hypervisor uses pre-emption for time slicing). There just isn't a use case for it on bare metal at the moment. In theory the scheduler in the kernel driver could use it to pre-empt lower priority tasks.

[artivision]

It doesn't require SR-IOV. You can use it on bare metal as well. It's just that the main use case for pre-emption at this point is SR-IOV (the hypervisor uses pre-emption for time slicing). There just isn't a use case for it on bare metal at the moment. In theory the scheduler in the kernel driver could use it to pre-empt lower priority tasks.

Clearly you didn't get the comment here. He said that you blocked non sever Gpus from using virtual Gpu futures like multiseat computer configuration. This way you lose money when someone buys the middle class Gpu and not the high class one because he cannot (for example) launch two CSGO instances from the same pc with two monitors - two mouses and two keyboards. Even games that don't support two instances from the same desktop, you can run the second instance in isolation sandbox.

AMD understands major fails and defeats when its to late. You only achieved management quality from 10% to 30% and you throw parties.

[pal666]

He said that you blocked non sever Gpus from using virtual Gpu futures like multiseat computer configuration. This way you lose money when someone buys the middle class Gpu and not the high class one because he cannot (for example) launch two CSGO instances from the same pc with two monitors - two mouses and two keyboards. Even games that don't support two instances from the same desktop, you can run the second instance in isolation sandbox.

what you think he said is wrong. virtual gpu features are not needed for multiseat. neither for video output nor for instance isolation, it's all doable in normal userspace with different users or namespaces

[agd5f]

Clearly you didn't get the comment here. He said that you blocked non sever Gpus from using virtual Gpu futures like multiseat computer configuration. This way you lose money when someone buys the middle class Gpu and not the high class one because he cannot (for example) launch two CSGO instances from the same pc with two monitors - two mouses and two keyboards. Even games that don't support two instances from the same desktop, you can run the second instance in isolation sandbox.

SR-IOV would not help in that case either. It doesn't support display hardware. You can do something like that today without virtualization by just using the GPU as a render node.

[artivision]

what you think he said is wrong. virtual gpu features are not needed for multiseat. neither for video output nor for instance isolation, it's all doable in normal userspace with different users or namespaces

If you cannot create a virtual Gpu then you need a second Gpu. Multiseat is Gpu based. Normal users don't buy two Gpus.

[artivision]

SR-IOV would not help in that case either. It doesn't support display hardware. You can do something like that today without virtualization by just using the GPU as a render node.

If you write a totally new UFO multiseat solution. Today's multiseat code potential requires two Gpus. Today's Gpus can display three different source outputs, you can connect the missing link.

[agd5f]

If you write a totally new UFO multiseat solution. Today's multiseat code potential requires two Gpus. Today's Gpus can display three different source outputs, you can connect the missing link.

You can write something today using drm leases to set up independent displays on different processes and you can use render nodes to submit work to the GPU from different processes. The plumbing is all there on the kernel side.

[caligula]

If you cannot create a virtual Gpu then you need a second Gpu. Multiseat is Gpu based. Normal users don't buy two Gpus.

Don't buy two GPUs? Correct me if I'm wrong but dual GPUs used to be quite common for gaming. Besides, how hard is it to buy another $50 GPU or have IGPU/APU + extra GPU? Most boards (except ITX) come with at least two GPU connectors, even mATX.