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: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Wed, 15 Feb 2023 at 20:54, Harry Wentland wrote: > On 2/15/23 06:46, Daniel Stone wrote: > > On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote: > >> On 2/14/23 10:49, Sebastian Wick wrote: > >> From what I've seen recently I am inclined to favor an incremental >

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

Hi, On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote: > On 2/14/23 10:49, Sebastian Wick wrote: > From what I've seen recently I am inclined to favor an incremental > approach more. The reason is that any API, or portion thereof, is > useless unless it's enabled full stack. When it isn't it

Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

On Sun, 1 May 2022 at 08:08, Paul Menzel wrote: > Am 26.04.22 um 15:53 schrieb Gong, Richard: > > I think so. We captured dmesg log. > > Then the (whole) system did *not* freeze, if you could still log in > (maybe over network) and execute `dmesg`. Please also paste the > amdgpu(?) error logs in

Re: 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: 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: [PATCH v2 1/2] drm: Add GPU reset sysfs event

Hi, On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote: > On Mon, Mar 21, 2022 at 2:30 AM Christian König > wrote: > > Well you can, it just means that their contexts are lost as well. > > Which is rather inconvenient when deqp-egl reset tests, for example, > take down your compositor ;-) Yeah. Or

Re: 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: [PATCH v2 1/2] drm: Add GPU reset sysfs event

Hi, On Thu, 17 Mar 2022 at 09:21, Christian König wrote: > Am 17.03.22 um 09:42 schrieb Sharma, Shashank: > >> AFAIU you probably want to be passing around a `struct pid *`, and > >> then somehow use pid_vnr() in the context of the process reading the > >> event to get the numeric pid.

Re: [RFC PATCH v2 0/3] Add support modifiers for drivers whose planes only support linear layout

Hi Esaki-san, On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote: > Some drivers whose planes only support linear layout fb do not support format > modifiers. > These drivers should support modifiers, however the DRM core should handle > this > rather than open-coding in every driver. > > In

Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread

Hi Monk, On Thu, 2 Sept 2021 at 06:52, Liu, Monk wrote: > I didn't mean your changes on AMD driver need my personal approval or review > ... and I'm totally already get used that our driver is not 100% under > control by AMDers, > but supposedly any one from community (including you) who tend

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

Hi Mark, On Wed, 24 Mar 2021 at 14:58, Mark Yacoub wrote: > So you mean it would make more sense to be more explicit in handling > DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just like > DRM_FORMAT_MOD_LINEAR, will return true in > dm_plane_format_mod_supported)? > That's

