[virglrenderer-devel] GL_ARB_buffer_storage implementation

Elie Tournier tournier.elie at gmail.com
Wed Apr 1 11:03:23 UTC 2020


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?
> 
> 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
> > > >
> >


More information about the virglrenderer-devel mailing list