On Thu, Aug 3, 2017 at 2:34 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > Quoting Daniel Vetter (2017-08-03 13:05:29) >> Back when we used cs flips it made sense to go through different >> engines, since a buffer busy on an engine that we couldnt' use for >> cs flipping ended up in different paths. >> >> But with atomic we use a worker for all flips, and going through the >> combinatorial growth of engines just wastes precious machine time. >> More so the more modern the platform is. > > Then test against all engines simultaneously. What's the benefit of that? Just making sure that we handle multiple dma_fence on the same obj/fb? Afaics the current test doesn't do that either. >> Of course gem tests should still do some diagonal testing across all >> engines, but the kms side can afford to be a bit cheaper. > > kms has a separate waiting interface, it would be prudent to not assume > that coverage elsewhere gives coverage of kms. Note also that kms has a > number of special paths for domain handling which require care and > attention. Again, sounds like a neat extension of test coverage, but I'm just aiming to make the current coverage more efficient in terms of machine time used. Atm kbl takes 15' longer than hsw, and these kms_busy tests are a big chunk of that (another one is that somehow everything related to modeset just takes a bit longer, the final one is that kbl has more features, so skips less). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
