New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 894466 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
pwang@chromium.org
█ marc...@chromium.org
█ chadversary@chromium.org
ihf@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Investigate eliminating process startup from dEQP

Project Member Reported by gurcheta...@chromium.org, Oct 11 
Our current dEQP script:

https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/site_tests/graphics_dEQP/graphics_dEQP.py

starts dEQP every-time with "--deqp-case=".  This causes dEQP to do a bunch of initialization (loading shaders, generating configs etc. etc.)  It also spawns a new process on every single run.


In my experience, running deqp-gles2 takes 1 hour and running deqp-gles3 takes 3 hours.  Our friends at Collabora apparently have a script that runs dEQP in 9 minutes:


https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/49


We should investigate if doing '--deqp-caselist' or '--deqp-caselist-file' can improve timing.  We should also determine how we're starting dEQP when running on Android, as that takes many hours as well.

Comment 1 by ihf@chromium.org, Oct 11

Components: OS>Kernel>Graphics
Labels: Gfx-Guard
So we run control.vk-master with hasty=true (=fast) because it is stable when we do that.

It used to be that for gles* hasty=true would cause flakes and cascading failures. If that is fixed, we could flip the flag.

A main problem with hasty is that the batch sizes are not precisely 1000 as in tradefed runs. But if the Collabora folks have fixed the issues we should of course take their solution.
►

Sign in to add a comment