zesDeviceProcessesGetState is returning 78000003 (ZE_RESULT_ERROR_UNSUPPORTED_FEATURE) #809
Comments
|
Adding additional context; it looks like the device handle I was using was for the integrated Intel UHD 770: Output while UHD 770 is running a workload, and I monitor the UHD 770: I had mistakenly thought the B580 would have engine groups, so mistook the existence of engine groups meaning it was running on the B580. So while When I run the workload on the B580 and and monitor it, Output while running workload on B580 and monitor its usage: An oddity is when running the workload on the integrated GPU (i915) the query to the B580 for process stats is showing the process that the i915 driver is using, but with no engine group flags: Output while UHD 770 is running a workload, and I monitor the B580: |
|
@jketreno we will look into internally and update you |
[Sai] XE driver upstream patch is in review and waiting for merge. once it is ready, it will merge and regarding other issue you raised for UHD770 , we able to see its working as per below log root@DUT6051BMGSVC:/home/gta/level_zero/bin# export ZELLO_SYSMAN_USE_ZESINIT=1; export ZES_ENABLE_SYSMAN=1; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/gta/level_zero/libs/:/home/gta/level_zero/latest_loa der/:/home/gta/level_zero/bin/; |
|
This looks like relevant kernel patch series, but it's for Xe KMD tree, not upstream: https://patchwork.freedesktop.org/series/144408/ |
Reproduction of U770 failureRunning Ubuntu Oracular (24.10) with the linux-intel kernel and all other packages updated to latest versions as of 2025-02-20. Find version of libze-intel-gpu1 on systemGet compute-runtime source matching the version of libze-intel-gpu1Build zello_sysmanTestOutput: |
I see it is failing in the patch tests: Assuming those errors get fixed, am I correct that the flow will be Xe KMD tree -> DRM next -> DRM -> kernel.org? Or would these go straight to kernel.org as a bug fix to the existing Xe KMD driver? Or might they get picked up in the linux-intel kernel in the Ubuntu intel-graphics PPA? I'm just trying to figure out if I should abandon trying to get the B580 to work for a few more months while I wait for these patches to land, or if there might be a shorter path. I'm not too keen on rip/replace my system's kernel with one I build from source as I tend to end up with other random system failures anytime I use a tip-of-tree kernel and I'm trying to keep this system as a "production" config vs. a franken-developer config :) Thanks, |
I'm not a kernel developer, but it's a new feature (for the Xe KMD), and I would think even bug fixes normally go through DRM integration tree, to make sure they do not break anything.
I'm not familiar with that. Ubuntu HWE packages are LTS backports from things that have been tested for few months in latest non-LTS releases, so those would have quite a lot of delay, but I guess PPAs could include anything. I don't think they would do backporting though, at least not for things like metrics, which do not block using the HW. So either it would be upstream kernel with the Xe stuff already merged, or kernel test package from the Xe driver repo. In latter case, I personally I would rather build test kernels myself. One might be able to fork-lift latest driver source from the driver integration repo to distro (HWE) kernel version sources; either whole driver, or specific source file(s). If you do that, you could notify upstream whether it worked or not (add your
While one could use stripped distro kernel config for building own kernels, to speed up the builds, I'd use the configs as-is (as much as possible), when wanting to make sure everything works as expected. If you do build your own kernel and it fails, it would be good to notifty upstream about that, at least about reproducible issues. |
|
Patches have been merged to DRM subsystem integration trees:
But are not yet upstream: |
|
I downloaded a tarball of the drm-xe-next and I now see temperature sensors reporting: However, I'm still not seeing engines. I do see engines with the i915 driver: Are there changes in L0 needed to use the added perf interface on the Xe driver? I'm still seeing the error with L0 Sysman when I call zesDeviceProcessesGetState() on the i915 driver: |
Btw. I would suggest using tagged version of that, if you are not. AFAIK integration trees are rebased to upstream kernel regularly and I would suggest using something that's rebased (close) on a upstream release version, not something rebased e.g. on rc1 release (where most of new changes for next kernel release are merged, and not yet stabilized).
Does
Did you mean Xe driver, not i915 one? |
I'll keep my eye open for such a tree; while the tree I used did start showing temperature sensors via L0, docker no longer worked so I had to revert back to the linux-intel kernel from the Canonical PPA.
I wasn't sure how to use As a side note, I haven't added code to my utility to query
For the UHD 770 (integrated Raptor Lake graphics) it is using the i915 kernel driver, which gives the ZE_RESULT_ERROR_UNSUPPORTED_FEATURE when calling If I block i915 from being 8000 used and instead have the U770 use the Xe driver, it doesn't list engines (with the linux-intel kernel), however it can report the processes being used: This is the URL for the little utility I'm building: Cheers, |
Patch series show examples on that:
Btw. Looking at the first series commits, you need also new enough GuC version: |
|
To update for anyone that finds this in the future. I just built kernel.org from source for 6.15-rc2 and installed the latest guc and huc from linux-firmware.git (prior to updating GuC, dmesg reported the engine activity required a newer version of GuC): After a reboot: While perf seems to list the counters, they are not being surfaced from L0 using libze-intel-gpu1 25.05.32567.18 for the B580 via Xe. The U770 still reports engines through i915: Minimal test case I'm using: cat << EOF > engines.c
#include <level_zero/ze_api.h> // for _ze_result_t, ze_result_t, ZE_MAX_DE...
#include <level_zero/zes_api.h> // for zes_device_handle_t, _zes_structure_...
#include <stdio.h> // for printf, fprintf, stderr, size_t, NULL
#include <malloc.h> // for free, calloc
#define nullptr NULL
// gcc -o engines engines.c -I/usr/include/ze -lze_loader
int main() {
if (zesInit(0) != ZE_RESULT_SUCCESS)
{
printf("Can't initialize the API\n");
return -1;
}
// Discover all the drivers
uint32_t driversCount = 0;
zesDriverGet(&driversCount, nullptr);
if (driversCount == 0)
{
fprintf(stderr, "No ze sysman drivers found.\n");
return 1;
}
printf("%d drivers found\n", driversCount);
// Allocate memory for driver handles
zes_driver_handle_t *drivers = (zes_driver_handle_t *)calloc(driversCount, sizeof(zes_driver_handle_t));
8000
if (!drivers)
{
fprintf(stderr, "Memory allocation failed for drivers\n");
return 1;
}
zesDriverGet(&driversCount, drivers);
for (uint32_t driver = 0; driver < driversCount; ++driver)
{
// Discover devices in a driver
uint32_t deviceCount = 0;
zesDeviceGet(drivers[driver], &deviceCount, nullptr);
if (deviceCount == 0)
{
printf("Driver %i:\n No devices found\n", driver);
continue;
}
printf("Driver %i:\n %d devices found\n", driver, deviceCount);
// Allocate memory for device handles
zes_device_handle_t * deviceHandles = (zes_device_handle_t *)calloc(deviceCount, sizeof(zes_device_handle_t));
if (!deviceHandles)
{
printf("Memory allocation failed for devices\n");
return 1;
}
zesDeviceGet(drivers[driver], &deviceCount, deviceHandles);
// Walk through each device and get properties
for (uint32_t device = 0; device < deviceCount; ++device)
{
uint32_t count = 0;
ze_result_t result;
zes_device_properties_t deviceProperties = {
.stype = ZES_STRUCTURE_TYPE_DEVICE_PROPERTIES,
};
result = zesDeviceGetProperties(deviceHandles[device], &deviceProperties);
if (result != ZE_RESULT_SUCCESS)
{
fprintf(stderr, "zesDeviceGetProperties failed: %08x\n", result);
return 1;
}
printf("Device %d: %04X:%04X (%s)\n",
device,
deviceProperties.core.vendorId,
deviceProperties.core.deviceId,
deviceProperties.modelName);
result = zesDeviceEnumEngineGroups(deviceHandles[device], &count, nullptr);
if (result != ZE_RESULT_SUCCESS)
{
fprintf(stderr, "Failed to enumerate engine groups: %08x\n", result);
return 1;
}
printf("Device %d: %d engine groups found\n", device, count);
if (count > 0)
{
zes_engine_handle_t *engineHandles = (zes_engine_handle_t *)calloc(count, sizeof(zes_engine_handle_t));
result = zesDeviceEnumEngineGroups(deviceHandles[device], &count, engineHandles);
if (result != ZE_RESULT_SUCCESS)
{
fprintf(stderr, "Failed to retrieve engine groups: %08x\n", result);
return 0;
}
for (size_t i = 0; i < count; ++i)
{
zes_engine_properties_t engineProperties = {
.stype = ZES_STRUCTURE_TYPE_ENGINE_PROPERTIES,
};
result = zesEngineGetProperties(engineHandles[i], &engineProperties);
if (result != ZE_RESULT_SUCCESS)
{
fprintf(stderr, "Failed to retrieve engine properties: %08x\n", result);
return 0;
}
printf("Engine %zu: Type %d\n", i, engineProperties.type);
}
}
}
}
return 0;
}
EOFThen compile engines.c and run it via sudo: Note the '0 engine groups found' for the B580 (device 0): Am I missing something? Thanks, |
|
Looking at the test code, you need either to set
(You could use |
|
Thanks for taking the time to look through the example; it was a simplified minimal quick case I put together to show the problem -- I've updated the code to use calloc to initialize all the values to 0. The problem persists, however -- engine groups are found for the U770 but not for the B580. |
|
Properties struct definitions still have undefined |
|
Those structures are using designated initializers to initialize the structures to 0 except for the fields explicitly set to a value. |
|
Ah, right, when at least one member is initialized, C99+ initializes rest to zero/NULL. And if perf sees the engine activity counters, then FW + Xe KMD should be fine, and problem is indeed on UMD side i.e. this project/repo. |
|
Since this issue was originally titled about the ZE_RESULT_ERROR_UNSUPPORTED_FEATURE with the U770, and the engine activity issue on the B580 was discovered while looking into that topic, should I re-file a new issue that covers that part? |
|
Yes, separate tickets for separate issues please. |
I'm writing a small ze-top like utility to monitor the B580. It looks like zesDeviceProcessesGetState should be able to tell me the info for processes using the GPU. However, it always returns ZE_RESULT_ERROR_UNSUPPORTED_FEATURE. That error return code is documented for other APIs, but doesn't seem to be in the list of valid return codes for zesDeviceProcessesGetState
I have a valid device handle, which I'm using to call zesDeviceEnumEngineGroups to get usage info from the engines, and that's working well.
I've tried running as sudo in case there was a permissions issue, but that didn't help.
The above outputs:
I've tried setting processCount to 0 to have it tell me how many process items to use, but that has the same error code returned.
I'm using libze-intel-gpu1 version 24.52.32224.5-1
24.10ppa2, and libze1 version 1.19.2.0-1076~24.10.Thanks,
James
The text was updated successfully, but these errors were encountered: