Re: [Intel-gfx] [PATCH 4/4] drm/i915: Rewrite CL/CTG L-shaped memory detection

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Rewrite CL/CTG L-shaped memory detection
Date: Mon, 26 Apr 2021 20:18:39 +0300	[thread overview]
Message-ID: <YIb178CssrxSSSk6@intel.com> (raw)
In-Reply-To: <YIblm7BAj6fnQiq+@phenom.ffwll.local>

On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 21, 2021 at 06:34:01PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Currently we try to detect a symmetric memory configurations
> > > > using a magic DCC2_MODIFIED_ENHANCED_DISABLE bit. That bit is
> > > > either only set on a very specific subset of machines or it
> > > > just does not exist (it's not mentioned in any public chipset
> > > > datasheets I've found). As it happens my CL/CTG machines never
> > > > set said bit, even if I populate the channels with identical
> > > > sticks.
> > > > 
> > > > So let's do the L-shaped memory detection the same way as the
> > > > desktop variants, ie. just look at the DRAM rank boundary
> > > > registers to see if both channels have an identical size.
> > > > 
> > > > With this my CL/CTG no longer claim L-shaped memory when I use
> > > > identical sticks. Also tested with non-matching sticks just to
> > > > make sure the L-shaped memory is still properly detected.
> > > > 
> > > > And for completeness let's update the debugfs code to dump
> > > > the correct set of registers on each platform.
> > > > 
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Did you check this with the swapping igt? I have some vague memories of
> > > bug reports where somehow the machine was acting like it's L-shaped memory
> > > despite that banks were populated equally. I've iirc tried all kinds of
> > > tricks to figure it out, all to absolutely no avail.
> > 
> > Did you have a specific test in mind? I ran a bunch of things
> > that seemed swizzle related. All passed just fine.
> 
> gem_tiled_swapping should be the one. It tries to cycle your entire system
> memory through tiled buffers into swap and out of it.

Passes with symmetric config, fails with L-shaped config (if I hack
out the L-shape detection of course). So seems pretty solid.

A kernel based self test that looks at the physical address would
still be nice I suppose. Though depending on the size of your RAM
sticks figuring out where exactly the switchover from two channels
to one channels happens probably requires a bit of work due to
the PCI hole/etc.

Both my cl and ctg report this btw:
 bit6 swizzle for X-tiling = bit9/bit10/bit11
 bit6 swizzle for Y-tiling = bit9/bit11
so unfortunately can't be sure the other swizzle modes would be
correctly detected.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel