With new veto our new veto test results look like the following:
TP: true positive (picked to use gpu and gpu was faster)
I: inderminate, the raster time is withing 5% of gpu time
TP FP TN FN I
old 21 9 15 12 3
new 29 12 11 6 3
There are three skps that tend to move from TN -> FP, however
the absolute difference in their run times are not huge between
them. The largest being desk_booking which is about 7.1 raster
and 8.8 gpu. The other two skps are desk_yahooanswers and
desk_linkedin
BUG=skia:
R=bsalomon@google.com, robertphillips@google.com
Author: egdaniel@google.com
Review URL: https://codereview.chromium.org/334053005
This CL just sketches out the structure of the gpuveto testing process. Two big areas for improvement are:
render the picture in tiles and label as unsuitable if any gpu tile is slower than raster
decide on whether tilegrid is used or not
As expected the current gpuveto heuristic isn't so good:
predicted suitable unsuitable
-------------------------------------------
actual suitable 10 17
actual unsuitable 15 27
R=rmistry@google.com, bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/257723003
git-svn-id: http://skia.googlecode.com/svn/trunk@14416 2bbb7eff-a529-9590-31e7-b0007b416f81
