<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Exchange Server"> <style></style> </head> <body> <meta content="text/html; charset=UTF-8"> <style type="text/css" style="">  </style> <div dir="ltr"> <div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif"> 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 </div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="x_divRplyFwdMsg" dir="ltr">From: virglrenderer-devel <virglrenderer-devel-bounces@lists.freedesktop.org> on behalf of Chia-I Wu <olvaffe@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 <div> </div> </div> </div> <div class="PlainText">On Wed, Aug 19, 2020 at 3:12 PM Vasyl Vavrychuk <vvavrychuk@gmail.com> wrote: > > On Wed, Aug 19, 2020 at 10:02 PM Chia-I Wu <olvaffe@gmail.com> wrote: > > > > On Wed, Aug 19, 2020 at 1:42 AM Vasyl Vavrychuk <vvavrychuk@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@lists.freedesktop.org <a href="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=">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=</a> </div> <HR>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. </body> </html>