[virglrenderer-devel] dEQP-GLES3.functional.shader_api.program_binary.* support
Dave Airlie
airlied at gmail.com
Fri Nov 23 01:24:05 UTC 2018
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
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.
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
More information about the virglrenderer-devel
mailing list