All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Tvrtko Ursulin <tursulin@ursulin.net>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel-gfx@lists.freedesktop.org,
	Nick Desaulniers <nick.desaulniers@gmail.com>
Subject: Re: [PATCH] drm/i915: Fix waiting for engines to idle
Date: Wed, 24 May 2017 14:39:48 +0300	[thread overview]
Message-ID: <87bmqitrej.fsf@intel.com> (raw)
In-Reply-To: <9fb57e39-7364-d453-48bc-bec71086b7e2@linux.intel.com>

On Wed, 24 May 2017, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 23/05/2017 12:30, Jani Nikula wrote:
>> On Tue, 23 May 2017, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>>> On 23/05/2017 10:56, Jani Nikula wrote:
>>>> On Tue, 23 May 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>>>> On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>
>>>>>> Waiting for engines needs to happen even in the non-debug builds
>>>>>> so it is incorrect to wrap it in a GEM_WARN_ON.
>>>>>>
>>>>>> Call it unconditionally and add GEM_WARN so that the debug
>>>>>> warning can still be emitted when things go bad.
>>>>>>
>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>> Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()")
>>>>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>>>>> Cc: Daniel Vetter <daniel.vetter@intel.com>
>>>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>> Cc: intel-gfx@lists.freedesktop.org
>>>>>> Reported-by: Nick Desaulniers <nick.desaulniers@gmail.com>
>>>>>> Cc: Nick Desaulniers <nick.desaulniers@gmail.com>
>>>>>> ---
>>>>>>  drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>>>>>>  drivers/gpu/drm/i915/i915_gem.h | 2 ++
>>>>>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>>>>> index a637cc05cc4a..ecaa21f106c8 100644
>>>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>>>> @@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private *i915)
>>>>>>  	enum intel_engine_id id;
>>>>>>
>>>>>>  	for_each_engine(engine, i915, id) {
>>>>>> -		if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
>>>>>> +		if (wait_for_engine(engine, 50)) {
>>>>>> +			GEM_WARN(1, "%s wait for idle timeout", engine->name);
>>>>>
>>>>> Nice touching adding the engine->name
>>>>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>
>>>>>>  			i915_gem_set_wedged(i915);
>>>>>>  			return -EIO;
>>>>>>  		}
>>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
>>>>>> index ee54597465b6..cefc6cf96a60 100644
>>>>>> --- a/drivers/gpu/drm/i915/i915_gem.h
>>>>>> +++ b/drivers/gpu/drm/i915/i915_gem.h
>>>>>> @@ -30,6 +30,7 @@
>>>>>>  #ifdef CONFIG_DRM_I915_DEBUG_GEM
>>>>>>  #define GEM_BUG_ON(expr) BUG_ON(expr)
>>>>>>  #define GEM_WARN_ON(expr) WARN_ON(expr)
>>>>>> +#define GEM_WARN(condition, format, ...) WARN(condition, format, __VA_ARGS__)
>>>>>>
>>>>>>  #define GEM_DEBUG_DECL(var) var
>>>>>>  #define GEM_DEBUG_EXEC(expr) expr
>>>>>> @@ -38,6 +39,7 @@
>>>>>>  #else
>>>>>>  #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
>>>>>>  #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
>>>>>> +#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
>>>>>
>>>>> WARNs can be used as part of an if(), so perhaps
>>>>>
>>>>> #define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
>>>>> #define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
>>>>
>>>> Sorry, I just can't resist the "told you so" here.
>>>>
>>>> If you come up with a local pattern that's deceptively similar to a
>>>> widely used one, with the crucial difference that you can't use anything
>>>> with required side effects in it, you'll screw it up eventually.
>>>>
>>>> if (GEM_WARN_ON(wait_for_engine(engine, 50))) looks completely natural
>>>> and "obviously correct" in code, but is dead wrong. This won't be the
>>>> last time.
>>>
>>> I would also prefer to make it consistent.
>>>
>>> There are two other users of GEM_WARN_ON in i915_vma_bind to consider
>>> what to do with, but anyway it would be a much better solution.
>>
>> My suggestion is to make GEM_WARN_ON and friends that are conditional to
>> CONFIG_DRM_I915_DEBUG_GEM unusable as expressions. Make them fail to
>> build within if (...) for both CONFIG_DRM_I915_DEBUG_GEM=y and =n. Then
>> if you need that kind of construct, handle it with something like:
>>
>> 	if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) && condition) {
>> 		GEM_WARN(...);
>> 		...
>> 	}
>>
>> maybe wrapping that IS_ENABLED bit in a more manageable macro.
>
> Why not simply make it work like a normal WARN_ON? Eg:
>
> #ifdef ...DEBUG_GEM
> #define GEM_WARN_ON(expr) WARN_ON(expr)
> #else
> #define GEM_WARN_ON(expr) (expr)
> #endif

I thought Chris explicitly wanted it to be lighter and leave expr out
completely on non-debug builds.

BR,
Jani.

>
> Regards,
>
> Tvrtko

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-05-24 11:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23  9:19 [PATCH] drm/i915: Fix waiting for engines to idle Tvrtko Ursulin
2017-05-23  9:29 ` Chris Wilson
2017-05-23  9:45   ` Tvrtko Ursulin
2017-05-23  9:51     ` Chris Wilson
2017-05-23  9:56   ` Jani Nikula
2017-05-23 10:05     ` Tvrtko Ursulin
2017-05-23 11:30       ` Jani Nikula
2017-05-24  9:11         ` Tvrtko Ursulin
2017-05-24 11:39           ` Jani Nikula [this message]
2017-05-23  9:36 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-05-23  9:36 ` [PATCH] " Chris Wilson
2017-05-23 10:09   ` Chris Wilson
2017-05-23 10:30     ` Chris Wilson
2017-05-23 10:51       ` Tvrtko Ursulin
2017-05-23 11:07         ` Chris Wilson
2017-05-23 11:14           ` Tvrtko Ursulin
2017-05-24  0:45 ` Nick Desaulniers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bmqitrej.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@intel.com \
    --cc=nick.desaulniers@gmail.com \
    --cc=tursulin@ursulin.net \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.