<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 5:14 PM Gurchetan Singh <<a href="mailto:gurchetansingh@chromium.org">gurchetansingh@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 3:46 AM Elie Tournier <<a href="mailto:tournier.elie@gmail.com" target="_blank">tournier.elie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 01, 2020 at 07:50:37AM -0700, Frank Yang wrote:<br>
> On Wed, Apr 1, 2020 at 4:03 AM Elie Tournier <<a href="mailto:tournier.elie@gmail.com" target="_blank">tournier.elie@gmail.com</a>><br>
> wrote:<br>
> <br>
> > On Tue, Mar 31, 2020 at 04:54:12PM -0700, Gurchetan Singh wrote:<br>
> > > On Mon, Mar 30, 2020 at 10:49 AM Elie Tournier <<a href="mailto:tournier.elie@gmail.com" target="_blank">tournier.elie@gmail.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > On Fri, Mar 27, 2020 at 05:10:43PM -0700, Gurchetan Singh wrote:<br>
> > > > > On Wed, Mar 25, 2020 at 5:17 AM Elie Tournier <<br>
> > <a href="mailto:tournier.elie@gmail.com" target="_blank">tournier.elie@gmail.com</a>><br>
> > > > > wrote:<br>
> > > > ><br>
> > > > > > Hi all,<br>
> > > > > ><br>
> > > > > > I'm currently working on OpenGL 4.5 support for virgl.<br>
> > > > > > For that, we need to implement ARB_clear_texture and<br>
> > > > ARB_buffer_storage.<br>
> > > > > > The first one is almost finish, and I should submit a MR soon-ish.<br>
> > > > > > The second one, ARB_buffer_storage is trickier to implement.<br>
> > > > > ><br>
> > > > > > So I'm wondering if any of you started something already?<br>
> > > > > > Do you have a design in mind?<br>
> > > > > ><br>
> > > > ><br>
> > > > > Hmm, depends on where you want to implement ARB_buffer_storage:<br>
> > > > I mean, the goal here is to help the project to going further.<br>
> > > > It seems that you started (1) but I guess you are interested by (3).<br>
> > > > Would it make sense to go gradually and do (1) -> (2) -> (3) as<br>
> > > > iiuc, we can reuse bits from the previous iteration?<br>
> > ><br>
> > ><br>
> > > (1) should work pretty easily, since we got dEQP-vk.memory.* working<br>
> > [with<br>
> > > Android Emulator VK impl].<br>
> ><br>
> > Does that mean the QEMU part is already in place?<br>
> ><br>
> <br>
> Hi, not necessarily; I've been the one trying that dEQP-VK.memory* out and<br>
> I only have patches for crosvm so far:<br>
> <br>
> <a href="https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034029" rel="noreferrer" target="_blank">https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034029</a><br>
> <a href="https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035595" rel="noreferrer" target="_blank">https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035595</a><br>
> <br>
> (which I'll get back to soon, hopefully this week, as I was busy w/ R-CTS<br>
> stuff)<br>
> <br>
> The same mechanism should work for coherent mem in GL though. I need to do<br>
> some experiments for (2) to see if EXT_external_objects works<br>
<br>
That's an amazing news.<br>
<br>
On my side, I will modify QEMU to be on par with the work done on drm.<br>
ie be able to use RESOURCE_CREATE_BLOB.<br></blockquote><div><br></div><div>Have you had any luck on this?  If not, perhaps Gerd/Dave/other QEMU devs can offer hints/strawman code on how to proceed. <div><br></div><div>Problem:</div><div><br></div><div>I was taking a look at QEMU and it's non-obvious to me how to implement RESOURCE_MAP / RESOURCE_UNMAP. </div><div><br></div><div><div>For GL_ARB_buffer_storage, virglrenderer can provide a page-aligned address (seems to work even on Nvidia) for use with KVM:</div><div><br></div><div><a href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/374/diffs#14086999aaf57fc68a3d7d639ab280c3a2672430_603_670" target="_blank">https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/374/diffs#14086999aaf57fc68a3d7d639ab280c3a2672430_603_670</a></div></div><div><br></div><div>We need to figure out a way to call kvm_region_add / kvm_region_del from virtio-gpu-3d.c with this address.<br></div><div><br></div><div>For crosvm, it's easy since it's designed to sit directly on top of KVM.  With QEMU, there are several layers of abstraction.  </div><div><br></div><div>memory_listener_register / memory_listener_unregister seemed promising, but they only seem to allow one address space per listener.  It's not clear how to get access to KVMMemoryListener in virtio-gpu-3d.c ...</div></div><div><br></div><div>memory_device_plug(..) seems interesting too, but I don't see a path to KVM, but then again, I'm a QEMU noob.</div><div> </div></div></div></blockquote><div><br></div><div>To address the overhead/complexity issue of going through the memory region / listener api in QEMU, we chose to</div><div><br></div><div>- only use them for the PCI memory region</div><div>- not have actual memory backing it to start with</div><div>- user controls the backing at runtime</div><div><br></div><div><a href="https://android-review.googlesource.com/q/topic:%22qemu-user-controlled-hv-mappings%22+(status:open%20OR%20status:merged)">https://android-review.googlesource.com/q/topic:%22qemu-user-controlled-hv-mappings%22+(status:open%20OR%20status:merged)</a></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> <br>
> > ><br>
> > > I think the trickiest part of the entire chain is (3) [it sounds like<br>
> > this<br>
> > > your end goal too?].  In particular, the lack of GLES coherent support<br>
> > ...<br>
> > > I think we may need to add some extensions or extend<br>
> > EXT_external_objects.<br>
> > > A good place to start is a feasibility study about such extensions, or<br>
> > > auditing your target drivers (i965?).<br>
> ><br>
> > Yes, my end goal is that all virglrenderer user should be able to expose<br>
> > OpenGL 4.5 on the guest side. But for now, (1) seems to be the best option.<br>
> ><br>
> > I'm not familiar with EXT_external_objects but I'm more in favor of a new<br>
> > extension.<br>
> > And yes, you guess right, I'm on i965/iris drivers so that's what I target<br>
> > for now.<br>
> ><br>
> > I will keep you updated.<br>
> > ><br>
> > ><br>
> > > > Also, are you aware of app that heavily depend on the buffer storage<br>
> > > > extension?<br>
> > > ><br>
> > ><br>
> > > <a href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/109" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/109</a><br>
> ><br>
> > ><br>
> > ><br>
> > > > ><br>
> > > > > 1) Single process, host GL drivers (normal QEMU) -- yes, I think<br>
> > > > > RESOURCE_CREATE_BLOB here[1] should do the trick.  A bunch of<br>
> > > > virglrenderer<br>
> > > > > cleanups need to land first though.<br>
> > > > Thanks for the pointer, I will have a look to drm then.<br>
> > > > Do you have that cleanup already? I can help for the review if so.<br>
> > > ><br>
> > ><br>
> > > Chia has wip MR here:<br>
> > ><br>
> > > <a href="https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/364" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/364</a><br>
> ><br>
> > Thanks, I will see if I can help there.<br>
> > ><br>
> > ><br>
> > > ><br>
> > > > > 2) multi-process, host GL drivers (vhost-user gpu) -- trickier, need<br>
> > > > > emulated coherent memory [2] for the general case.<br>
> > > > > 3) multi-process, host GLES drivers (crosvm) -- even trickier and<br>
> > driver<br>
> > > > > specific, since GLES doesn't have GL_MAP_COHERENT_BIT.<br>
> > > > ><br>
> > > > > [1]<br>
> > > > ><br>
> > > ><br>
> > <a href="https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/virtio-gpu-next" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/virtio-gpu-next</a><br>
> > > > > [2]<br>
> > > ><br>
> > <a href="https://lists.freedesktop.org/archives/dri-devel/2019-April/215731.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/dri-devel/2019-April/215731.html</a><br>
> > > > ><br>
> > > > > Thanks, have a nice day,<br>
> > > > > > Elie<br>
> > > > > > _______________________________________________<br>
> > > > > > virglrenderer-devel mailing list<br>
> > > > > > <a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a><br>
> > > > > > <a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a><br>
> > > > > ><br>
> > > ><br>
> > _______________________________________________<br>
> > virglrenderer-devel mailing list<br>
> > <a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a><br>
> > <a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a><br>
> ><br>
</blockquote></div></div>
_______________________________________________<br>
virglrenderer-devel mailing list<br>
<a href="mailto:virglrenderer-devel@lists.freedesktop.org" target="_blank">virglrenderer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel</a><br>
</blockquote></div></div>