On 08/05/2019 12:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-08 11:29:34)
On 08/05/2019 09:06, Chris Wilson wrote:
+static int live_virtual_engine(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ unsigned int class, inst;
+ int err = -ENODEV;
+
+ if (USES_GUC_SUBMISSION(i915))
+ return 0;
+
+ mutex_lock(&i915->drm.struct_mutex);
+
+ for_each_engine(engine, i915, id) {
+ err = nop_virtual_engine(i915, &engine, 1, 1, 0);
+ if (err) {
+ pr_err("Failed to wrap engine %s: err=%d\n",
+ engine->name, err);
+ goto out_unlock;
+ }
+ }
+
+ for (class = 0; class <= MAX_ENGINE_CLASS; class++) {
+ int nsibling, n;
+
+ nsibling = 0;
+ for (inst = 0; inst <= MAX_ENGINE_INSTANCE; inst++) {
+ if (!i915->engine_class[class][inst])
+ break;
I previous review I said I think this should be continue instead of
break so vcs0 + vcs2 skus can also be tested.
Completely missed that, sorry.
+
+ siblings[nsibling++] = i915->engine_class[class][inst];
+ }
+ if (nsibling < 2)
+ continue;
And also that single engine VE could be tested just as well, unless I am
missing something.
There's no such thing as single engine VE. The current design requires
that this type of struct virtual_engine encompasses more than one engine
(failing that we break the single request scheduling, although might be
able to lift that with timeslicing but the early results were not
favourable); the single engine being a regular intel_context instance.
Yeah my bad, the auto-magic replacement with physical engine happens one
level higher than what this selftest is operating on.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
