Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Daniel Vetter
On Wed, Apr 16, 2014 at 7:47 AM, Yang, Guang A guang.a.y...@intel.com wrote: Ok there are a few cases where we can indeed make tests faster, but it will be work for us. And that won't really speed up much since we're adding piles more testcases at a pretty quick rate. And many of these new

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Yang, Guang A
I think stopping the tests after 10 minutes is ok, but in general the point of stress tests is to beat on the kernel for corner cases. E.g. even with todays extensive set of stress tests some spurious OOM bugs can only be reproduced in 1 out of 5 runs. Reducing the test time could severely

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Jesse Barnes
On Tue, 15 Apr 2014 19:17:59 +0200 Daniel Vetter daniel.vet...@intel.com wrote: Ok there are a few cases where we can indeed make tests faster, but it will be work for us. And that won't really speed up much since we're adding piles more testcases at a pretty quick rate. And many of these new

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Daniel Vetter
On 16/04/2014 17:42, Jesse Barnes wrote: On Tue, 15 Apr 2014 19:17:59 +0200 Daniel Vetter daniel.vet...@intel.com wrote: Ok there are a few cases where we can indeed make tests faster, but it will be work for us. And that won't really speed up much since we're adding piles more testcases at a

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Damien Lespiau
On Wed, Apr 16, 2014 at 08:42:27AM -0700, Jesse Barnes wrote: And can you elaborate on the CRC tests? It doesn't seem like those should take more than a few frames to verify we're getting what we expect... Indeed, if the CRC tests take a long time, that's a bug (for instance we may never

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-16 Thread Ville Syrjälä
On Wed, Apr 16, 2014 at 05:50:20PM +0200, Daniel Vetter wrote: On 16/04/2014 17:42, Jesse Barnes wrote: On Tue, 15 Apr 2014 19:17:59 +0200 Daniel Vetter daniel.vet...@intel.com wrote: Ok there are a few cases where we can indeed make tests faster, but it will be work for us. And that

[Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-15 Thread Yang, Guang A
Hi all, I have discussed with Daniel about the running time for each cases before and we set the standard as 10M, if one can’t finish after running 10M we will see it as Timeout and report bug on FDO(such as : Bug 77474https://bugs.freedesktop.org/show_bug.cgi?id=77474 -

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-15 Thread He, Shuang
Chated with Ben last week about this It may be feasiable to have a fast.tests for intel-gpu-tools also Thanks --Shuang From: Yang, Guang A Sent: Tuesday, April 15, 2014 11:46 PM To: Vetter, Daniel; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin, Gordon; OTC GFX QA Extended;

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-15 Thread Daniel Vetter
On 15/04/2014 17:46, Yang, Guang A wrote: Hi all, I have discussed with Daniel about the running time for each cases before and we set the standard as 10M, if one can’t finish after running 10M we will see it as Timeout and report bug on FDO(such as : Bug 77474

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-15 Thread He, Shuang
From: Vetter, Daniel Sent: Wednesday, April 16, 2014 1:18 AM To: Yang, Guang A; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin, Gordon; OTC GFX QA Extended; intel-gfx@lists.freedesktop.org; Parenteau, Paul A; Nikkanen, Kimmo Subject: Re: The whole round of i-g-t testing cost too long

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

2014-04-15 Thread Yang, Guang A
Ok there are a few cases where we can indeed make tests faster, but it will be work for us. And that won't really speed up much since we're adding piles more testcases at a pretty quick rate. And many of these new testcases are CRC based, so inheritely take some time to run. [He, Shuang] OK, so