[Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

[Abdiel Janulgue]

On 10/13/2016 06:17 PM, Daniel Vetter wrote:
> On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote:
>> On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote:
>>>
>>>
>>> On 10/12/2016 03:07 PM, Chris Wilson wrote:
>>>> On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote:
>>>>> Signed-off-by: Abdiel Janulgue <abdiel.janulgue at linux.intel.com>
>>>>> ---
>>>>>  tests/gem_wait.c | 77 +++++++++-----------------------------------------------
>>>>>  1 file changed, 12 insertions(+), 65 deletions(-)
>>>>
>>>> We can do so much better than a dummy load here. We can precisely
>>>> control how long we want the object to be busy by using a recursive
>>>> batch buffer (and terminating that batch at the exact moment we require).
>>>> -Chris
>>>>
>>> Hi Chris, I see you've posted a better solution to gem_wait. I could
>>> drop this one and defer to yours instead. So for now, igt_dummyload has
>>> dropped to only 1 customer at the moment: kms_flip.  Let me know whether
>>> it's possible to upstream this dummyload api.
>>
>> kms_flip would probably be better with a specific load rather than a
>> dummy as well. The challenge is whether the flip works given various
>> input states of the framebuffers, and the more control we have over
>> those inputs the better.
> 
> Oh yeah, this is a pretty sweet idea with a spinning batch that we
> manually terminate. Assuming it works everywhere I think this is a much
> better approach, and by submitting different workloads we can always put
> the delay workload exactly where we want.
> 
> Abdiel, can you pls update the JIRA to instead extract Chris' trick into a
> library (pretty sure Chris can help with bikeshedding the interface to
> make it all pretty) and then roll that one out? Being able to control the
> time used by delay tasks down to jiffies is real sweet.

Ok I'll try that. Thanks!

-Abdiel

> 
> Also there might be some space to reuse this with Mika's hangcheck stuff,
> not sure.
> -Daniel
>