[virglrenderer-devel] virgl_renderer_resource_import_eglimage

[Alain Magloire]

Bonjour,


You mean Gerd... I think it is on his Kraxel news blog


https://www.kraxel.org/blog/2019/11/virtio-gpu-status-and-plans/



________________________________
From: Dmitry Sepp <Dmitry.Sepp at opensynergy.com>
Sent: Thursday, August 20, 2020 5:09 AM
To: Alain Magloire; Chia-I Wu; Vasyl Vavrychuk
Cc: virglrenderer-devel
Subject: RE: [virglrenderer-devel] virgl_renderer_resource_import_eglimage

Hi Alain,

Could you please point to some of the Greg's proposals?

Thanks in advance.

Best regards,
Dmitry.

________________________________
From: virglrenderer-devel [virglrenderer-devel-bounces at lists.freedesktop.org] on behalf of Alain Magloire [amagloire at blackberry.com]
Sent: Thursday, August 20, 2020 01:18
To: Chia-I Wu; Vasyl Vavrychuk
Cc: virglrenderer-devel
Subject: Re: [virglrenderer-devel] virgl_renderer_resource_import_eglimage


Bonjour,


Yes, it is my understanding that virtio-gpu allocates memory on the guest.

Then on the host you will have the corresponding backing store...

if synchronization is needed, then you will get a transfer Host to guest and vice-versa and your performance is.. not great.

The transfer to the attach backing is basically a memcpyv().


On Android, it can get more challenging, as Android is not killing apps, but relying on the lmkd (low memory killer) to take actions...

Except that the graphics memory being consumed by guest... is actually on the host... sigh... the accounting is off.


They are different possible strategies to deal with this.

Gerd H proposed a few...


Thanks




________________________________
From: virglrenderer-devel <virglrenderer-devel-bounces at lists.freedesktop.org> on behalf of Chia-I Wu <olvaffe at gmail.com>
Sent: Wednesday, August 19, 2020 6:40:38 PM
To: Vasyl Vavrychuk
Cc: virglrenderer-devel
Subject: Re: [virglrenderer-devel] virgl_renderer_resource_import_eglimage

On Wed, Aug 19, 2020 at 3:12 PM Vasyl Vavrychuk <vvavrychuk at gmail.com> wrote:
>
> On Wed, Aug 19, 2020 at 10:02 PM Chia-I Wu <olvaffe at gmail.com> wrote:
> >
> > On Wed, Aug 19, 2020 at 1:42 AM Vasyl Vavrychuk <vvavrychuk at gmail.com> wrote:
> > >
> > > Commit message for commit that adds "virgl_renderer_resource_import_eglimage" says this function supposed to be used from CrosVM. But I have checked CrosVM source and did not find virgl_renderer_resource_import_eglimage usage. Same for QEMU.
> > >
> > > As I understand virgl_renderer_resource_import_eglimage is essential to achieve zero copy. So, why QEMU/CrosVM do not use it. Are they using some other methods to achieve zero copy?
> >
> > I think crosvm moved from import model to export model a while ago.
> > It probably uses virgl_renderer_export_query now (didn't verify).
>
> You are right, crosvm does export fd and then "RegisterFdAtPciBarOffset".
>
> But, as far as I understand, this means that resources are allocated
> from host memory. In embedded systems, usually video memory is the
> same as RAM, but here RAM accessible to the guest and video memory
> provided by virglrenderer/crosvm will be separate. So I will have to
> limit separately, that for example, my guest should have 2 GB of RAM
> and 1 GB of video memory. Kindly please confirm that my understanding
> is correct.

That is correct, but it has nothing to do with importing or exporting.
The difference is whether crosvm or virglrenderer allocates, but those
allocations are not from the guest memory no matter who allocates.  I
think at least virglrenderer does not put any limit.

For qemu 2D mode, there is indeed a property called max_hostmem to
limit total host allocation size.
_______________________________________________
virglrenderer-devel mailing list
virglrenderer-devel at lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_virglrenderer-2Ddevel&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=HXY0JlWsCRezqLYUvNUPwHZ5mqaW649zvjNgwUbCqdA&m=wzB6ubiaQAckPg2BQnh3xKd7rlrZb0vrg3WEO8LX3C0&s=K4dgo1ALtSeiMGoYSB30Hr2NMVK8pnsy0yPxudjWwtA&e=
________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20200820/c44c712e/attachment.htm>