Re: [PATCH] BDW swizzling

[Ben Widawsky <ben@bwidawsk.net>]

On Thu, Apr 10, 2014 at 03:50:35PM -0700, Ben Widawsky wrote:
> On Thu, Apr 10, 2014 at 06:51:50PM +0100, Damien Lespiau wrote:
[snip]

> > 
> > Do you know if you have a configuration where we try to swizzle? If yes
> > and tests/gem_tiled_pread is passing that would give us a nice bit of
> > information. (which of course can be tried by the next person with time
> > to do so).
> > 
> 
> If you get it wrong, it looks really obvious. Swizzling is *supposed* to
> be one of those transparent things (I thought). What follows can be
> entirely wrong, it's mostly from memory and a brief conversation with
> Art.
> 
> There are 3 places that care about swizzling:
> 1. The memory/DRAM controller
> 2. The displayer interface to memory
> 3. The GAM arbiter (generic interface to memory)
> 
> It may or may not be talking about the same type of swizzling (bit) in
> all cases. The important thing, and what I have observed, is that the
> GAM and DE match on how things are swizzled. Otherwise we render/blit to
> a surface and it gets [de]swizzled when it's displayed. I never measured
> performance for setting both to 0, instead of 1.
> 
> The part that's confused me has always been why we are supposed to
> program it based on #1. The way the DRAM controller decides to lay out
> the physical rows/banks etc. shouldn't matter as long as everyone goes
> through the same DRAM controller. It should just be transparent linear
> RAM. In other words, the comment about how we need to program the
> swizzle based on the DRAM controller never quite made sense to me. It's
> also possible if you enable one, you shouldn't/should enable another
> since compounding swizzling may be self-defeating. Dunno - so maybe your
> patch helps, maybe it hurts.
> 
> Art suggested that the swizzling in GAM and DE predate the DRAM
> swizzler.

My bad. I just read the actual patch's commit message. Seems like you
knew all this already. Feel free to ignore me. I'll try to read both
before responding, next time.

-- 
Ben Widawsky, Intel Open Source Technology Center