One of the irritating parts of deqp testing in our CI is that
deqp-runner has only been able to invoke one deqp binary per
deqp-runner invocation, which meant that we have to split out each of
deqp-gles*, deqp-egl, and glcts into different CI jobs, producing a
whole lot of output for devs to review when things go wrong (or for me
to review when trying to find slow testcases to optimize).  It also
wastes hardware time bringing up the test environment for each CI job,
and makes job tuning to meet our ~10-minute runtime goal a lot of
fuss.

So, I'm adding support to deqp-runner to describe a test suite in a
toml file and have it run all the deqp-*s in parallel.  I'm already
enjoying it for doing full, quick softpipe CTS runs locally.  I'm
hoping to merge it next week when I get back from camping, so I
thought I'd put the MR up here for feedback on the interface:

deqp-runner code:
https://gitlab.freedesktop.org/anholt/deqp-runner/-/merge_requests/14

Mesa commit showing its use:
https://gitlab.freedesktop.org/anholt/mesa/-/commit/8c70ab9a9e285882ec9740f1a1f058b3135c5ee9

Test Mesa pipeline:
https://gitlab.freedesktop.org/anholt/mesa/-/pipelines/365283

Should any of the toml keys be renamed?  Should anything else be in
command line args? Do we need toml top-level settings for "apply this
to all the [[deqp]]s"?  Should I bite the bullet and let you do both
deqp and piglit in the same suite config (new runner binary?)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to