On Wed, May 19, 2021 at 09:13:37AM +0100, Matthew Auld wrote: > On Tue, 11 May 2021 at 17:52, Matthew Auld <matthew.auld@xxxxxxxxx> wrote: > > > > Just the really basic stuff, which unlocks adding more interesting testcases > > later, like gem_lmem_swapping. > > > > On the kernel side we landed the uAPI bits[1] behind CONFIG_BROKEN, which is > > already enabled in CI builds, so it should be possible to get some more BAT > > testing(outside of just the selftests) on DG1 to the point where we can start to > > exercise the LMEM paths with the new bits of uAPI. > > > > [1] https://patchwork.freedesktop.org/series/89648/ > > Petri, any thoughts on this series? As an initial step we just need > some way to start exercising the new bits of uAPI, and from that we > can add more interesting test cases. This series is in a confused state. First there's the addition of local definitions and ioctl tokens, then they are replaced with the proper stuff... When this was starting to get developed the idea was to avoid icky cases that break _testing_. Not tests, testing. Remember when engine discovery was being developed and we had cases where for_each_engine loop didn't progress, causing stuff like for_each_engine(...) igt_subtest(...) to never enter a subtest? Pushing for stubbing memory regions ultimately wanted to avoid cases where for_each_combination(memregions) breaks test enumeration. It all boils down to: Can that break? Can we have cases where the query gives garbage? Can it give two million smem regions? Can it give 0 regions, or -1 regions? And what happens then? Is it just gem_create_ext that's hiding behind CONFIG_BROKEN or also the querying? -- Petri Latvala _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
