[Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code

[Kristian Høgsberg]

On Fri, Sep 1, 2017 at 6:46 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Thu, Aug 31, 2017 at 05:05:01PM -0700, Rodrigo Vivi wrote:
>> Hi Ville,
>>
>> On Wed, Aug 30, 2017 at 10:09 AM, Ville Syrjälä
>> <ville.syrjala at linux.intel.com> wrote:
>> > On Wed, Aug 30, 2017 at 11:31:16AM +0300, Jani Nikula wrote:
>> >> On Mon, 28 Aug 2017, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
>> >> > On Mon, Aug 28, 2017 at 02:35:54PM +0100, Daniel Stone wrote:
>> >> >> Hi Daniel,
>> >> >>
>> >> >> On 25 August 2017 at 18:17, Daniel Vetter <daniel at ffwll.ch> wrote:
>> >> >> > Which of these do we need to cherry-pick over to -next-fixes? There's no
>> >> >> > annotations about that. If the answer is "most" I'm leaning towards
>> >> >> > disabling CCS for 4.14, minimal set would be ideal (and first in the patch
>> >> >> > series).
>> >> >>
>> >> >> My opinion below; tl;dr is that I don't think most of them are
>> >> >> super-critical. Ville obviously has a far stronger opinion than me on
>> >> >> the shape of the code, so I'm fine with this series, which seems to
>> >> >> mostly be a merge back of the delta between whatever Ville's latest
>> >> >> branch was, and whatever the last patchset Ben sent out was.
>> >> >>
>> >> >> >> Ville Syrjälä (12):
>> >> >> >>   drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear
>> >> >> >>     offset
>> >> >>
>> >> >> This should land into -fixes. I trust Ville that it has no UABI
>> >> >> impact, but seems like something to be very consistent on.
>> >> >
>> >> > It does change the uabi. That's the whole point. What was merged doesn't
>> >> > agree with what userspace wants. So this we want in definitely so that
>> >> > we don't end up exposing the wrong uabi in any released kernel.
>> >> >
>> >> >>
>> >> >> >>   drm/i915: Skip fence alignemnt check for the CCS plane
>> >> >>
>> >> >> Not sure if this is -fixes material really, just a cleanup?
>> >> >
>> >> > It makes the kernel less likely to reject the fb entirely. So
>> >> > without this userspace has to be rather careful where it places
>> >> > the aux surface. I would include this as well.
>> >> >
>> >> >>
>> >> >> >>   drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for
>> >> >> >>     CCS
>> >> >>
>> >> >> Not -fixes, performance optimisation.
>> >> >
>> >> > We hope. It does change the layout of the compressed data though so if
>> >> > our testcases try to generate compressed data with the CPU it'll not go
>> >> > well if the test assumes the wrong hash mode. I would include this as
>> >> > well so that we don't end up in any kind of a mess later when we try to
>> >> > change it.
>> >> >
>> >> > So the patches were more or less sorted in priority order, and we want
>> >> > at least 01,02 and maybe 03.
>> >>
>> >> When you decide what to apply, please *please* add the appropriate
>> >> Fixes: tags for the ones you want to show up in v4.14.
>> >
>> > I just pushed 01 and 02 to dinq with the approriage Fixes: tags.
>> > I'd still prefer to get 03 in as well, but that would need an
>> > r-b/ack.
>> >
>> >>
>> >> BR,
>> >> Jani.
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> >>   drm/i915: Add a comment exlaining CCS hsub/vsub
>> >> >>
>> >> >> Seems harmless to land to -fixes.
>> >> >>
>> >> >> >>   drm/i915: Nuke a pointless unreachable()
>> >> >>
>> >> >> Ditto.
>> >> >>
>> >> >> >>   drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites
>> >> >>
>> >> >> Per my previous reply, NAK to landing at all, since DDB/WM allocation
>> >> >> seems too broken for it to work.
>> >> >>
>> >> >> >>   drm/i915: Clean up the sprite modifier checks
>> >> >>
>> >> >> Fine with this, but doesn't seem like -fixes material.
>> >> >>
>> >> >> >>   drm/i915: Add CCS capability for sprites
>> >> >>
>> >> >> NAK, same reason as Y/Yf.

What's the status for CCS_E on the overlay plane?

thanks,
Kristian

>> >> >>
>> >> >> >>   drm/i915: Allow up to 32KB stride on SKL+ "sprites"
>> >> >>
>> >> >> Again doesn't seem like -fixes necessarily?
>> >> >>
>> >> >> >>   drm: Fix modifiers_property kernel doc
>> >> >>
>> >> >> Good for -fixes.
>> >> >>
>> >> >> >>   drm: Check that the plane supports the request format+modifier combo
>> >> >>
>> >> >> Good for core (not Intel) -fixes.
>> >> >>
>> >> >> >>   drm/i915: Remove the pipe/plane ID checks from
>> >> >> >>     skl_check_ccs_aux_surface()
>> >> >>
>> >> >> Seems fine but probably not -fixes material; land in Intel after a merge?
>> >> >>
>> >> >> Cheers,
>> >> >> Daniel
>>
>> Should I wait any more of this for drm-intel-next-fixes?
>>
>> Otherwise I will move with the pull request.
>
> Go ahead with the pull request. We should be able to live with just the
> first two patches for now.
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx