From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Thomas Hellstrom <thomas.hellstrom@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
Carlos Santa <carlos.santa@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [Intel-xe] LLC configurating, mmap and bo cache management questions
Date: Tue, 5 Dec 2023 14:19:23 +0000 [thread overview]
Message-ID: <02c74379-6513-40cc-a195-c4eeb7a7fd79@linux.intel.com> (raw)
Hi,
We are working on adding xe support to ChromeOS minigbm and have a
couple questions.
If I follow things correctly with xe mmap caching mode is fixed to
object caching modes set at bo create. For framebuffers it will be WC
and for the rest userspace can choose WB or WC via
drm_xe_gem_create->cpu_caching. (Unless discrete, when WB cannot be used
at all.)
AFAICT minigbm basically cares about two transition points. Lets call
them CPU access begin and end.
1)
When a bo is mmapped it wants to invalidate the cache, which looks to be
about making sure all GPU writes have landed to the backing store. In
the i915 world that translates to the set_domain ioctl.
What is the uapi for this with xe, or it is somehow guaranteed to not be
needed?
2)
When a bo is unmapped, or CPU access finished, it wants to flush the CPU
caches. That is /almost/ completely a CPU operation, where it just needs
to either clflush or invalidate the WC buffer respectively, if not the
fact that clflush can be skipped on platforms with LLC.
I did not see an equivalent of an I915_PARAM_HAS_LLC in xe? Did I miss
it or what it is the plan for querying this detail?
Regards,
Tvrtko
next reply other threads:[~2023-12-05 14:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 14:19 Tvrtko Ursulin [this message]
2023-12-06 8:26 ` [Intel-xe] LLC configurating, mmap and bo cache management questions Hellstrom, Thomas
2023-12-06 10:58 ` Tvrtko Ursulin
2023-12-06 11:46 ` Hellstrom, Thomas
2023-12-07 11:11 ` Tvrtko Ursulin
2023-12-07 12:01 ` Thomas Hellström
2023-12-13 11:55 ` Tvrtko Ursulin
2023-12-13 17:27 ` Thomas Hellström
2023-12-13 17:50 ` Tvrtko Ursulin
2023-12-13 20:11 ` Thomas Hellström
2023-12-14 8:10 ` Tvrtko Ursulin
2023-12-14 10:52 ` Thomas Hellström
2023-12-14 12:34 ` Tvrtko Ursulin
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=02c74379-6513-40cc-a195-c4eeb7a7fd79@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=carlos.santa@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@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