| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | CLOSED |
Comment # 4
on bug 109303
from Martin Peres
(In reply to Chris Wilson from comment #3) > (In reply to Lionel Landwerlin from comment #2) > > (In reply to Martin Peres from comment #0) > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/ > > > igt@i915_query@query-topology-known-pci-ids.html > > > > > > Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || > > > IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid) > > > Subtest query-topology-known-pci-ids: SKIP (0.000s) > > > > > > I doubt that this would only be supported on these platforms and not on CNL > > > and ICL. > > > > It does only support haswell/gen8/gen9 because that's the only place where > > based off the GT we can deduct the number of slices/subslices and do some > > actual checks on the values returned by i915. > > On gen10+ fusing is a lot more fuzzy. > > > > One way to extend coverage would be to beef up lib/intel_device_info.c to > > contain information about the topology of the device. > > Not really, I think. The purpose of the topology i915_query is precisely to > retrieve the more flexible configurations that are not simply defined in > static pci-id tables. > > So long as we have sanity checks on the ioctl to catch garbage returns; > along with the static checks to make sure known configs are reported, that > seems like we have our boundary conditions covered. > > If were possible to use the topology and verify that matches hw, that would > be a useful test (I presume that would also closely match use). (In reply to Lionel Landwerlin from comment #2) > (In reply to Martin Peres from comment #0) > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/ > > igt@i915_query@query-topology-known-pci-ids.html > > > > Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || > > IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid) > > Subtest query-topology-known-pci-ids: SKIP (0.000s) > > > > I doubt that this would only be supported on these platforms and not on CNL > > and ICL. > > It does only support haswell/gen8/gen9 because that's the only place where > based off the GT we can deduct the number of slices/subslices and do some > actual checks on the values returned by i915. > On gen10+ fusing is a lot more fuzzy. > > One way to extend coverage would be to beef up lib/intel_device_info.c to > contain information about the topology of the device. > > Thoughts welcome. Thanks for the info! Maybe you could create a Jira to implement something like Chris is describing so we don't forget about this gap in coverage?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
