[virglrenderer-devel] GL_ARB_buffer_storage implementation

Tue May 12 00:16:59 UTC 2020

On Mon, May 11, 2020 at 5:14 PM Gurchetan Singh <gurchetansingh at chromium.org>
wrote:

>
>
> On Mon, Apr 13, 2020 at 3:46 AM Elie Tournier <tournier.elie at gmail.com>
> wrote:
>
>> On Wed, Apr 01, 2020 at 07:50:37AM -0700, Frank Yang wrote:
>> > On Wed, Apr 1, 2020 at 4:03 AM Elie Tournier <tournier.elie at gmail.com>
>> > wrote:
>> >
>> > > On Tue, Mar 31, 2020 at 04:54:12PM -0700, Gurchetan Singh wrote:
>> > > > On Mon, Mar 30, 2020 at 10:49 AM Elie Tournier <
>> tournier.elie at gmail.com>
>> > > > wrote:
>> > > >
>> > > > > On Fri, Mar 27, 2020 at 05:10:43PM -0700, Gurchetan Singh wrote:
>> > > > > > On Wed, Mar 25, 2020 at 5:17 AM Elie Tournier <
>> > > tournier.elie at gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi all,
>> > > > > > >
>> > > > > > > I'm currently working on OpenGL 4.5 support for virgl.
>> > > > > > > For that, we need to implement ARB_clear_texture and
>> > > > > ARB_buffer_storage.
>> > > > > > > The first one is almost finish, and I should submit a MR
>> soon-ish.
>> > > > > > > The second one, ARB_buffer_storage is trickier to implement.
>> > > > > > >
>> > > > > > > So I'm wondering if any of you started something already?
>> > > > > > > Do you have a design in mind?
>> > > > > > >
>> > > > > >
>> > > > > > Hmm, depends on where you want to implement ARB_buffer_storage:
>> > > > > I mean, the goal here is to help the project to going further.
>> > > > > It seems that you started (1) but I guess you are interested by
>> (3).
>> > > > > Would it make sense to go gradually and do (1) -> (2) -> (3) as
>> > > > > iiuc, we can reuse bits from the previous iteration?
>> > > >
>> > > >
>> > > > (1) should work pretty easily, since we got dEQP-vk.memory.* working
>> > > [with
>> > > > Android Emulator VK impl].
>> > >
>> > > Does that mean the QEMU part is already in place?
>> > >
>> >
>> > Hi, not necessarily; I've been the one trying that dEQP-VK.memory* out
>> and
>> > I only have patches for crosvm so far:
>> >
>> >
>> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034029
>> >
>> https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035595
>> >
>> > (which I'll get back to soon, hopefully this week, as I was busy w/
>> R-CTS
>> > stuff)
>> >
>> > The same mechanism should work for coherent mem in GL though. I need to
>> do
>> > some experiments for (2) to see if EXT_external_objects works
>>
>> That's an amazing news.
>>
>> On my side, I will modify QEMU to be on par with the work done on drm.
>> ie be able to use RESOURCE_CREATE_BLOB.
>>
>
> Have you had any luck on this?  If not, perhaps Gerd/Dave/other QEMU devs
> can offer hints/strawman code on how to proceed.
>
> Problem:
>
> I was taking a look at QEMU and it's non-obvious to me how to implement
> RESOURCE_MAP / RESOURCE_UNMAP.
>
> For GL_ARB_buffer_storage, virglrenderer can provide a page-aligned
> address (seems to work even on Nvidia) for use with KVM:
>
>
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/374/diffs#14086999aaf57fc68a3d7d639ab280c3a2672430_603_670
>
> We need to figure out a way to call kvm_region_add / kvm_region_del
> from virtio-gpu-3d.c with this address.
>
> For crosvm, it's easy since it's designed to sit directly on top of KVM.
> With QEMU, there are several layers of abstraction.
>
> 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 ...
>
> memory_device_plug(..) seems interesting too, but I don't see a path to
> KVM, but then again, I'm a QEMU noob.
>
>

To address the overhead/complexity issue of going through the memory region
/ listener api in QEMU, we chose to

- only use them for the PCI memory region
- not have actual memory backing it to start with
- user controls the backing at runtime

https://android-review.googlesource.com/q/topic:%22qemu-user-controlled-hv-mappings%22+(status:open%20OR%20status:merged)

> >
>> >
>> > > >
>> > > > I think the trickiest part of the entire chain is (3) [it sounds
>> like
>> > > this
>> > > > your end goal too?].  In particular, the lack of GLES coherent
>> support
>> > > ...
>> > > > I think we may need to add some extensions or extend
>> > > EXT_external_objects.
>> > > > A good place to start is a feasibility study about such extensions,
>> or
>> > > > auditing your target drivers (i965?).
>> > >
>> > > Yes, my end goal is that all virglrenderer user should be able to
>> expose
>> > > OpenGL 4.5 on the guest side. But for now, (1) seems to be the best
>> option.
>> > >
>> > > I'm not familiar with EXT_external_objects but I'm more in favor of a
>> new
>> > > extension.
>> > > And yes, you guess right, I'm on i965/iris drivers so that's what I
>> target
>> > > for now.
>> > >
>> > > I will keep you updated.
>> > > >
>> > > >
>> > > > > Also, are you aware of app that heavily depend on the buffer
>> storage
>> > > > > extension?
>> > > > >
>> > > >
>> > > > https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/109
>> > >
>> > > >
>> > > >
>> > > > > >
>> > > > > > 1) Single process, host GL drivers (normal QEMU) -- yes, I think
>> > > > > > RESOURCE_CREATE_BLOB here[1] should do the trick.  A bunch of
>> > > > > virglrenderer
>> > > > > > cleanups need to land first though.
>> > > > > Thanks for the pointer, I will have a look to drm then.
>> > > > > Do you have that cleanup already? I can help for the review if so.
>> > > > >
>> > > >
>> > > > Chia has wip MR here:
>> > > >
>> > > >
>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/364
>> > >
>> > > Thanks, I will see if I can help there.
>> > > >
>> > > >
>> > > > >
>> > > > > > 2) multi-process, host GL drivers (vhost-user gpu) -- trickier,
>> need
>> > > > > > emulated coherent memory [2] for the general case.
>> > > > > > 3) multi-process, host GLES drivers (crosvm) -- even trickier
>> and
>> > > driver
>> > > > > > specific, since GLES doesn't have GL_MAP_COHERENT_BIT.
>> > > > > >
>> > > > > > [1]
>> > > > > >
>> > > > >
>> > >
>> https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/virtio-gpu-next
>> > > > > > [2]
>> > > > >
>> > >
>> https://lists.freedesktop.org/archives/dri-devel/2019-April/215731.html
>> > > > > >
>> > > > > > Thanks, have a nice day,
>> > > > > > > Elie
>> > > > > > > _______________________________________________
>> > > > > > > virglrenderer-devel mailing list
>> > > > > > > virglrenderer-devel at lists.freedesktop.org
>> > > > > > >
>> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>> > > > > > >
>> > > > >
>> > > _______________________________________________
>> > > virglrenderer-devel mailing list
>> > > virglrenderer-devel at lists.freedesktop.org
>> > > https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>> > >
>>
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20200511/652b57ff/attachment-0001.htm>