[Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
From: Ville Syrjälä Looks like we ended up with a stale version of my CCS code in dinq. This series contains the remainder in smaller chunks. I also ended up adding a bunch of extra cleanup etc. on top. The most important thing we need to get in is the change to the fb->offsets[] interpretation since that's ABI territory. The hash mode apparently doesn't require the nasty virtual address alignment tricks so that shouldn't have any ABI issues after all. Entire series available here: git://github.com/vsyrjala/linux.git ccs_fixes Cc: Ben Widawsky Cc: Jason Ekstrand Cc: Daniel Stone Ville Syrjälä (12): drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear offset drm/i915: Skip fence alignemnt check for the CCS plane drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for CCS drm/i915: Add a comment exlaining CCS hsub/vsub drm/i915: Nuke a pointless unreachable() drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites drm/i915: Clean up the sprite modifier checks drm/i915: Add CCS capability for sprites drm/i915: Allow up to 32KB stride on SKL+ "sprites" drm: Fix modifiers_property kernel doc drm: Check that the plane supports the request format+modifier combo drm/i915: Remove the pipe/plane ID checks from skl_check_ccs_aux_surface() drivers/gpu/drm/drm_atomic.c | 8 +- drivers/gpu/drm/drm_crtc.c | 8 +- drivers/gpu/drm/drm_crtc_internal.h| 4 +- drivers/gpu/drm/drm_plane.c| 31 +-- drivers/gpu/drm/i915/i915_reg.h| 8 +- drivers/gpu/drm/i915/intel_display.c | 145 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_engine_cs.c | 13 +++ drivers/gpu/drm/i915/intel_pm.c| 27 +++--- drivers/gpu/drm/i915/intel_sprite.c| 102 +++ include/drm/drm_mode_config.h | 2 +- 11 files changed, 217 insertions(+), 133 deletions(-) -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Fri, Sep 1, 2017 at 6:46 AM, Ville Syrjälä 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ä >> wrote: >> > On Wed, Aug 30, 2017 at 11:31:16AM +0300, Jani Nikula wrote: >> >> On Mon, 28 Aug 2017, Ville Syrjälä 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 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Thu, Aug 24, 2017 at 10:10:48PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Looks like we ended up with a stale version of my CCS code in dinq. > This series contains the remainder in smaller chunks. I also ended > up adding a bunch of extra cleanup etc. on top. > > The most important thing we need to get in is the change > to the fb->offsets[] interpretation since that's ABI territory. > The hash mode apparently doesn't require the nasty virtual address > alignment tricks so that shouldn't have any ABI issues after all. > > Entire series available here: > git://github.com/vsyrjala/linux.git ccs_fixes > > Cc: Ben Widawsky > Cc: Jason Ekstrand > Cc: Daniel Stone 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). Thanks, Daniel > > Ville Syrjälä (12): > drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear > offset > drm/i915: Skip fence alignemnt check for the CCS plane > drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for > CCS > drm/i915: Add a comment exlaining CCS hsub/vsub > drm/i915: Nuke a pointless unreachable() > drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites > drm/i915: Clean up the sprite modifier checks > drm/i915: Add CCS capability for sprites > drm/i915: Allow up to 32KB stride on SKL+ "sprites" > drm: Fix modifiers_property kernel doc > drm: Check that the plane supports the request format+modifier combo > drm/i915: Remove the pipe/plane ID checks from > skl_check_ccs_aux_surface() > > drivers/gpu/drm/drm_atomic.c | 8 +- > drivers/gpu/drm/drm_crtc.c | 8 +- > drivers/gpu/drm/drm_crtc_internal.h| 4 +- > drivers/gpu/drm/drm_plane.c| 31 +-- > drivers/gpu/drm/i915/i915_reg.h| 8 +- > drivers/gpu/drm/i915/intel_display.c | 145 > + > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_engine_cs.c | 13 +++ > drivers/gpu/drm/i915/intel_pm.c| 27 +++--- > drivers/gpu/drm/i915/intel_sprite.c| 102 +++ > include/drm/drm_mode_config.h | 2 +- > 11 files changed, 217 insertions(+), 133 deletions(-) > > -- > 2.13.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
Hi Daniel, On 25 August 2017 at 18:17, Daniel Vetter 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. >> drm/i915: Skip fence alignemnt check for the CCS plane Not sure if this is -fixes material really, just a cleanup? >> drm/i915: Switch over to the LLC/eLLC hotspot avoidance hash mode for >> CCS Not -fixes, performance optimisation. >> 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. >> 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Mon, Aug 28, 2017 at 02:35:54PM +0100, Daniel Stone wrote: > Hi Daniel, > > On 25 August 2017 at 18:17, Daniel Vetter 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. > > >> 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. > > >> 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 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Mon, 28 Aug 2017, Ville Syrjälä 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 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. 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. >> >> >> 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 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
On Wed, Aug 30, 2017 at 11:31:16AM +0300, Jani Nikula wrote: > On Mon, 28 Aug 2017, Ville Syrjälä 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 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. > >> > >> >> 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 > > -- > Jani Nikula, Intel Open Source Technology Center -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
Hi Ville, On Wed, Aug 30, 2017 at 10:09 AM, Ville Syrjälä wrote: > On Wed, Aug 30, 2017 at 11:31:16AM +0300, Jani Nikula wrote: >> On Mon, 28 Aug 2017, Ville Syrjälä 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 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. >> >> >> >> >> 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. Thanks, Rodrigo. >> >> -- >> Jani Nikula, Intel Open Source Technology Center > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm/i915: Fix up the CCS code
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ä > wrote: > > On Wed, Aug 30, 2017 at 11:31:16AM +0300, Jani Nikula wrote: > >> On Mon, 28 Aug 2017, Ville Syrjälä 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 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. > >> >> > >> >> >> 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
