On Mon, Jun 15, 2015 at 07:36:25PM +0100, Dave Gordon wrote:
> +static int i915_gem_context_first_open(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int ret;
> +
> + /*
> + * We can't enable contexts until all firmware is loaded. This
> + * call shouldn't return -EAGAIN because we pass wait=true, but
> + * it can still fail with code -EIO if the GuC doesn't respond,
> + * or -ENOEXEC if the GuC firmware image is invalid.
> + */
> + ret = intel_guc_ucode_load(dev, true);
> + WARN_ON(ret == -EAGAIN);
> +
> + /*
> + * If an error occurred and GuC submission has been requested, we can
> + * attempt recovery by disabling GuC submission and reinitialising
> + * the GPU and driver. We then fail this open() anyway, but the next
> + * attempt will find that GuC submission is already disabled, and so
> + * proceed to complete context initialisation in non-GuC mode instead.
> + */
> + if (ret && i915.enable_guc_submission) {
> + i915_handle_guc_error(dev, ret);
> + return ret;
> + }
This is still backwards. What we wanted was for the submission process
to start up normally and then once the GuC loading succeeds, we then
start submitting the backlog to the GuC. If the loading fails, we can
then submit the backlog via execlists. It may be interesting to even
start userspace before GuC finishes loading.
So this makes more sense as to why you have the tight integration with
execlists then. I still don't think that justifies changing gen8 without
reason.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