Re: [PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen wrote: > On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote: > >> No modifier support does not imply linear. It's generally signalled via >> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver >> specific mechanisms". >>

Re: [PATCH 0/3] Use implicit kref infra

Hi Luben, On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote: > Not sure how I can do this when someone doesn't want to read up on > the kref infrastructure. Can you help? > > When someone starts off with "My understanding of ..." (as in the OP) you > know you're > in trouble and in for a rough

Re: [PATCH 0/3] Use implicit kref infra

Hi Luben, On Wed, 2 Sep 2020 at 15:51, Luben Tuikov wrote: > Of course it's true--good morning! > > Let me stop you right there--just read the documentation I pointed > to you at. > > No! > > I'm sorry, that doesn't make sense. > > No, that's horrible. > > No, that's horrible. > > You need to

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: [pull] amdgpu, amdkfd drm-next-5.8

Hi, On Thu, 14 May 2020 at 14:36, Alex Deucher wrote: > On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote: > > Did this ever go through uAPI review? It's been pushed to the kernel > > before Mesa review was complete. Even then, Mesa only uses it when > > behind a magic

Re: [pull] amdgpu, amdkfd drm-next-5.8

Hi Alex, On Thu, 30 Apr 2020 at 22:30, Alex Deucher wrote: > UAPI: > - Add amdgpu UAPI for encrypted GPU memory > Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401 Did this ever go through uAPI review? It's been pushed to the kernel before Mesa review was complete. Even

Re: 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: [Mesa-dev] [Intel-gfx] 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: 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: [PATCH][next[ drm/amd/display: fix a couple of spelling mistakes

Hi Colin, On Wed, 26 Jun 2019 at 14:24, Colin King wrote: > There are a couple of spelling mistakes in dm_error messages and > a comment. Fix these. Whilst there, you might fix the '[next[' typo in the commit message. Cheers, Daniel

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: [RFC] drm/amdgpu: Add macros and documentation for format modifiers.

Hi, On Tue, 4 Sep 2018 at 11:44, Christian König wrote: > Am 04.09.2018 um 12:15 schrieb Daniel Stone: > > Right. The conclusion, after people went through and started sorting > > out the kinds of formats for which they would _actually_ export real > > colour buffers f

Re: [RFC] drm/amdgpu: Add macros and documentation for format modifiers.

Hi, On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote: > On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen > wrote: > > +/* The chip this is compatible with. > > + * > > + * If compression is disabled, use > > + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8 > > + * - AMDGPU_CHIP_VEGA10 for GFX9+ > >

Re: [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: [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: 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: gitlab migration

Hi Alexander, On 12 June 2018 at 14:53, Alexander E. Patrakov wrote: > Daniel Stone : >> > That said, I could not even create an account with a noscript/xhtml basic >> > browser (if you want to test that, install the famous noscript module with >> > an >

Re: gitlab migration

Hi Sylvain, On 12 June 2018 at 13:38, wrote: > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: >> GitLab has a pretty comprehensive and well-documented API which might >> help if you don't want to use a web browser. There are also clients >> like 'lab

Re: gitlab migration

Hi Michel, On 11 June 2018 at 11:33, Michel Dänzer wrote: > On 2018-06-08 08:08 PM, Adam Jackson wrote: >> I'd like us to start moving repos and bug tracking into gitlab. >> Hopefully everyone's aware that gitlab exists and why fdo projects are >> migrating to it. If not, the thread about Mesa's

Re: gitlab migration

Hi Sylvain, It looks like Mutt is mangling email addresses - I've fixed Michel's. On 11 June 2018 at 14:30, wrote: > On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote: >> Adding the amd-gfx list, in cases somebody there has concerns or other >> feedback. > > For feedback: > I

Re: RFC for a render API to support adaptive sync and VRR

Hi, On 20 April 2018 at 21:32, Manasi Navare wrote: > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote: >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote: >> > I'd also encourage using a single unit for all of these values, >> >

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

Hi Alex, On 30 March 2018 at 15:47, Alex Deucher <alexdeuc...@gmail.com> wrote: > On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone <dani...@collabora.com> wrote: >> I intend to remove create_handle when all drivers are converted over >> to placing BOs directly insid

[PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc

[PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc

[PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone <dani...@collabora.com> Cc

[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: [PATCH 0/6] drm: tackle byteorder issues, take two

Hi, On 24 April 2017 at 15:26, Ville Syrjälä wrote: > On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote: >> On 24/04/17 04:36 PM, Gerd Hoffmann wrote: >> > When running in opengl mode there will be a hardware-specific mesa >> > driver in userspace,

Re: [RFC] Using DC in amdgpu for upcoming GPU

Hi Harry, I've been loathe to jump in here, not least because both cop roles seem to be taken, but ... On 13 December 2016 at 01:49, Harry Wentland wrote: > On 2016-12-11 09:57 PM, Dave Airlie wrote: >> On 8 December 2016 at 12:02, Harry Wentland

Re: [PATCH 0/6] drm: Explicit target vblank seqno for page flips

On 4 August 2016 at 11:01, Michel Dänzer <mic...@daenzer.net> wrote: > On 04.08.2016 18:51, Daniel Stone wrote: >> On 4 August 2016 at 04:39, Michel Dänzer <mic...@daenzer.net> wrote: >>> Patch 6 extends the ioctl with new flags, which allow userspace to >>&g