Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

[Maarten Lankhorst]

Op 29-07-16 om 22:33 schreef Matt Roper:
> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
>> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
>>> This is completely untested (and probably horribly broken/buggy), but
>>> here's a quick mockup of the general approach I was thinking for
>>> ensuring DDB & WM's can be updated together while ensuring the
>>> three-step pipe flushing process is honored:
>>>
>>>         https://github.com/mattrope/kernel/commits/experimental/lyude_ddb
>>>
>>> Basically the idea is to take note of what's happening to the pipe's DDB
>>> allocation (shrinking, growing, unchanged, etc.) during the atomic check
>>> phase;
>> Didn't look too closely, but I think you can't actually do that unless
>> you lock all the crtcs whenever the number of active pipes is goind to
>> change. Meaning we'd essentially be back to the one-big-modeset-lock
>> apporach, which will cause missed flips and whanot on the other pipes.
>>
>> The alternative I think would consist of:
>> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes,
>>   so that a modeset doesn't have to care about the wms for the other
>>   pipes not fitting in
> Unfortunately this part is the problem.  You might get away with doing
> this on SKL/KBL which only have three planes max per pipe and a large
> (896 block) DDB, but on BXT you have up to four planes (we don't
> actually enable the topmost plane in a full-featured manner just yet,
> but need to soon), yet the total DDB is only 512 blocks.  Sadly, the
> platform with more planes was given a smaller DDB...   :-(
> We're already in trouble because users that are running setups like 3x
> 4K with most/all planes in use at large sizes can't find level 0
> watermarks that satisfy their needs and we have to reject the whole
> configuration.  If we further limit each pipe's usage to total/maxpipes
> (i.e., 170 blocks per pipe on BXT), then we're going to hit similar
> issues when only driving one or two displays with with all of the planes
> in use, even though we should have had more DDB space to work with.
>
> I guess serious plane usage isn't too common in desktop setups today,
> but it's a very critical feature in the embedded world; we can't really
> afford to cripple plane usage further.  Unfortunately, as you point out
> above, this means that we have to follow the bspec's DDB allocation
> method, which in turn means we need to grab _all_ CRTC locks any time
> _any_ CRTC is being turned on or turned off which is a BKL-style way of
> doing things.
Meh, I'm running into a similar issue on vlv/chv. I don't see a way around it. :(
Only thing we could do is split up the state to make the non-modeset
crtc's complete early.