Alyssa Rosenzweig <aly...@rosenzweig.io> writes: >> We start by building a container in Docker that contains a suitable >> rootfs and kernel for the DUT, deqp and all dependencies for building >> Mesa itself. > > Out of curiosity, what's the performance impact of this? If there are no > changes to the kernel or to deqp (but mesa had a commit somewhere in > Panfrost space), do we have to rebuild the former two? Does ccache maybe > pick that up? I'm trying to get a sense for how long it takes between > pushing a commit and getting a CI answer, and maybe if that can be > shortened. > >> the expectations that are stored >> in git. > > Might it be better to track this outside so we don't pollute mesa with > changes to that largely autogenerated file? Or I guess that's > problematic since then we lose branch information / etc.
Hopefully just current expected fails get stored in git. > Is there an automated way to do this based on the results of LAVA/CI? >> + git clone --depth 1 https://github.com/KhronosGroup/VK-GL-CTS.git . >> && \ > > Is this the right repo? I recall getting deqp source from Google's > servers (Chromium git). I suppose it's the same. VK-GL-CTS is the official conformance suite, and it includes dEQP. You need to use a release tag, or you'll have extra garbage tests expecting nonstandardized behavior being run. Same for dEQP master.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
