From: "Summers, Stuart" <stuart.summers@intel.com>
To: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"Wang, X" <x.wang@intel.com>
Subject: Re: [PATCH v8 2/2] lib/intel_device_info: Query runtime xe device graphics versions
Date: Thu, 30 Oct 2025 20:51:26 +0000 [thread overview]
Message-ID: <6636a57ddbc6cd74848b3dfac6ecc1576f0a65a6.camel@intel.com> (raw)
In-Reply-To: <20251020231253.138842-3-x.wang@intel.com>
On Mon, 2025-10-20 at 23:12 +0000, Xin Wang wrote:
> For platforms with graphics_ver >= 20, query the runtime xe device
> ver
> instead of relying solely on hardcoded values from the PCI device
> table.
> This enables accurate IP minor version (graphics_rel) detection for
> platforms like Xe2 where different steppings have different IP
> versions.
>
> Implementation details:
> - Use weak symbol linkage for xe_ipver_cache_lookup() to handle
> static
> library compilation (libigt_chipset.a, libigt_device_scan.a)
> without
> xe_query.c dependencies which are used for i915 tools (i915_perf
> and
> intel_gpu_top)
> - Provide a weak stub that returns NULL when xe_query is not linked
> - For Gen20+ platforms, prefer runtime xe device versions over static
> data
> - Fall back to PCI table if xe device info is unavailable
> - Reset cache on query failure to allow retry
>
> Remove hardcoded graphics_rel from static table entries for xe
> devices
> as they will be populated at runtime from GMD_ID.
>
> This unifies device info handling between i915 and xe drivers,
> enabling:
> - Platform-specific workarounds based on accurate IP versions
> - Consistent device info API across both drivers
I'd personally drop this reference to unification of interfaces. The
implementations of the query interfaces between xe and i915 are already
different and could diverge even further over time, so this isn't a
true unification anyway.
>
> Signed-off-by: Xin Wang <x.wang@intel.com>
> ---
> lib/intel_device_info.c | 26 +++++++++++++++++++++++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
> index a853f9ab4..87b1069be 100644
> --- a/lib/intel_device_info.c
> +++ b/lib/intel_device_info.c
> @@ -3,6 +3,16 @@
> #include "i915_pciids_local.h"
>
> #include <strings.h> /* ffs() */
> +#include <stddef.h>
> +#include <string.h>
Why do you need string.h here?
> +
> +/* Weak symbol stub - will be overridden if xe_query.c is linked */
> +struct xe_device_ipver *xe_ipver_cache_lookup(uint32_t devid)
> __attribute__((weak));
> +
> +struct xe_device_ipver *xe_ipver_cache_lookup(uint32_t devid)
> +{
> + return NULL;
> +}
>
> static const struct intel_device_info intel_generic_info = {
> .graphics_ver = 0,
> @@ -505,7 +515,6 @@ static const struct intel_device_info
> intel_pontevecchio_info = {
>
> static const struct intel_device_info intel_lunarlake_info = {
> .graphics_ver = 20,
Sorry if I'm coming in late here... why don't we do this for
graphics_ver also? Then below you can just either check if graphics_ver
== 0 or use intel_gen()?
> - .graphics_rel = 4,
> .display_ver = 20,
> .has_4tile = true,
> .has_flatccs = true,
> @@ -517,7 +526,6 @@ static const struct intel_device_info
> intel_lunarlake_info = {
>
> static const struct intel_device_info intel_battlemage_info = {
> .graphics_ver = 20,
> - .graphics_rel = 1,
> .display_ver = 14,
> .has_4tile = true,
> .has_flatccs = true,
> @@ -529,7 +537,6 @@ static const struct intel_device_info
> intel_battlemage_info = {
>
> static const struct intel_device_info intel_pantherlake_info = {
> .graphics_ver = 30,
> - .graphics_rel = 0,
> .display_ver = 30,
> .has_4tile = true,
> .has_flatccs = true,
> @@ -675,6 +682,8 @@ const struct intel_device_info
> *intel_get_device_info(uint16_t devid)
> {
> static __thread const struct intel_device_info *cache =
> &intel_generic_info;
> static __thread uint16_t cached_devid;
> + static __thread struct intel_device_info xe_dev_info;
> + struct xe_device_ipver *ipver;
> int i;
>
> if (cached_devid == devid)
> @@ -689,6 +698,17 @@ const struct intel_device_info
> *intel_get_device_info(uint16_t devid)
> cached_devid = devid;
> cache = (void *)intel_device_match[i].match_data;
>
> + if (cache->graphics_ver >= 20) {
> + ipver = xe_ipver_cache_lookup(devid);
> + if (ipver && ipver->devid == devid) {
What is the expectation if we don't link in xe_query.c? Seems like it
would be better to just make this a hard requirement? Or since there is
a dependency here on igt_device_get()/put() we still want this backup
if we don't care about the versions?
Thanks,
Stuart
> + memcpy(&xe_dev_info, cache, sizeof(struct
> intel_device_info));
> + xe_dev_info.graphics_ver = ipver-
> >graphics_ver;
> + xe_dev_info.graphics_rel = ipver-
> >graphics_rel;
> + cache = &xe_dev_info;
> + } else {
> + cached_devid = 0;
> + }
> + }
> out:
> return cache;
> }
next prev parent reply other threads:[~2025-10-30 20:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 23:12 [PATCH v8 0/2] lib/intel_device_info: get the xe .graphics_rel from GMD_ID Xin Wang
2025-10-20 23:12 ` [PATCH v8 1/2] lib/xe/xe_query: Get runtime xe device graphics version " Xin Wang
2025-10-30 21:20 ` Summers, Stuart
2025-10-31 5:09 ` Wang, X
2025-10-31 15:45 ` Summers, Stuart
2025-11-07 19:39 ` Kamil Konieczny
2025-11-18 6:16 ` Wang, X
2025-10-20 23:12 ` [PATCH v8 2/2] lib/intel_device_info: Query runtime xe device graphics versions Xin Wang
2025-10-30 20:51 ` Summers, Stuart [this message]
2025-10-31 5:25 ` Wang, X
2025-10-31 15:21 ` Summers, Stuart
2025-11-07 19:47 ` Kamil Konieczny
2025-11-18 6:11 ` Wang, X
2025-12-12 15:56 ` [PATCH v8 2/2] lib/intel_device_info: Query runtime xe device graphics versionsth Vodapalli, Ravi Kumar
2025-12-12 16:49 ` Wang, X
2025-12-12 15:58 ` Vodapalli, Ravi Kumar
2025-10-21 3:05 ` ✓ i915.CI.BAT: success for lib/intel_device_info: get the xe .graphics_rel from GMD_ID Patchwork
2025-10-21 7:20 ` ✓ Xe.CI.BAT: " Patchwork
2025-10-21 8:59 ` ✗ Xe.CI.Full: failure " Patchwork
2025-10-21 12:36 ` Patchwork
2025-10-21 18:27 ` ✓ i915.CI.Full: success " Patchwork
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=6636a57ddbc6cd74848b3dfac6ecc1576f0a65a6.camel@intel.com \
--to=stuart.summers@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=x.wang@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).