On Wed, 19 May 2021 at 09:49, Petri Latvala <petri.latvala@xxxxxxxxx> wrote: > > 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... Yeah, I think that's how it is internally. Maybe the idea with that was to somehow land the igt changes first, before the kernel stuff potentially landed? I can clean this up and just start 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? On integrated platforms it can only return one region: smem. If we somehow don't have a smem region then the i915 module load would have failed, since we must have been unable to populate the i915->mm.regions. On DG1 we just get the extra lmem region, and for Xe HP multi-tile we get a few more lmem regions, but again if we can't populate the i915->mm.regions with the required regions then we fail driver init. The only "optional" region is stolen memory, but for that we don't expose it to userspace. The query will fail on !CONFIG_BROKEN kernels though, where it just returns -ENODEV, or of course some other error if the user provided an invalid query. > > Is it just gem_create_ext that's hiding behind CONFIG_BROKEN or also > the querying? It's the region query, and specifically the placements extension in gem_create_ext, since there is also pxp coming soon and for that we don't need CONFIG_BROKEN. > > > -- > Petri Latvala _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
