[virglrenderer-devel] dEQP-GLES3.functional.shader_api.program_binary.* support

[Elie Tournier]

On Fri, Nov 23, 2018 at 11:24:05AM +1000, Dave Airlie wrote:
> On Thu, 22 Nov 2018 at 10:29, Gurchetan Singh
> <gurchetansingh at chromium.org> wrote:
> >
> > On Wed, Nov 21, 2018 at 4:17 PM Elie Tournier <tournier.elie at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm working on reducing the number of "Not Supported" tests when running the CTS in the guest.
> > > I just come across the dEQP-GLES3.functional.shader_api.program_binary.* case.
> > > We currently do not support any binary format (GL_NUM_PROGRAM_BINARY_FORMATS = 0),
> > > so tests are tagged as "Not Supported".
> > >
> > > This feature was invented in order to be able to cache the result of the program linking.
> > > But it's not applicable to virglrenderer as we left the compilation process before the linker.
> > > However, we can still share binaries provided by the app with the host.
> > >
> > > So my question is:
> > > Is this a feature that you want to see in virglrenderer or can we skip it for now?
> >
> > Skip for now.  From the ChromiumOS perspective, here are the things
> > we're focusing on:
> >
> > 1) Improve performance for the average user while still maintaining correctness
> > 2) Vulkan (not too much progress lately, but maybe working on (1) will
> > inform this)
> > 3) Code quality
> 
Hello Gurchetan,

First of all, thanks for your reply. Currently, we are working on 1 and 3 too,
and we are also investigating misrendering issues in some applications
like, e.g. supertuxkart [1].

Concerning Vulkan support, it's not completely clear what's its priority
for you compared to the other items.
Our current understanding is that improving performance and security of virgl
has top priority and Vulkan comes after this.
Is Vulkan support something that you would like worked on in parallel to
the virgl improvements?

Another unclear point is whether Google is primarily interested in
(1) virtualizing Vulkan guest applications
or (2) providing a Vulkan backend for virglrenderer
(i.e., essentially implementing Gallium on the host with Vulkan), or both.

For (1), supporting Vulkan in virgl is certainly an option and has some benefits,
like the opportunity to reuse some buffer management code.
However, most code is GL specific, so significant work would be required to
support Vulkan and it's debatable whether making an already complex host-side
project even more complex is the best way forward.
An alternative approach for this could be to have a separate,
leaner project just for Vulkan support, free of GL baggage and assumptions,
and which would also allow us to move away from the C heritage of virgl if so desired.

Relatedly, in the future we could go one step further and use Zink [2]
as a frontend to convert the OpenGL calls in the guest to Vulkan ones.
This approach has many potential benefits in terms of simplicity and security,
since it moves a lot of the complexity to the guest.
The feasibility of this design depends on the performance of Zink,
which is still WIP, although improving steadily.
Of course, the downside is that, in such a design, vulkan host support
is required even for GL apps, which may not be possible on older systems.

[1] https://gitlab.freedesktop.org/virgl/virglrenderer/issues/59
[2] https://gitlab.freedesktop.org/kusma/mesa/tree/zink

> I don't think we want this, though I think we could plug in the TGSI
> serialisation cache at least, which would avoid some GLSL overheads in
> the guest, but I wouldn't involve the host in this at all.
> 
We can definitely work on that. Optimisations are always welcome. ;)
I add this task to the Collabora TODO list.

Sorry for the long email.
Happy thanksgiving.

Elie

> Dave.
> 
> >
> > >
> > > To my point of view, it is not a good idea as this will compromise the security
> > > of the project. More over, if we still want to implement it, the chance that
> > > the binary provided by the app will be execute in the host is quite low as
> > > the existing drivers consider the HW information and config
> > > (say old kernel lacking feature X) when generating a unique device id.
> > > If that one didn't matches, the cache is not reused.
> > >
> > >
> > > 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