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

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Thu Mar 19 07:06:14 UTC 2020


On 19/03/2020 03:55, Ch, Sai Gowtham wrote:
> Hi Andi,Tvrtko ,
> 
> Could you please suggest me which would be the best way ?

No reopen after fork and no need for the engines array - just 
s/engines[i]/i/ in the child.

Regards,

Tvrtko

> 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
> 
> 


More information about the igt-dev mailing list