Re: [PATCH 12/16] drm/915: fix relaxed tiling on gen2: tile height

From: Daniel Vetter <daniel@ffwll.ch>
To: Keith Packard <keithp@keithp.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 12/16] drm/915: fix relaxed tiling on gen2: tile height
Date: Mon, 16 May 2011 19:48:49 +0200	[thread overview]
Message-ID: <20110516174848.GA3506@viiv.ffwll.ch> (raw)
In-Reply-To: <yunliy739tp.fsf@aiko.keithp.com>

On Sun, May 15, 2011 at 02:58:26PM -0700, Keith Packard wrote:
> I have this vague memory of some problem in the past with tiling and old
> user space for Gen2 hardware. I assume that old user space will just do
> bad things, but that there's nothing the kernel can do to fix it, right?

Ok, I'll try to fill you in with a quick summary on this - after all,
we've not only had just one issue with tiling, so it's rather easy to get
lost ;-) Very short answer is "yes".

The tiling height bug (aligning to 8 rows instead of 16) in userspace has
been around forever (as far as I bothered to dig into history, at least).
But that never really showed up because we were rounding up to the next
fence size, which is a pot and at least .5mb (on gen2). So ceil(rows/8)
was never odd, which is the only case this bug manifests. This also wastes
tons of memory, so Chris Wilson developed the relaxed fencing scheme to
avoid allocating unneeded backing storage (and only reserving the full gtt
space if there's a fence attached to the object). Only with support for
relaxed fencing both in the kernel and userspace portion of the driver
could we actually hit the bug. Matters were made worse by our rather large
impedance mismatch between userspace and kernel releases: Distros have
been shipping broken userspace in their stable releases before the kernel
part has hit Linus-mainline (which is when people started to complain, at
around .38-rc6, iirc).

We've tried to detect such underallocated last tile rows in the kernel and
reject such tiling attempts. But libdrm reuses buffers as long as they're
big enough, so the last tile row might intentionally not be complete, but
also never used. We can't tell these two cases apart in the kernel, which
is why we've had to back out that change again and just absorb the
resulting flak.

Aside: I think we need to improve our efforts to make the new patches in
-next testable by the community to decrease that turn-around time mismatch
and catch such issues earlier. I'm tossing around ideas, but nothing
concrete yet.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48