[virglrenderer-devel] GL_ARB_buffer_storage implementation

[Elie Tournier]

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?
Also, are you aware of app that heavily depend on the buffer storage extension?

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

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