dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Himal Prasad Ghimiray" <himal.prasad.ghimiray@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Boris Brezillon" <bbrezillon@kernel.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v6 04/26] drm/gpuvm: Introduce DRM_GPUVM_SM_MAP_OPS_FLAG_SPLIT_MADVISE flag
Date: Sat, 09 Aug 2025 15:23:45 +0200	[thread overview]
Message-ID: <DBXXHBNTM105.2DTBKIO95D5UI@kernel.org> (raw)
In-Reply-To: <20250807164338.1832254-5-himal.prasad.ghimiray@intel.com>

On Thu Aug 7, 2025 at 6:43 PM CEST, Himal Prasad Ghimiray wrote:
> - DRM_GPUVM_SM_MAP_OPS_FLAG_SPLIT_MADVISE: This flag is used by
>   drm_gpuvm_sm_map_ops_create to iterate over GPUVMA's in the
> user-provided range and split the existing non-GEM object VMA if the

What do you mean with non-GEM object VMA? I assume you just mean sparse
mappings?

> start or end of the input range lies within it. The operations can
> create up to 2 REMAPS and 2 MAPs.

Wait -- that doesn't make sense with what I thought how this works.

In the RFC you gave the following example:

	Example:
	Input Range: 0x00007f0a54000000 to 0x00007f0a54400000
	GPU VMA: 0x0000000000000000 to 0x0000800000000000
	Operations Result:
	- REMAP:UNMAP: addr=0x0000000000000000, range=0x0000800000000000
	- REMAP:PREV: addr=0x0000000000000000, range=0x00007f0a54000000
	- REMAP:NEXT: addr=0x00007f0a54400000, range=0x000000f5abc00000
	- MAP: addr=0x00007f0a54000000, range=0x0000000000400000

That's exactly the same what the existing logic does. So in which case do you
have *two* MAP operations?

For completeness, the other example you gave was:

	Example:
	Input Range: 0x00007fc898800000 to 0x00007fc899000000
	GPU VMAs:
	- 0x0000000000000000 to 0x00007fc898800000
	- 0x00007fc898800000 to 0x00007fc898a00000
	- 0x00007fc898a00000 to 0x00007fc898c00000
	- 0x00007fc898c00000 to 0x00007fc899000000
	- 0x00007fc899000000 to 0x00007fc899200000
	Operations Result: None

This just means, if things are split already, at the defined edges, just don't
do anything, which is also conform with the existing logic except for the "no
merge" part, which is obviously fine given that it's explicitly for splitting
things.

Can you please provide some additional *simple* examples, like the documentation
of GPUVM does today for the normal split/merge stuff? I.e. please don't use
complex real addresses, that makes it hard to parse.

Also, can you please provide some information on what this whole thing does
*semantically*? I thought I understood it, but now I'm not so sure anymore.

> The purpose of this operation is to be
> used by the Xe driver to assign attributes to GPUVMA's within the
> user-defined range.

Well, hopefully it's useful to other drivers as well. :)

> Unlike drm_gpuvm_sm_map_ops_flags in default mode,
> the operation with this flag will never have UNMAPs and
> merges, and can be without any final operations.

I really think this is significant enough of a feature to add some proper
documentation about it.

Please add a separate section about madvise operations to the documentation at
the beginning of the drivers/gpu/drm/drm_gpuvm.c file.

>
> v2
> - use drm_gpuvm_sm_map_ops_create with flags instead of defining new
>   ops_create (Danilo)

If this turns out not to be what I thought semantically and we still agree it's
the correct approach, I think I have to take this back and it should indeed be
an entirely separate code path. But let's wait for your answers above.

Again, I really think this needs some proper documentation like in the
"DOC: Split and Merge" documentation section.

  parent reply	other threads:[~2025-08-09 13:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250807164338.1832254-1-himal.prasad.ghimiray@intel.com>
2025-08-07 16:43 ` [PATCH v6 01/26] drm/gpuvm: Pass map arguments through a struct Himal Prasad Ghimiray
2025-08-08  5:03   ` Matthew Brost
2025-08-09 12:43   ` Danilo Krummrich
2025-08-11  6:54     ` Ghimiray, Himal Prasad
2025-08-12 16:51   ` Danilo Krummrich
2025-08-12 17:55     ` Ghimiray, Himal Prasad
2025-08-07 16:43 ` [PATCH v6 03/26] drm/gpuvm: Support flags in drm_gpuvm_map_req Himal Prasad Ghimiray
2025-08-08  5:04   ` Matthew Brost
2025-08-09 12:46   ` Danilo Krummrich
2025-08-11  6:56     ` Ghimiray, Himal Prasad
2025-08-07 16:43 ` [PATCH v6 04/26] drm/gpuvm: Introduce DRM_GPUVM_SM_MAP_OPS_FLAG_SPLIT_MADVISE flag Himal Prasad Ghimiray
2025-08-08  5:20   ` Matthew Brost
2025-08-09 13:23   ` Danilo Krummrich [this message]
2025-08-11  6:52     ` Ghimiray, Himal Prasad
2025-08-12 16:06       ` Danilo Krummrich
2025-08-12 17:52         ` Ghimiray, Himal Prasad
2025-08-12 16:58   ` Danilo Krummrich
2025-08-12 17:54     ` Ghimiray, Himal Prasad

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=DBXXHBNTM105.2DTBKIO95D5UI@kernel.org \
    --to=dakr@kernel.org \
    --cc=bbrezillon@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).