[Intel-gfx] [PATCH] drm/i915: Report the actual swizzling back to userspace

[Chris Wilson]

On Mon, Oct 27, 2014 at 10:08:29AM +0100, Daniel Vetter wrote:
> On Fri, Oct 24, 2014 at 04:16:14PM +0100, Chris Wilson wrote:
> > On Fri, Oct 24, 2014 at 04:39:29PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 24, 2014 at 12:11:11PM +0100, Chris Wilson wrote:
> > > > Userspace cares about whether or not swizzling depends on the page
> > > > address for its direct access into bound objects. Extend the get_tiling
> > > > ioctl to report the physical swizzling value in addition to the logical
> > > > swizzling value so that userspace can accurately determine when it is
> > > > possible for manual detiling.
> > > > 
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Cc: Akash Goel <akash.goel at intel.com>
> > > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > 
> > > I wonder whether we should care really, since on gen5+ we know that they
> > > agree. Pimp some igt (by skipping if needed) to convince me?
> > 
> > It's for gen2-4... Trivial little change to enable more sharing of code
> > paths and speedups.
> > 
> > What type of igt do you want? I personally have never seen a bit17
> > swizzling machine, but we know that some do exist due to the bug
> > reports.
> 
> I've thought of adding the relevant new cases to gem_tiled_pread.c. But
> that's for the pread stuff and not cpu mmaps, but copypaste to
> gem_tiled_cpu_mmap.c can fix that. And the desktop i915g I have here does
> bit17 - without any L-shaped craziness even afaik!

But what do you actually want to verify? That if we write through a
linear view onto a tiled surface using the swizzle mode indicated by the
ioctl that it is in order when read back through a fence register? And
in particular for v2 that we don't do anything when the swizzle
indicates bit17 is involved.

A get_tiling ioctl test needs to exercise that it reports swizzling
correctly, right?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre