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.janul...@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!


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

Reply via email to