Re: [PATCH 6/7] drm: Document fdinfo format specification

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
	Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Christian König" <christian.koenig@amd.com>,
	"Chris Healy" <cphealy@gmail.com>,
	"David M Nieto" <David.Nieto@amd.com>
Subject: Re: [PATCH 6/7] drm: Document fdinfo format specification
Date: Thu, 20 Jan 2022 10:30:47 +0000	[thread overview]
Message-ID: <1cac5ccf-c49b-a584-f802-a89cb5d4bfb5@linux.intel.com> (raw)
In-Reply-To: <YegpiY3MU15RsEfk@phenom.ffwll.local>

On 19/01/2022 15:08, Daniel Vetter wrote:
> On Thu, Jan 06, 2022 at 04:55:35PM +0000, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Proposal to standardise the fdinfo text format as optionally output by DRM
>> drivers.
>>
>> Idea is that a simple but, well defined, spec will enable generic
>> userspace tools to be written while at the same time avoiding a more heavy
>> handed approach of adding a mid-layer to DRM.
>>
>> i915 implements a subset of the spec, everything apart from the memory
>> stats currently, and a matching intel_gpu_top tool exists.
>>
>> Open is to see if AMD can migrate to using the proposed GPU utilisation
>> key-value pairs, or if they are not workable to see whether to go
>> vendor specific, or if a standardised  alternative can be found which is
>> workable for both drivers.
>>
>> Same for the memory utilisation key-value pairs proposal.
>>
>> v2:
>>   * Update for removal of name and pid.
>>
>> v3:
>>   * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel)
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: David M Nieto <David.Nieto@amd.com>
>> Cc: Christian König <christian.koenig@amd.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Daniel Stone <daniel@fooishbar.org>
>> Cc: Chris Healy <cphealy@gmail.com>
>> Acked-by: Christian König <christian.koenig@amd.com>
> 
> I'm assuming this ack here and later on is a "amdgpu plans to use this
> too" kind of affair. Especially also in the lights of eventually using
> matching semantics for cgroups and everything else tied to gpu execution
> resource management.
> 
> If not I'm mildly worried that we're creating fake-standard stuff here
> which cannot actually be used by anything resembling driver-agnostic
> userspace.

Hard to say how much adoption there would be.

At least on the statement of that the proposed spec cannot be used for 
driver agnostic userspace, do you have concrete concerns with the spec I 
proposed, or are just going by the lack of continuous engagement by any 
third party?

Apart from AMD, during past postings Daniel Stone also had positive 
feedback (along the lines of "works the driver I am familiar with"). I 
don't know if I have missed someone else who provided feedback, hope not.

There is of course the option of dropping the idea of trying to document 
a common spec, or to do anything cross-driver at this point. AFAIR it 
was your push to try this, and I agreed it would be a good thing if it 
worked out. But given AMD already exposes stuff in fdinfo, I don't think 
it would be a blocker for merging the i915 side even if we decided to 
drop the standardisation effort for now. Given I am maintaining this 
i915 code from ~2018 and there is a lot of interest from users it would 
be good to put it in.

Regards,

Tvrtko