Re: [Qemu-devel] Proof of concept for GPU forwarding for Linux guest on Linux host

[address@hidden]

On Thu, Apr 4, 2019 at 12:49 AM Andrew Randrianasulu <
address@hidden> wrote:

> В сообщении от Thursday 04 April 2019 10:33:55 Tao Wu(address@hidden) 
> написал(а):
> > On Thu, Apr 4, 2019 at 12:15 AM Andrew Randrianasulu <
> > address@hidden> wrote:
> >
> > > Hi!
> > >
> > > I recall I saw something like this some time ago (but in connection
> with
> > > qemu-user + ALSA sycallls)
> > > So far I found this:
> > >
> > > https://marc.info/?l=qemu-devel&m=154349285205915
> > >
> > > List:       qemu-devel
> > > Subject:    [Qemu-devel] Support for Intel GPU
> > > From:       Allan Sandfeld Jensen <kde () carewolf ! com>
> > > Date:       2018-11-29 11:54:19
> > >
> > > Ah, found alsa bits too:
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05334.html
> >
> > Thanks, I took a look, the previous patches are targeting qemu user mode
> > while mine is targeting full system virtualization.
> > There is no plan to merge my code as it is now. I just want to get some
> > feedbacks first.
>
> I was thinking qemu's system mode was covered already by
>
>
> https://www.kraxel.org/blog/2018/04/vgpu-display-support-finally-merged-upstream/
> (intel's vGPU)
>
> Personally I have never tested this.

>
> https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/
> (virtio-gpu
> <https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/(virtio-gpu>,
> via gallium framework)
>
In the long term, this should be the right direction. But for now, it is
lacking of something like vulkan support.
Also, performance is not as great as it could be. In some use case
(benchmark), GPU forwarding work much better
than virtio-gpu and can get close native performance.

>
> ?
>
> But thanks anyway, may be some of those ideas can be fused together (I
> only have nvidia/nouveau GPU,
> and at best can forward-port something simple)

Actually although I said GPU forwarding, the real code is doing "file
handler" forwarding (by supporting
mmap/ioctl/select...) etc. I am not sure if we should have a general frame
work for things like this so we can forward
any special device in host to guest with minimal efforts.

>






>
> >
> >
> > >
> > >
> > > None of this was merged, as far as I understand.
> > >
> >
>
>
>