Quoting Daniel Vetter (2017-08-03 16:17:57) > 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. We increase the potential source for errors, keep the cursory check that any engine can generate content for a flip, and all without adding any significant time (a couple of extra microseconds to submit, 10us to handle the extra interrupts). > >> 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. Indeed, so use all engines instead of an arbitrary choice. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
