4 ms·
no AMD, why for Intel and doesn't cover 90% of nvidia products most people will have (unles they own and run a datacenter)... which leads me to ask... why even
by rob_c 4y ago
no AMD, why for Intel and doesn't cover 90% of nvidia products most people will have (unles they own and run a datacenter)... which leads me to ask...
why even bother?
- ArcVRArthur 4y agoThis works on most Nvidia consumer cards (not just datacenter cards): https://openmdev.io/index.php/GPU_Support https://openmdev.io/index.php/GPU_Support I think we have decent coverage of device support: https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw... We'd like to improve support for AMD devices but there are some issues there that have yet to be resolved.
- rob_c 4y agoSeriously, no. And this isn't just an unhelpful comment on a forum. This is serious advice from an expert here. After patching the Nvidia driver and then patching the driver itself to allow other non-standard vgpu definitions what's the point of this? Its at best a feel good that I reimplemented a tiny part. You'd be better contributing patches against binary blobs to the community rather than wasting time on this.
- ArcVRArthur 4y agoNearest I can tell the guy earlier thought what mdevctl is (echo uuid >> /sys/mdev_bus/$pci-device/available-types/) is the same as what we are doing. That couldn't be further from the truth. I tried explaining to him we arbitrarily define the available types on behalf of the vendor driver via user configuration. It’s the difference between picking from a pre-made list of things someone else says you’re allowed to do and making the list of things you’re allowed to do yourself.