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. I was planning to fix the "take threshold into consideration when checking the size" problem later: I wanted to think on a way that would guarantee that we'd always get the best possible threshold to prevent cases where we'd keep reusing 1:4 compression even while we could just free+realloc to have 1:1 compression back. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx