Is the VDI client Pi using VNC, H264 or what compression? Had an idea to use NDI instead for the framebuffer compression to the thin clients.
Also, that stinks that current Threadripper mobos can’t handle the ROM BAR of that many virtual GPU instances.
You and I are in a similar boat where you need NVIDIA GRID and AMD SR-IOV GPUs and I need Threadripper and other odds and ends (which now includes a Ninja V) to make my videos on capture cards and EDID emulators.
So, 2,500 for an Epic CPU that clocks in at only 2.3GHz (cheapest CPU w/ highest boost clock that NewEgg stocks), in order to drive a 2,000 S7150 FirePro card?
It would seem that if AMD made the price of entry a little more reasonable to deploy SR-IOV in home labs, then this would drive data center purchases down the road. Home users do not need to support dozens of users/VMs. We need a 4x4 package - a SR-IOV compatible 4GHz CPU and a 4-user GPU, with home lab pricing.
Where’s Scott Wasson?!?!?!
We need to strap him into a chair and force him to watch this vid.
If SR-IOV works on massively parallel ARM servers, all it would take is x86 to ARM translation cause ARM is cheaper. BUT… the computational cost of the architecture translator might outweigh the cheapness of ARM.
What I would love would be to still have the output ports and have an internal, programmable switch that would allow for piping the video from any of the SR-IOV instances – or even things like one per output. Give the OS control to config at runtime for what goes to what.
Oh and make it work with virsh/qemu/kvm
I’d pay $1000 for it and I bet you would start making lots of sales once people knew the build worked.
@wendell am I missing something with your flatpak container statement? With containers you can already install a custom user space driver specifically for that container and just pass the dri device from /dev/dri to the container. Since a container is fundamentally just user space there’s no need for SR-IOV because the same kernel driver is in use and if you wanted different kernel drivers then you’d need a separate kernel which is no longer a container but rather a VM.
This apparently has been worked out at this stage but when talked about by large companies that they might be able to do such things there were instant legal threats over x86 licensing so it went away again.
It’s a bit different for raw device access. I’ve been experimenting with that for config management for machine learning stacks. So normally it’s a way big security issue to give the container access to a real pci device.
With Sr iov you can still have a raw device but some security features remain intact.
Interesting, I wouldn’t have thought it was possible to use SR-IOV without a full VM but I’m really not very familiar with the technology so it wouldn’t surprise me if I was totally off base with that assumption.
