Re: [PATCH 00/15] Batch submission via GuC

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, Ben Widawsky <ben@bwidawsk.net>,
	Vinit Azad <vinit.azad@intel.com>
Subject: Re: [PATCH 00/15] Batch submission via GuC
Date: Wed, 24 Jun 2015 13:57:18 +0100	[thread overview]
Message-ID: <20150624125718.GA30757@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20150624121605.GF25769@phenom.ffwll.local>

On Wed, Jun 24, 2015 at 02:16:05PM +0200, Daniel Vetter wrote:
> - For async gem init it's tempting to repurpose the gpu reset code with
>   all the existing synchronization: We'd only need to set the
>   RESET_IN_PROGRESS flag synchronously and then run a gpu reset after the
>   firmware is loaded, all from the async worker. The problem with that is
>   that we still have issues with rogue -EIO escaping into the modeset code
>   while a reset is pending, and that would not be good since we want
>   modesets to work right away ofc. Also most modeset paths need to stall
>   for gpu resets synchronously, which again isn't what we want.

We already have async GEM init! It is the source of a bug I keep
reporting.

async GEM init is trivial, the memory management code is independent of
request submission. Request submission can be delayed indefinitely until
the submission port is ready. The only effect is that we have to be
careful when doing hangcheck to be sure that the submission port is
running before declaring it hung.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx