[virglrenderer-devel] GL_ARB_buffer_storage implementation

Tue Apr 21 16:11:05 UTC 2020

On Fri, Apr 17, 2020 at 4:15 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
>
> Out of curiousity, do you started working on this subject?
> If yes, do you have a branch somewhere?
> I would be happy to help if needed.
>
>
I haven't started the work to make Vk/GL interoperate in the multiprocess
case (will get to it soon), but we can trace the basic idea that the
Android Emulator uses in here:

1. When the guest does vkAllocateMemory that's external and therefore
potentially interoperable with GL:

https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android/android-emugl/host/libs/libOpenglRender/vulkan/VkDecoderGlobalState.cpp#2499

create a canonical memory object in a globally visible instance, and keep a
registry of "ColorBuffers" (representing external Vk/GL objects) up to date
with the new memory. Then create a GL external object that imports that
memory:

https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android/android-emugl/host/libs/libOpenglRender/vulkan/VkCommonOperations.cpp#1330
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android/android-emugl/host/libs/libOpenglRender/ColorBuffer.cpp#940

2. That is already what the android emulator uses to support external
memory and gl interop in the single process case; to extend to multi
process, it should be straightforward to put those behind fd's obtained
from other processes, but it has not yet been proven.

> Thanks and have a nice week-end.
> Elie
> >
> >
> > > >
> > > > 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20200421/9e1bad81/attachment.htm>