From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH] drm/i915: Fix context size calculation on
 SNB/IVB/VLV
Date: Thu, 22 Aug 2013 21:45:14 +0300
Message-ID: <20130822184514.GE29682@intel.com>
References: <1377188593-6881-1-git-send-email-ville.syrjala@linux.intel.com>
	<20130822183054.GB7181@bwidawsk.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
	by gabe.freedesktop.org (Postfix) with ESMTP id 11D55E5C21
	for <intel-gfx@lists.freedesktop.org>;
	Thu, 22 Aug 2013 11:45:18 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20130822183054.GB7181@bwidawsk.net>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Thu, Aug 22, 2013 at 11:30:55AM -0700, Ben Widawsky wrote:
> On Thu, Aug 22, 2013 at 07:23:13PM +0300, ville.syrjala@linux.intel.com w=
rote:
> > From: Ville Syrj=E4l=E4 <ville.syrjala@linux.intel.com>
> > =

> > All the different context sizes reported in the CXT_SIZE register
> > aren't meant to be simply added together.
> > =

> > While BSpec is somewhat unclear on the topic of the actual context
> > size, empirical tests have now revealed the truth. So let's add a
> > big fat comment to remind people how it all works.
> =

> By the way. I've done some digging. I believe (75% certain) pre-HSW,
> every context save writes the entire data. So if you wanted to set some
> pattern and see what HW actually overwrites, it should be doable. HSW+
> though we can't do that.

That's actually what I did. I dumped the context to disk and looked for
magic numbers and checked their offsets against the context layout
information in BSpec.

Now sure how HSW works. If it just jumps over some parts of the context
that don't need saving, then we could certainly use the same method.
Just identify some magic numbers in some high offsets, make sure to use
that part of the hardware to force it to save it, and then look for
those magic numbers in the dump. That'd easily tell us which parts of
the context it never saves (eg. the execlist context).

But if it dynamically rearranges the contents of the context image
every time, then it won't work obviously.

-- =

Ville Syrj=E4l=E4
Intel OTC