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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22e017c0-d886-22b5-b382-d68d79f7774f@linux.intel.com>
Date:	Mon, 1 Aug 2016 10:48:37 +0200
From:	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
To:	Matt Roper <matthew.d.roper@...el.com>,
	Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:	Lyude <cpaul@...hat.com>, intel-gfx@...ts.freedesktop.org,
	David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	Daniel Vetter <daniel.vetter@...el.com>
Subject: Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

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.