[virglrenderer-devel] Guest chosen host context types

Elie Tournier tournier.elie at gmail.com
Tue Jul 10 13:13:27 UTC 2018

On Tue, Jul 10, 2018 at 08:53:14AM +1000, Dave Airlie wrote:
> > So currently we have a couple of bugs and a fairly big pile of code related
> > to various texture formats that are not supported by the core GL context but
> > is needed to support GLES and compatibility GL. For instance alpha and
> > luminescence.
> >
> > So my thought was that he guest could mark a context as a GLES context and
> > the host would then create GLES context on the host and have those formats
> > supported without any workarounds.
> >
> > Now I'm guessing there are several things that will go wrong with trying to
> > mix GLES and D-GL (Desktop GL) in virgl. Sharing textures will need to be
> > worked around. Format table and some have_foo needs to be per-context. Caps
> > will probably be made per context type. And a whole bunch of other things
> > might explode.
> >
> > That said a lot of these things will probably have to be solved if we ever
> > want to do vulkan virgl. So maybe we can do a bunch of ground work and
> > experiment with GLES vs D-GL without having to deal with Vulkan on top of
> > all that.
> >
> > Initially just opening a Vulkan Device, allocating all resources from it and
> > importing them into D-GL and GLES would enable sharing between the different
> > profiles at least. And be something we could build Vulkan support on top of.
> >
> > Thoughts and comments, please?
> I've no major objections, but it's going to be churny. I wonder do we need to
> try and get GLES3.1 merged first, and maybe cut a release before taking
> something like this on.

Yes, I would like to see a release too.
Distro will start shipping a new enough QEMU with GLES support in SDL but
virglrenderer will be too old to support this feature.

> For vulkan we'd have to route at least all shared object allocs via vulkan
> memory allocation, the question for GL vs GLES is what would context 0
> need to be.

Dave, do you follow the GSoC about vulkan virgl?
He maybe started the routing process. Dunno.
I have to admit that I don't follow his work. /me is grimacing.
> I'd really like to minimise these "fourth wall" breaches though, exposing
> the host stack internals to the guest makes me weary exposing host
> contexts made me annoyed but GL couldn't do certain things without them
> (like transform feedback).
> I expect I'd need to see the solution is better than the problem :-) I don't
> even think in gallium we have the info to know if we want a GLES or GL
> context at that level.
> Dave.
> _______________________________________________
> 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