Re: [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property

/HEIGHT caps, which can only declare > a one size fits all limit for the whole device. Acked-by: Daniel Stone Cheers, Daniel

Re: [PULL] drm-xe-next

Hi, On Mon, 26 Feb 2024 at 03:21, Lucas De Marchi wrote: > All of this should be fixed by now: dim is used for applying and pushing > patches, which has additional checks so that doesn't happen again. Still > pending confirmation from Daniel Stone if the git server hooks are ready >

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

Hi, On Wed, 10 Jan 2024 at 10:44, Daniel Vetter wrote: > On Tue, Jan 09, 2024 at 11:12:11PM +, Andri Yngvason wrote: > > ţri., 9. jan. 2024 kl. 22:32 skrifađi Daniel Stone : > > > How does userspace determine what's happened without polling? Will it > > > only cha

Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

Hi, On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > + * active color format: > + * This read-only property tells userspace the color format actually used > + * by the hardware display engine "on the cable" on a connector. The > chosen > + * value depends on hardware

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote: > On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote: > > That's not what anyone's saying here ... > > > > No-one's demanding AMD publish RTL, or internal design docs, or > > hardware specs, or URLs to JIR

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

Hi Alex, On Wed, 23 Mar 2022 at 14:42, Alex Deucher wrote: > On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote: > > On Wed, 23 Mar 2022 at 08:19, Christian König > > wrote: > > > Well the key point is it's not about you to judge that. > > > > > >

Re: [Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

On Wed, 23 Mar 2022 at 08:19, Christian König wrote: > Am 23.03.22 um 09:10 schrieb Paul Menzel: > > Sorry, I disagree. The motivation needs to be part of the commit > > message. For example see recent discussion on the LWN article > > *Donenfeld: Random number generator enhancements for Linux

Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core

tained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. Acked-by: Daniel Stone

Re: [Intel-gfx] [PATCH v3 0/8] DG2 accelerated migration/clearing support

Hi Matthew, On Mon, 6 Dec 2021 at 13:32, Matthew Auld wrote: > Enable accelerated moves and clearing on DG2. On such HW we have minimum page > size restrictions when accessing LMEM from the GTT, where we now have to use > 64K > GTT pages or larger. With the ppGTT the page-table also has a

Re: [Intel-gfx] [RFC 6/8] drm: Document fdinfo format specification

Hi Tvrtko, Thanks for typing this up! On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin wrote: > +Mandatory fully standardised keys > +- > + > +- drm-driver: > + > +String shall contain a fixed string uniquely identified the driver handling > +the device in question.

Re: [Intel-gfx] [Mesa-dev] [PATCH] dma-buf: Document dma-buf implicit fencing/resv fencing rules

Hi, On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote: > +* > +* IMPLICIT SYNCHRONIZATION RULES: > +* > +* Drivers which support implicit synchronization of buffer access as > +* e.g. exposed in `Implicit Fence Poll Support`_ should follow the > +*

Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

Hi, On Wed, 26 May 2021 at 13:46, Christian König wrote: > Am 26.05.21 um 13:31 schrieb Daniel Stone: > > How would we insert a syncobj+val into a resv though? Like, if we pass > > an unmaterialised syncobj+val here to insert into the resv, then an > > implicit-only med

Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

Hi Christian, On Wed, 26 May 2021 at 12:02, Christian König wrote: > Am 25.05.21 um 23:17 schrieb Jason Ekstrand: > > This new IOCTL solves this problem by allowing us to get a snapshot of > > the implicit synchronization state of a given dma-buf in the form of a > > sync file. It's effectively

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync

On Fri, 21 May 2021 at 14:09, Christian König wrote: > Am 21.05.21 um 14:54 schrieb Daniel Stone: > > If you're curious, the interface definitions are in the csf/ directory > > in the 'Bifrost kernel driver' r30p0 download you can get from the Arm > > developer site. Un

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/11] drm/panfrost: Fix implicit sync

On Fri, 21 May 2021 at 13:28, Christian König wrote: > Am 21.05.21 um 14:22 schrieb Daniel Stone: > > Yeah, the 'second-generation Valhall' GPUs coming later this year / > > early next year are starting to get pretty weird. Firmware-mediated > > job scheduling out of multi

Re: [Intel-gfx] [PATCH 04/11] drm/panfrost: Fix implicit sync

Hi, On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote: > Currently this has no practial relevance I think because there's not > many who can pull off a setup with panfrost and another gpu in the > same system. But the rules are that if you're setting an exclusive > fence, indicating a gpu write

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

Hi, On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin wrote: > I was just wondering if stat(2) and a chrdev major check would be a > solid criteria to more efficiently (compared to parsing the text > content) detect drm files while walking procfs. Maybe I'm missing something, but is the per-PID walk

Re: [Intel-gfx] [RFC PATCH 1/5] drm/doc/rfc: i915 GuC submission / DRM scheduler integration plan

Hi, On Tue, 11 May 2021 at 15:34, Daniel Vetter wrote: > On Thu, May 06, 2021 at 10:30:45AM -0700, Matthew Brost wrote: > > +No major changes are required to the uAPI for basic GuC submission. The > > only > > +change is a new scheduler attribute: > > I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP. >

Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen > wrote: > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for

Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"

On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä wrote: > On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote: > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == > > true, > > then the driver is allowed to steal an unrelated pipe. > > > > Maybe i915 is stealing a pipe

Re: [Intel-gfx] [PATCH] drm/ttm: don't set page->mapping

Hi, On Wed, 25 Nov 2020 at 18:06, Jason Gunthorpe wrote: > On Wed, Nov 25, 2020 at 05:28:32PM +0100, Daniel Vetter wrote: > > Apologies again, this shouldn't have been included. But at least I > > have an idea now why this patch somehow was included in the git > > send-email. Lovely interface

Re: [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY

Hi, On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. Thanks a lot, this is super helpful! Both patches are: Reviewed-by: Daniel Stone Cheers,

Re: [Intel-gfx] [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit

Hi, On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote: > + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i) > + affected_crtc |= drm_crtc_mask(crtc); > + > + /* > +* For commits that allow modesets drivers can add other CRTCs to the > +* atomic

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect tha

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > Defacto the uapi we have now is that userspace needs to ignore

Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

Hi all, On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote: > On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote: > > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen > > wrote: > > > Yes, this is used as part of the Android stack on Chrome OS (need to > &

Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

Hi, On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen wrote: > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson > wrote: > > Maybe now is the time to ask: are you using sw_sync outside of > > validation? > > Yes, this is used as part of the Android stack on Chrome OS (need to > see if ChromeOS

Re: [Intel-gfx] sw_sync deadlock avoidance, take 3

Hi, On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen wrote: > My concern with going in this direction was that we potentially allow > an application to allocate a lot of kernel memory but not a lot of fds > by creating lots of fences and then closing the fds but never > signaling them. Is that

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote: > On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote: > > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote: > > > Comes up every few years, gets somewhat tedious to discuss, let's > > > write this down once

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

icitly encode the carrot of dma-fence's positive guarantees, rather than just the stick of 'don't do this'. ;) Either way, this is: Acked-by: Daniel Stone > What I'm not sure about is whether the text should be more explicit in > flat out mandating the amdkfd eviction fences for long run

Re: [Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations

Hi, On Wed, 8 Jul 2020 at 16:13, Daniel Vetter wrote: > On Wed, Jul 8, 2020 at 4:57 PM Christian König > wrote: > > Could we merge this controlled by a separate config option? > > > > This way we could have the checks upstream without having to fix all the > > stuff before we do this? > >

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

Hi, Jumping in after a couple of weeks where I've paged most everything out of my brain ... On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote: > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > > The proposed patches might very well encode the wrong contract, that's > > > all up

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

Hi, On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Introducing a global lockmap that cannot capture the rules correctly, > > Can you document the rules all drivers should be following then, > because from here it looks to get refactored

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote: > On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote: > > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote: > > I'd be very much in favour of putting the blocking down in the kernel > > at least until the kernel can give

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

Hi, On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote: > > Did anything happen with this? > > Nope. There's an igt now that fails with this, and I'm not sure > whether changing the igt is the right idea or not. > > I'm kinda now thinking about changing this to instead document under > which

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > Resending because last attempt failed CI and meanwhile the results are > lost :-/ Did anything happen with this? Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

Hi Jan, On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote: > On Friday 2020-02-28 08:59, Daniel Stone wrote: > >I believe that in January, we had $2082 of network cost (almost > >entirely egress; ingress is basically free) and $1750 of > >cloud-storage cost (almost all

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund wrote: > On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > > Yeah, changes on vulkan drivers or backend compilers should be > > fairly > > sandboxed. > > > > We also have tools that only work for intel stuff, that should never > > trigger

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote: > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > comparable in terms of what you get and what you pay for them. > > Obviously providers like Packet

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > b) we probably need to take a large step back here. > > Look at this from a sponsor POV, why would I give X.org/fd.o > sponsorship money that they are just giving straight to google to pay > for hosting credits? Google are profiting in some minor

Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services

Hi Matt, On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote: > We're paying 75K USD for the bandwidth to transfer data from the > GitLab cloud instance. i.e., for viewing the https site, for > cloning/updating git repos, and for downloading CI artifacts/images to > the testing machines (AFAIU). I

Re: [Intel-gfx] [RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor based integer scaling support

Hi, On Tue, 25 Feb 2020 at 07:17, Pankaj Bharadiya wrote: > @@ -415,18 +415,26 @@ skl_program_scaler(struct intel_plane *plane, > u16 y_vphase, uv_rgb_vphase; > int hscale, vscale; > const struct drm_plane_state *state = _state->uapi; > + u32 src_w =

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

commits. Thanks for writing this up Daniel, and for reminding me about it some time later as well ... Reviewed-by: Daniel Stone Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present

Hi, On Wed, 6 Nov 2019 at 02:47, Dave Airlie wrote: > Otherwise I think this seems fine, though it does beg the question in > my mind of what happens if I get 2 8K monitors, and plug the first > tile of one in, and the second tile of the other in. Honestly in that case I think 'you get to

Re: [Intel-gfx] [PATCH] drm: Add support for integrated privacy screens

Hi Thierry, On Fri, 25 Oct 2019 at 12:36, Thierry Reding wrote: > On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote: > > I did think about having a state variable in software to get and set > > this. However, I think it is not very far fetched that some platforms > > may have "hardware

Re: [Intel-gfx] [PULL] drm-misc-next

Hi, On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote: > On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote: > > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote: > > > The thing is, dim push shouldn't allow you to do that. And the patches > > > have clearly been applied with dim apply (or at

[Intel-gfx] Fwd: PSA: Mailman changes, From addresses no longer accurate

that you are replying to the original sender (in Reply-To) and not the list itself. Cheers, Daniel -- Forwarded message - From: Daniel Stone Date: Mon, 11 Feb 2019 at 23:38 Subject: PSA: Mailman changes, From addresses no longer accurate To: , Hi all, We have hit another step change

Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property

e-time. So, in include/uapi there shouldn't be these numeric > values. > > The strings themselves effectively form the UABI, so I was wondering > if they should be defined in include/uapi, but you would be the first > to do that. > > Daniel Vetter and/or Daniel Stone mi

Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab

Hi Rodrigo, On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > drm-intel for the time being.

Re: [Intel-gfx] [igt-dev] RFC: Migration to Gitlab

Hi, On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula > wrote: > > Just a couple of concerns from drm/i915 perspective for starters: > > > > - Patchwork integration. I think we'll want to keep patchwork for at > > least intel-gfx etc. for the

Re: [Intel-gfx] RFC: Migration to Gitlab

Hi, On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > reasons: > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > infrastructure, because

Re: [Intel-gfx] Shared atomic state causing Weston repaint failure

Hey Jakob, On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz wrote: > So from a VR compositor getting blocked like this is a no-go as the > user would quickly throw EPUKE. The situation is compounded by the > fact that the VR compositor has no idea what the display compositor is > doing with

[Intel-gfx] Shared atomic state causing Weston repaint failure

Hi, The atomic API being super-explicit about how userspace sequences its calls is great and all, but having shared global state implicitly dragged in is kind of ruining my day. Currently on Intel, Weston sometimes fails on hotplug, because a commit which only enables CRTC B (not touching CRTC A

[Intel-gfx] [PATCH v3 2/2] drm/i915: Move GEM BO inside drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. v2: Only hold a single reference per framebuffer, not per plane. (Ville) v3: Drop NULL check in intel_fb_obj. (Ville) Signed-off-by: Daniel Stone <dani...@collabora.com> Reviewed-by:

[Intel-gfx] [PATCH v3 1/2] drm/i915: Use intel_fb_obj() everywhere

We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by: Daniel Stone <dani...@collabora.com> Reviewed-by: Ville Syrjälä <ville.syrj...@intel.com> Cc: Jani Nikula <jani.nik...@linu

[Intel-gfx] [PATCH v2 1/2] drm/i915: Use intel_fb_obj() everywhere

We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linu

[Intel-gfx] [PATCH v2 2/2] drm/i915: Move GEM BO inside drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. v2: Only hold a single reference per framebuffer, not per plane. (Ville) Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Ville Syrjälä <ville.syrj...@intel.com> Cc:

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Hi Ville, On 23 March 2018 at 14:49, Daniel Stone <dan...@fooishbar.org> wrote: > On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrj...@linux.intel.com> > wrote: >> Hmm. I'm thinking we can stick to the single reference per fb. >> IIRC this counter is there just

[Intel-gfx] [PATCH 00/24] drm_framebuffer boilerplate removal

Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Hi Ville, On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Mar 23, 2018 at 01:45:50PM +0000, Daniel Stone wrote: >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -1391

[Intel-gfx] [PATCH 1/4] drm/i915: Use intel_fb_obj() everywhere

We already have a macro to pull the GEM object from a FB, so use it everywhere. We'll make use of this later to move the object storage. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linu

[Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Rodri

Re: [Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

ts we > don't want. The mode type is just a hint anyway, and more > useful for the kernel->userspace direction. Reviewed-by: Daniel Stone <dani...@collabora.com> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] meson: Chamelium depends on GSL

Chamelium support requires igt_frame to be built, which requires both GSL and Pixman. Signed-off-by: Daniel Stone <dani...@collabora.com> --- meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build index ef7017cb..5b783e5d

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites

Hi Ville,Given you've tested, my reservations are dropped, so this series is:Acked-by: Daniel Stone <dani...@collabora.com>Sorry for the mobile client formatting.Cheers,Daniel___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Add CCS capability for sprites

Hi, On 11 December 2017 at 12:08, Mika Kahola <mika.kah...@intel.com> wrote: > On Mon, 2017-12-11 at 12:00 +0000, Daniel Stone wrote: >> Did you manage to test this? When I tried, the DDB/watermark >> allocation was too conservative for sprites, and never allowed enough

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Add CCS capability for sprites

Hi Mika, On 11 December 2017 at 11:11, Mika Kahola wrote: > On Thu, 2017-08-24 at 22:10 +0300, ville.syrj...@linux.intel.com wrote: >> Allow sprites to scan out compressed framebuffers. >> >> Since different platforms have a different set of planes that >> support CCS

Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property

Hi Pavel, On 5 December 2017 at 17:34, Pavel Machek wrote: > Yes, so... This patch makes it more likely to see machines with locked > down kernels, preventing developers from working with systems their > own, running hardware. That is evil, and direct threat to Free > software

Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

Hi Uma, On 10 November 2017 at 08:37, Shankar, Uma wrote: >>This is missing documentation on how plane colour management interacts with >>CRTC colour management. Is it a step before CRTC colour management is >>applied, or does it bypass CRTC colour management, or ... ? >>

Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

Hi Uma, On 7 November 2017 at 12:06, Uma Shankar wrote: > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel >

Re: [Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

Hi, On 2 November 2017 at 18:04, Pandiyan, Dhinakaran wrote: > On Thu, 2017-11-02 at 07:27 -0700, Rodrigo Vivi wrote: >> That's intentional. The idea is to send to linux-firmware only after it >> passes our CI. So, prepare already in a way that it is easy to just

Re: [Intel-gfx] [PATCH i-g-t 00/22] RFC: meson build system support

ng into a bigger series > already. And of course we need to keep autohell working for probably a > fairly long time, at least for the tools that distro install. Yes please. I've taken a couple of passes looking at it, and it seems fine to me. Acked-by: Daniel Stone <dani...@collabora.com>

Re: [Intel-gfx] [PATCH v2 4/7] tests/kms_ccs: Test case where the CCS buffer was not provided

Hi Gabriel, On 31 August 2017 at 06:58, Gabriel Krisman Bertazi wrote: > @@ -321,16 +325,19 @@ static void generate_fb(data_t *data, struct igt_fb *fb, > size[1] = f.pitches[1] * ALIGN(ccs_height, 32); > > f.handles[0] =

Re: [Intel-gfx] [PATCH v2 5/7] tests/kms_ccs: Test case where CCS and main buffer overlaps

On 31 August 2017 at 06:58, Gabriel Krisman Bertazi wrote: > @@ -321,7 +322,13 @@ static void generate_fb(data_t *data, struct igt_fb *fb, > int ccs_height = ALIGN(height, 16) / 16; > f.pitches[1] = ALIGN(ccs_width * 1, 128); >

Re: [Intel-gfx] [PATCH v2 6/7] tests/kms_ccs: Test case where CCS is on a different BO

Hi Gabriel, On 31 August 2017 at 06:58, Gabriel Krisman Bertazi wrote: > + if (data->flags & TEST_BAD_CCS_HANDLE) { > + /* Put the CCS buffer on a different BO. */ > + f.handles[0] = gem_create(data->drm_fd,

Re: [Intel-gfx] [PATCH i-g-t v3 7/7] tests/kms_ccs: Test case for wrong aux buffer stripe size

Hi Gabriel, On 31 August 2017 at 07:18, Gabriel Krisman Bertazi wrote: > Two scenarios tested: > - unaligned stripe > - Stripe too small 'stride' in the commit message please. ;) But it is fine everywhere through the code. > @@ -323,7 +326,14 @@ static void

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fail addfb ioctl if color and CCS buffers overlap

Hi Ville, On 4 September 2017 at 17:37, Ville Syrjälä wrote: > On Thu, Aug 31, 2017 at 04:52:15PM -0300, Gabriel Krisman Bertazi wrote: >> With this patch the new testcase igt@kms_ccs@pipe-X-invalid-ccs-offset >> succeeds. > > I don't think we actually want to

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

Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Change default GuC FW for SKL to v9.33

Hi Sagar, On 28 August 2017 at 10:56, Sagar Arun Kamble wrote: > This patch makes v9.33 firmware as default firmware for SKL. > This update includes (since v6.1): https://01.org/linuxgraphics/downloads/firmware does not include v9.33, only 6.1. Please do not push this

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites

Hi, On 25 August 2017 at 12:34, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > On Fri, Aug 25, 2017 at 10:40:28AM +0100, Daniel Stone wrote: >> On 24 August 2017 at 20:10, <ville.syrj...@linux.intel.com> wrote: >> > Y/Yf somehow dropped out from the SKL+

Re: [Intel-gfx] [PATCH 06/12] drm/i915: Add the missing Y/Yf modifiers for SKL+ sprites

On 24 August 2017 at 20:10, wrote: > Y/Yf somehow dropped out from the SKL+ sprite modifier list. Add them > in. There's no 'somehow': https://lists.freedesktop.org/archives/intel-gfx/2017-August/134932.html I would prefer to not see this pushed whilst it doesn't

Re: [Intel-gfx] [PATCH] drm/doc: Document ioctl errno value patterns

Hi, On 18 August 2017 at 10:21, Daniel Vetter wrote: > +Recommended IOCTL Return Values > +=== > + > +In theory a driver's IOCTL callback is only allowed to return very few error > +codes. In practice it's good to abuse a few more. This section

Re: [Intel-gfx] [PATCH i-g-t] syncobj: Add some wait and reset tests

th EINVAL */ > + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, ); > + return ret == -1 && errno == EINVAL; Unfortunately an unrecognised ioctl also leads to a failure with EINVAL. Try another test for ioctl presence, e.g. do you get ENOENT if you pass one handle to wait for, but that h

Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers

Hi, On 3 August 2017 at 12:00, Daniel Stone <dan...@fooishbar.org> wrote: > On 1 August 2017 at 17:58, Ben Widawsky <b...@bwidawsk.net> wrote: >> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private >> *dev_priv, >>

[Intel-gfx] [PATCH i-g-t 1/8] tests/kms_ccs: Convert int/bool to enum

Rather than using TEST_UNCOMPRESSED / TEST_COMPRESSED as alternately either an int or a bool, change it to a bitfield enum. This will let us add more parameters later to control framebuffer generation. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.

[Intel-gfx] [PATCH i-g-t 4/8] tests/kms_ccs: Paramaterize color for framebuffer

Will be used in later patches. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c index c02a0433..50bb2ad6 100644 --- a/tests/kms_ccs.c +++ b/tests/kms

[Intel-gfx] [PATCH i-g-t 2/8] tests/kms_ccs: Split FB generation into helper

Create a new helper for generating and rendering the framebuffer, rather than doing it inline with applying the configuration. This will be used later to generate a different plane configuration. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.

[Intel-gfx] [PATCH i-g-t 5/8] tests/kms_ccs: Reshuffle test name and loop

In preparation for also testing sprites. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c index 50bb2ad6..1a5cdcd4 100644 --- a/tests/kms_ccs.c +++ b

[Intel-gfx] [PATCH i-g-t 6/8] tests/kms_ccs: Test for supported modifier

Make sure the CCS modifier is supported on our plane, before we try to use it on that plane. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.c | 117 +++- 1 file changed, 116 insertions(+), 1 deletion(-) diff

[Intel-gfx] [PATCH i-g-t 7/8] tests/kms_ccs: Split all tests into subtests

Some subtests were magically doing a for-each-pipe loop. Remove that, and have all multi-pipe tests actually work across all pipes. Signed-off-by: Daniel Stone <dani...@collabora.com> --- tests/kms_ccs.c | 62 +++-- 1 file chang

[Intel-gfx] [PATCH i-g-t 8/8] tests/kms_ccs: Test CCS on sprite planes

Also try to test CCS on available non-primary planes. However, as there is not enough bandwidth to scan out both the primary and sprite planes when using CCS (or even Y-tiled), fall back to linear for the primary plane when using CCS for a sprite/cursor plane. Signed-off-by: Daniel Stone <d

[Intel-gfx] [PATCH i-g-t 3/8] tests/kms_ccs: Remove excessive FB alignment

We don't need to align the framebuffer dimensions to the tile size. As long as the pitch is aligned to the tile width, and the BO dimensions can fit full tiles of both aligned pitch and aligned height, we don't need to claim the FB itself is larger. Signed-off-by: Daniel Stone <d

[Intel-gfx] [PATCH igt] tests/kms_ccs: Don't overallocate CCS surface

Due to a mix-up in kernel branches being used, I'd mangled Jason's original CCS test to hopelessly overallocate the CCS surface size. Restore it back to its original. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Jason Ekstrand <ja...@jlekstrand.net> --- tests/kms_ccs.c |

Re: [Intel-gfx] [PATCH] tests/kms_ccs: Fix the color/ccs surface generation

On 4 August 2017 at 15:56, Jason Ekstrand <ja...@jlekstrand.net> wrote: > On August 4, 2017 2:59:56 AM Daniel Stone <dan...@fooishbar.org> wrote: >>> + width = ALIGN(f.width * 4, 32) / 32; >>> + height = ALIGN(f.height, 16) / 16; >>

Re: [Intel-gfx] [PATCH v2 i-g-t] tests/perf: fix build where system headers don't have Gen8 formats

On 4 August 2017 at 15:00, Lionel Landwerlin <lionel.g.landwer...@intel.com> wrote: > v2: Use previous enum to define the new Gen8 enums (Petri) > > Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com> Tested-by: Daniel Stone &

Re: [Intel-gfx] [PATCH igt] tests/kms_properties: Don't set immutable properties

On 4 August 2017 at 14:38, Daniel Stone <dani...@collabora.com> wrote: > If the kernel tells us it's immutable, trying to set it probably isn't > going to succeed. > > Fixes a failure seen with the IN_FORMATS property. Pushed a v2 which removed most of the list with Daniel Vet

[Intel-gfx] [PATCH igt] tests/kms_properties: Don't set immutable properties

If the kernel tells us it's immutable, trying to set it probably isn't going to succeed. Fixes a failure seen with the IN_FORMATS property. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc: Daniel Vetter <daniel.vet...@intel.com> Cc: Ben Widawsky <b...@bwidawsk.

Re: [Intel-gfx] [PATCH] tests/kms_ccs: Fix the color/ccs surface generation

Hi Jason, On 4 August 2017 at 01:52, Jason Ekstrand wrote: > Previously, the test used the old 64x64 convention that Ville introduced > for CCS tiles and not the current 128x32 Y-tile convention. Also, the > original scheme for generating the CCS data was over-complicated

Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers

On 3 August 2017 at 18:21, Ben Widawsky <b...@bwidawsk.net> wrote: > On 17-08-03 12:00:56, Daniel Stone wrote: >> if (pipe >= PIPE_C || plane >= PLANE_SPRITE1) >> >> cf. skl_check_ccs_aux_surface() which rejects CCS on anything other >> than PRIMARY/

Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers

Hi, On 1 August 2017 at 17:58, Ben Widawsky wrote: > @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private > *dev_priv, > plane_formats = skl_plane_formats; > num_plane_formats = ARRAY_SIZE(skl_plane_formats); >

  1   2   3   4   >