On Fri, Dec 26, 2014 at 11:46:34AM -0200, Paulo Zanoni wrote:
> 2014-12-25 8:16 GMT-02:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
> > On Tue, Dec 23, 2014 at 10:35:38AM -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>
> >>
> >> We have dev_priv->fbc.size which is supposed to contain the compressed
> >> FB size, but it is not: at find_compression_threshold() we try to
> >> overallocate the CFB, but we don't consider this when we assign a
> >> value to dev_priv->fbc.size. Since the correct CFB size should already
> >> be stored at dev_priv->fbc.compressed_fb.size, just kill
> >> dev_priv->fbc.size and use the correct value isntead.
> >
> > They should not be equivalent though. We actually want fbc.size to
> > compensate for the compression in the allocation so that the simple
> > check for enough space succeeds even if we are compressing.
>
> Can you please elaborate more on that? Are you talking about the
> threshold? As far as I can see, we're failing to properly take it into
> consideration both before and after this patch, so it wouldn't be a
> valid reason.
We have both identified the problem, and the fix to the current code
looks rather easy as it seems a simple bug in
commit 5e59f7175f96550ede91f58d267d2b551cb6fbba
Author: Ben Widawsky <benjamin.widawsky@xxxxxxxxx>
Date: Mon Jun 30 10:41:24 2014 -0700
drm/i915: Try harder to get FBC
that fluffs the compare of uncompressed request sizes.
Your subject line claims to be a fix, so fix something.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
