From: Matthew Auld <matthew.auld@intel.com>
To: Maarten Lankhorst <dev@lankhorst.se>, intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Matthew Brost" <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs
Date: Fri, 26 Jun 2026 10:09:46 +0100 [thread overview]
Message-ID: <8ef2f0cf-629e-4b38-a467-e243f37f8285@intel.com> (raw)
In-Reply-To: <d5be431c-8393-4846-95b8-c30cbceed51b@lankhorst.se>
On 25/06/2026 16:35, Maarten Lankhorst wrote:
> Hello,
>
> On 6/12/26 19:05, Matthew Auld wrote:
>> Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
>> apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
>> -EINVAL if the BO is already VM_BINDed.
>>
>> However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
>> to make much sense since CPU caching policy is entirely controlled by
>> the exporter. Plus there is no place to set this flag, in the first
>> place. Also this is not rejected if not yet vm_binded, but that seems
>> arbitrary since setting or not setting FORCE_WC should a noop either
>> way, at this stage, and whether it is currently VM_BINDed makes no
>> difference.
>>
>> Currently if we run an app and offload rendering to an external dGPU,
>> like NV or another xe device, the dma-buf passed back to the compositor
>> (igpu) will be an actual external import from xe pov, and it will be
>> missing FORCE_WC, and if the compositor side did a VM_BIND before
>> turning into it into an fb the whole thing gets rejected.
>>
>> So it looks like we either need to reject outright, no matter what, or
>> this usecase is valid and we need to loosen the restriction for sg
>> buffers. Proposing here to loosen the restriction.
>>
>> Assisted-by: Gemini:gemini-3.1-pro-preview
>> Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
>> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Cc: Maarten Lankhorst <dev@lankhorst.se>
>> ---
>> drivers/gpu/drm/xe/display/xe_display_bo.c | 3 ++-
>> drivers/gpu/drm/xe/display/xe_fb_pin.c | 3 ++-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/display/xe_display_bo.c b/drivers/gpu/drm/xe/display/xe_display_bo.c
>> index 7fbac223b097..8953da0136dc 100644
>> --- a/drivers/gpu/drm/xe/display/xe_display_bo.c
>> +++ b/drivers/gpu/drm/xe/display/xe_display_bo.c
>> @@ -48,7 +48,8 @@ static int xe_display_bo_framebuffer_init(struct drm_gem_object *obj,
>> if (ret)
>> goto err;
>>
>> - if (!(bo->flags & XE_BO_FLAG_FORCE_WC)) {
>> + if (!(bo->flags & XE_BO_FLAG_FORCE_WC) &&
>> + bo->ttm.type != ttm_bo_type_sg) {
>> /*
>> * XE_BO_FLAG_FORCE_WC should ideally be set at creation, or is
>> * automatically set when creating FB. We cannot change caching
>> diff --git a/drivers/gpu/drm/xe/display/xe_fb_pin.c b/drivers/gpu/drm/xe/display/xe_fb_pin.c
>> index f93c98bec5b5..5f4a0cd8deca 100644
>> --- a/drivers/gpu/drm/xe/display/xe_fb_pin.c
>> +++ b/drivers/gpu/drm/xe/display/xe_fb_pin.c
>> @@ -331,7 +331,8 @@ static struct i915_vma *__xe_pin_fb_vma(struct drm_gem_object *obj, bool is_dpt,
>> int ret = 0;
>>
>> /* We reject creating !SCANOUT fb's, so this is weird.. */
>> - drm_WARN_ON(bo->ttm.base.dev, !(bo->flags & XE_BO_FLAG_FORCE_WC));
>> + drm_WARN_ON(bo->ttm.base.dev, !(bo->flags & XE_BO_FLAG_FORCE_WC) &&
>> + bo->ttm.type != ttm_bo_type_sg);
>>
>> if (!vma)
>> return ERR_PTR(-ENODEV);
>
> Yeah we cannot actually set the force flag on imported bo's for mmap coherency, but mmap on an imported dma-buf should be forbidden anyway, so that is fine.
>
> Best we can hope for is that dirtyfb is called correctly.
>
> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Thanks!
>
prev parent reply other threads:[~2026-06-26 9:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 17:05 [PATCH] drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs Matthew Auld
2026-06-12 17:26 ` ✓ CI.KUnit: success for " Patchwork
2026-06-12 18:23 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-13 10:39 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-06-25 15:35 ` [PATCH] " Maarten Lankhorst
2026-06-26 9:09 ` Matthew Auld [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=8ef2f0cf-629e-4b38-a467-e243f37f8285@intel.com \
--to=matthew.auld@intel.com \
--cc=dev@lankhorst.se \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.