From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel@ffwll.ch>, Dave Airlie <airlied@redhat.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 0/1] drm: Add a gpu page-table walker
Date: Mon, 27 Feb 2023 09:07:26 +0100 [thread overview]
Message-ID: <ec302d85-4b84-fb5e-ff52-2e4183f18b58@linux.intel.com> (raw)
In-Reply-To: <CADnq5_Mfp4pCnVcsWn_vMO-hWcMhH_yb8MHccyp_jEL=XxgZNg@mail.gmail.com>
Hi,
On 2/23/23 19:50, Alex Deucher wrote:
> On Thu, Feb 23, 2023 at 10:03 AM Thomas Hellström
> <thomas.hellstrom@linux.intel.com> wrote:
>> Hi, Daniel,
>>
>> On 2/16/23 21:18, Daniel Vetter wrote:
>>> On Thu, Feb 16, 2023 at 05:27:28PM +0100, Thomas Hellström wrote:
>>>> A slightly unusual cover letter for a single patch.
>>>>
>>>> The page table walker is currently used by the xe driver only,
>>>> but the code is generic so we can be good citizens and add it to drm
>>>> as a helper, for possible use by other drivers,
>>>> If so we can merge the commit when we merge the xe driver.
>>>>
>>>> The question raised here is
>>>> *) Should it be a generic drm helper or xe-specific with changed
>>>> prefixes?
>>> I think if there's some other drivers interested in using this, then this
>>> sounds like a good idea. Maybe more useful if it's also integrated into
>>> the vm/vma helpers that are being discussed as an optional part?
>>>
>>> Maybe some good old sales pitching here to convince people would be good.
>>>
>>> Maybe one of the new accel drivers is interested in this too?
>> Thanks for your thoughts on this. Yeah, I think it's a bit awkward to
>> push for having code generic when there is only one user, and the
>> prospect of having other drivers rewrite their page-table building code
>> based on this helper in the near future is probably small. Perhaps more
>> of interest to new drivers. I think what will happen otherwise is that
>> during some future cleanup this will be pushed down to xe claiming it's
>> the only user.
>>
>> I wonder whether it might be an idea to maintain a small document where
>> driver writers can list suggestions for code that could be lifted to
>> core drm and be reused by others. That way both reviewers and writers of
>> other drivers can keep an eye on that document and use it to avoid
>> duplicating code. The procedure would then be to lift it to core drm and
>> fix up prefixes as soon as we have two or more users.
>>
>> Thoughts?
> FWIW, when we originally wrote the GPU scheduler it was part of
> amdgpu, but we consciously kept any AMD-isms out of it so it could be
> lifted up to a core component when another user came along. Maybe
> some comments in the top of those files to that effect to maintain the
> separation.
Sure. I'll do that. It sounds like we'll keep this in xe for now.
Thanks,
/Thomas
> Alex
>
>
>> Thomas
>>
>>
>>>> *) If a drm helper, should we use a config option?
>>> I am no fan of Kconfig things tbh. Maybe just include it in the vma
>>> helpers, or perhaps we want to do a drm-accel-helpers with gem helpers,
>>> drm/sched, this one here, vm/vma helpers or whatever they will be and so
>>> on? Kinda like we have modeset helpers.
>>>
>>> I'd definitely not go for a Kconfig per individual file, that's just
>>> excessive.
>>> -Daniel
>>>
>>>> For usage examples, see xe_pt.c
>>>> https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/xe_pt.c
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>> Thomas Hellström (1):
>>>> drm: Add a gpu page-table walker helper
>>>>
>>>> drivers/gpu/drm/Makefile | 1 +
>>>> drivers/gpu/drm/drm_pt_walk.c | 159 +++++++++++++++++++++++++++++++++
>>>> include/drm/drm_pt_walk.h | 161 ++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 321 insertions(+)
>>>> create mode 100644 drivers/gpu/drm/drm_pt_walk.c
>>>> create mode 100644 include/drm/drm_pt_walk.h
>>>>
>>>> --
>>>> 2.34.1
>>>>
prev parent reply other threads:[~2023-02-27 8:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 16:27 [Intel-xe] [PATCH 0/1] drm: Add a gpu page-table walker Thomas Hellström
2023-02-16 16:27 ` [Intel-xe] [PATCH 1/1] drm: Add a gpu page-table walker helper Thomas Hellström
2023-02-16 20:18 ` [Intel-xe] [PATCH 0/1] drm: Add a gpu page-table walker Daniel Vetter
2023-02-23 14:38 ` Thomas Hellström
2023-02-23 18:50 ` Alex Deucher
2023-02-26 18:56 ` Oded Gabbay
2023-02-27 8:09 ` Thomas Hellström
2023-02-27 15:07 ` Stanislaw Gruszka
2023-02-27 8:07 ` Thomas Hellström [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec302d85-4b84-fb5e-ff52-2e4183f18b58@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@redhat.com \
--cc=alexdeucher@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox