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

[Gurchetan Singh]

On Fri, Nov 23, 2018 at 10:00 AM Elie Tournier <tournier.elie at gmail.com> wrote:
>
> 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?

If all tasks related to virgl performance + security are being worked
on, then the next focus area should be Vulkan.

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

Both, though we're more likely to focus our efforts on (1) since
virglrenderer already provides a virtualized GL solution.  Virtualized
Vulkan will be a hard requirement not too long from now.

With Zink, there's been really good progress on (2).   I want to see a
FOSS project for (1) though too.

Zink + virtualized Vulkan conceptually sounds like the best solution
in the long term.

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

It looks like there are some ambiguities related to how we should procede.

a) Should this virtualized Vulkan project be apart of Mesa and virglrenderer?

My opinion -- In the long term, yes.  virglrenderer could be the
container of multiple virtualized libraries, like Mesa contains
multiple graphics drivers.

For now, a separate project SGTM.  We could add bindings in Mesa and
virglrenderer later.

I suspect we may have to alter how virtio-gpu works (is one virtio
queue enough when we have multiple threads generating multiple command
buffers?).

Right now, a guest library + host library + sockets in between (like
vtest) is a great place to start.

b) Which language should we use?

My opinion -- Rust.  It has compile-time ownership semantics, a strong
standard library (I assume we won't rely on src/util/ in Mesa
anymore), idiomatic coding conventions, and much more.  In my
experience, C developers can pick up the language in 2-3 weeks and are
pleasantly surprised at it's features.  The downside with Rust is
Vulkan code generation utilities were designed with C/C++ in mind.

What does Collabora / Red Hat think about these questions?