[Intel-gfx] i915 freakout with latest 3.7 git

[Daniel Vetter]

On Sat, Dec 08, 2012 at 02:06:48PM +0100, Heinz Diehl wrote:
> On 07.12.2012, Daniel Vetter wrote: 
> 
> [....]
> 
> I did a "git bisect" betweeb 3.6 and 3.7-rc8 and ended up with
> this. Unfortunately, git can't revert this patch on top of master, sp
> I have not been able to test if a revert will cure the problem.
> 
> After reading on the net that Peter (Lekensteyn) already ended up with
> bisecting the same patch and it didn't work for him reverting it on
> top of 3-7-rc4, I'm somewhat clueless..
> 
> What else can I do to help finding the cause?

Can you please test the patch at

https://bugs.freedesktop.org/attachment.cgi?id=70111

That one should disable all effects of the unbound tracking, since a
revert of the below commit conflicts.

Thanks, Daniel
> 
> Heinz
> 
> 
> [root at wildsau linux-git]# git bisect good
> 6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
> commit 6c085a728cf000ac1865d66f8c9b52935558b328
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Mon Aug 20 11:40:46 2012 +0200
> 
>     drm/i915: Track unbound pages
>     
>     When dealing with a working set larger than the GATT, or even the
>     mappable aperture when touching through the GTT, we end up with
>     evicting
>     objects only to rebind them at a new offset again later. Moving an
>     object into and out of the GTT requires clflushing the pages, thus
>     causing a double-clflush penalty for rebinding.
>     
>     To avoid having to clflush on rebinding, we can track the pages as
>     they
>     are evicted from the GTT and only relinquish those pages on memory
>     pressure.
>     
>     As usual, if it were not for the handling of out-of-memory
>     condition and
>     having to manually shrink our own bo caches, it would be a net
>     reduction
>     of code. Alas.
>     
>     Note: The patch also contains a few changes to the last-hope
>     evict_everything logic in i916_gem_execbuffer.c - we no longer try
>     to
>     only evict the purgeable stuff in a first try (since that's
>     superflous
>     and only helps in OOM corner-cases, not fragmented-gtt trashing
>     situations).
>     
>     Also, the extraction of the get_pages retry loop from bind_to_gtt
>     (and
>     other callsites) to get_pages should imo have been a separate
>     patch.
>     
>     v2: Ditch the newly added put_pages (for unbound objects only) in
>     i915_gem_reset. A quick irc discussion hasn't revealed any
>     important
>     reason for this, so if we need this, I'd like to have a git
>     blame'able
>     explanation for it.
>     
>     v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris
>     noticed.
>     
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     [danvet: Split out code movements and rant a bit in the commit
>     message
>     with a few Notes. Done v2]
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> :040000 040000 c4f02e0d05a570d0baf9d2f19a6c276c06a55142
> df93a56308637e3840353c3c9425ec96c3422dcc M	drivers
> [root at wildsau linux-git]# 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch