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

[Robert Foss]

On 2018-11-26 19:54, Gurchetan Singh wrote:
> 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.

That sounds like a neat long-term solution. A project like Zink
would fit neatly in both mesa and virglrenderer, so making sure
it is going to integrate well with both is something we could have in mind
from now on.

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

I'm no Rust programmer but moving new projects to Rust does seem like a good 
idea, where possible.

> 
> What does Collabora / Red Hat think about these questions?
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>