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

[Gurchetan Singh]

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

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