This MR implements native context support for amdgpu: this enables to use native drivers (radeonsi, radeonsi_drv_video and radv) in a guest VM (QEMU+kvm is the only supported setup currently).
Besides performance which seems better than virgl/venus (but I only tested 1 Vulkan game and a couple of GL ones so...) the main advantage I see is maintenance: the guest uses the same drivers, except that they don't speak directly to libdrm(_amdgpu) but instead go through a virtio/qemu transport layer. This can be see for in the enablement patches (last 2 of the series) which are quite small.
This is largely based on @robclark's work on freedreno/msm (see !14900 (merged) for the Mesa part or the XDC presentation https://www.youtube.com/watch?v=yTO8QRIfOjA&t=29065s).
To be able to test this some patches are currently needed for virglrenderer, qemu and Linux. I'll push them soon.
This MR is marked as draft because it's meant for discussion rather than review - the current code has flaws, quirks and all kind of issues; it's correct enough to be able to run Unigine Superposition and Rocket League though
The items I'd like to discuss:
- Would the RADV team be interested in supporting native context in their driver?
- Is the current approach regarding libdrm_amdgpu wrapping OK (see be8d35ac7d1 ("amd: port to libdrm_amdgpu virtual table"))? Instead of adding a new virtio winsys, I wrapped libdrm_amdgpu functions because radeonsi/radv amdgpu winsys provide lots of features that I didn't want to reimplement.