Message ID | 1439497901-14310-7-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote: > Need some LRC tests in the 'basic' subset, and this is a good simple > one. > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> This is just a testcase for a very specific lrc corner case. We do already exercise lrc with all the other execbuf testcases. Imo we're covered enough already with what we have in the basic testset - testing for all 3 billion cornercases will make it grow out of scope I fear. I'd just drop this one here as not needed for BAT. If you want to extend execbuffer scope a bit then we should add a concurrency test, i.e. one of the gem_concurrent_blt testcases as basic ones. Unfortunately to be able to reliable trigger race conditions those all take a few seconds. But inter-batch sync is a _big_ gap across all archs, and something which is even more tricky with lrc (and scheduler). Imo that would be a lot more useful than this test here. -Daniel > --- > tests/gem_ctx_exec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c > index 3df939c..ea0fb7f 100644 > --- a/tests/gem_ctx_exec.c > +++ b/tests/gem_ctx_exec.c > @@ -216,7 +216,7 @@ igt_main > gem_context_destroy(fd, ctx_id); > } > > - igt_subtest("lrc-lite-restore") { > + igt_subtest("basic-lrc-lite-restore") { > int i, j; > > /* > -- > 1.9.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 08/14/2015 05:32 AM, Daniel Vetter wrote: > On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote: >> Need some LRC tests in the 'basic' subset, and this is a good simple >> one. >> >> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > This is just a testcase for a very specific lrc corner case. We do already > exercise lrc with all the other execbuf testcases. Imo we're covered > enough already with what we have in the basic testset - testing for all 3 > billion cornercases will make it grow out of scope I fear. I'd just drop > this one here as not needed for BAT. > > If you want to extend execbuffer scope a bit then we should add a > concurrency test, i.e. one of the gem_concurrent_blt testcases as basic > ones. Unfortunately to be able to reliable trigger race conditions those > all take a few seconds. But inter-batch sync is a _big_ gap across all > archs, and something which is even more tricky with lrc (and scheduler). > Imo that would be a lot more useful than this test here. Yeah that's a good point; I just saw 'lrc' and though "I want that", but you're right we should already be covered. Definitely open to adding some concurrency stuff (maybe just a few seconds worth) as we get things in place. I'll drop this one. Jesse
On Fri, Aug 14, 2015 at 08:31:01AM -0700, Jesse Barnes wrote: > On 08/14/2015 05:32 AM, Daniel Vetter wrote: > > On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote: > >> Need some LRC tests in the 'basic' subset, and this is a good simple > >> one. > >> > >> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > > > This is just a testcase for a very specific lrc corner case. We do already > > exercise lrc with all the other execbuf testcases. Imo we're covered > > enough already with what we have in the basic testset - testing for all 3 > > billion cornercases will make it grow out of scope I fear. I'd just drop > > this one here as not needed for BAT. > > > > If you want to extend execbuffer scope a bit then we should add a > > concurrency test, i.e. one of the gem_concurrent_blt testcases as basic > > ones. Unfortunately to be able to reliable trigger race conditions those > > all take a few seconds. But inter-batch sync is a _big_ gap across all > > archs, and something which is even more tricky with lrc (and scheduler). > > Imo that would be a lot more useful than this test here. > > Yeah that's a good point; I just saw 'lrc' and though "I want that", but > you're right we should already be covered. Definitely open to adding > some concurrency stuff (maybe just a few seconds worth) as we get things > in place. For concurrency mabye we can do that in a 2nd round - we need to go over gem_concurrent_* anyway and reshuffle that one into basic, full and subtests that we're only going to expose through cmdline options for manual testing. Atm there's way too many of those tests. -Daniel
diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c index 3df939c..ea0fb7f 100644 --- a/tests/gem_ctx_exec.c +++ b/tests/gem_ctx_exec.c @@ -216,7 +216,7 @@ igt_main gem_context_destroy(fd, ctx_id); } - igt_subtest("lrc-lite-restore") { + igt_subtest("basic-lrc-lite-restore") { int i, j; /*
Need some LRC tests in the 'basic' subset, and this is a good simple one. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- tests/gem_ctx_exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)