[igt-dev] [PATCH] [PATCH i-g-t]tests/i915/gem_exec_create: Added __for_each_physical_engine to utilize all available engines.

[Ch, Sai Gowtham]

Hi Andi,Tvrtko ,

Could you please suggest me which would be the best way ?

Thanks,
Gowtham

-----Original Message-----
From: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> 
Sent: Friday, March 6, 2020 7:37 PM
To: Shyti, Andi <andi.shyti at intel.com>
Cc: Ch, Sai Gowtham <sai.gowtham.ch at intel.com>; Dec, Katarzyna <katarzyna.dec at intel.com>; igt-dev at lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH] [PATCH i-g-t]tests/i915/gem_exec_create: Added __for_each_physical_engine to utilize all available engines.


On 06/03/2020 11:22, Andi Shyti wrote:
> Hi Tvrtko,
> 
>>> After fork we need to transfer the engine map from parent fd default 
>>> context. (gem_context_copy_engines)
>>>
>>> Also, since we have __for_each_physical_engine in the top level 
>>> igt_fixture, I think _all_ subtests run with default ctx engine map. 
>>> So all which submit to one from either all_engines or ppgtt_engines 
>>> need to make sure engine maps are aligned.
>>>
>>> it was suggested by tvrtko in one of the patch: 
>>> https://patchwork.freedesktop.org/patch/351622/?series=72889&rev=1
>>
>> I was sadly wrong there, it is not required to reopen and copy 
>> engines after fork. So __for_each_physical_engine should do it in this case.
>>
>> Regards,
>>
>> Tvrtko
>>
>> P.S. You could also dynamically size (allocate) the engines array 
>> while at it to be more in line with the other recent cleanups.
>>
>> Hm.. actually, do we even need the array? Andi, 
>> __for_each_physical_engine will always create engine map with consecutive e->flags integers, right?
>> There can be no holes?
> 
> yes, you are right, we do not need in this case the array and there 
> shouldn't be holes, indeed.

Then the question is whether it is a good idea to rely on this from tests or not? I can't imagine a scenario where IGT couldn't create a map with no holes but maybe my imagination is bad.

Regards,

Tvrtko