Re: [PATCH 2/9] drm/i915: fix the FBC CFB size tracking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux