Other GLES3 conformance tests require about the expected amount of time to run. This test, however, runs for epic time and eats all the CPU.
Mark: You may want to blacklist this test on SKL on Jenkins.
Ben / Sarah: Can one of you try to reproduce this on a local SKL and maybe do some initial analysis?
Also, is it better if bf58a2c362d5afdba512f40b3eb300154201c7f0 is reverted?
(In reply to Ian Romanick from comment #2)
> Also, is it better if bf58a2c362d5afdba512f40b3eb300154201c7f0 is reverted?
Yes, I've bisected that this commit makes test run considerably longer. It seems that it's not causing all the slowness though.
After upgrading kernel to 4.3 I haven't had this problem, from my POV this issue is fixed.
(In reply to Tapani Pälli from comment #4)
> After upgrading kernel to 4.3 I haven't had this problem, from my POV this
> issue is fixed.
Having said that it seems that the conformance runs on our CI system still take way too long time.
The CI is still running an old drm-nightly kernel. Recent attempts to update the kernel resulted in many regressions.
I'll make a note to try the 4.3 kernel when it is released.
this test currently takes 0.04 seconds on SKL in our CI.