From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>, "miku@iki.fi" <miku@iki.fi>
Subject: Re: [PATCH v3] drm/i915: Add null state batch to active list
Date: Thu, 22 May 2014 16:34:30 +0300 [thread overview]
Message-ID: <87lhturl7d.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20140521152906.GA2828@bdvolkin-ubuntu-desktop>
"Volkin, Bradley D" <bradley.d.volkin@intel.com> writes:
> On Wed, May 21, 2014 at 07:02:56AM -0700, Mika Kuoppala wrote:
>> + if (ring->id == RCS && !to->is_initialized && from == NULL) {
>> + ret = i915_gem_render_state_init(ring);
>> + if (ret)
>> + DRM_ERROR("init render state: %d\n", ret);
>> + }
>
> Apologies if this has already been discussed, but why do we have the
> 'from == NULL' check? Shouldn't we initialize all uninitialized RCS
> contexts? Otherwise I thought we'll inherit whatever state 'from' left
> behind.
>
> The hw state should be valid in either case (and so I expect would fix
> the rc6 issue either way), it's just the difference between initializing
> every context to a specific valid state or initializing every context to
> _some_ valid state. The commit message on the first render state patch
> seemed to indicate the former while the implementation looks like the
> latter. Just want to understand which we intended.
It seems that the intentions changed and I forgot to update the
commit message. For now this is just to push some state and hoping
that we can get in/out from rc6 without symptomps.
The idea that we would restore/initialize to a specific (golden) state for
each new context makes me think that we would get rid of some transient
bugs we are seeing. As how I understand things are now, app might
inherit some parts from previous ctx and then have lacking
initialization by itself and then see a hang..sometimes.
I guess the main opponent here is the performance implications.
And I lack the experience from user/application side to estimate the impact.
I hope that other devs with more experience on this topic will join
the discussion.
Thanks,
-Mika
prev parent reply other threads:[~2014-05-22 13:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-21 12:08 [PATCH] drm/i915: Add null state batch to active list Mika Kuoppala
2014-05-21 12:22 ` Ville Syrjälä
2014-05-21 12:59 ` [PATCH v2] " Mika Kuoppala
2014-05-21 13:06 ` [PATCH] " Chris Wilson
2014-05-21 14:02 ` [PATCH v3] " Mika Kuoppala
2014-05-21 14:54 ` Daniel Vetter
2014-05-21 15:00 ` Chris Wilson
2014-05-21 15:17 ` Daniel Vetter
2014-05-21 16:01 ` [PATCH v4] " Mika Kuoppala
2014-05-22 12:10 ` Daniel Vetter
2014-05-21 15:29 ` [PATCH v3] " Volkin, Bradley D
2014-05-22 13:34 ` Mika Kuoppala [this message]
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=87lhturl7d.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=bradley.d.volkin@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=miku@iki.fi \
/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.