You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two issues we would like to address here:
As mentioned in oneapi-src/level-zero#36, there's a desired to have an API to enable SYSMAN, instead of an environment variable.
Additionally, there are frequent requests to add to Core API an interface that provides similar functionality to one already existing on SYSMAN. An example is zesMemoryGetState, which provides info on available memory in the system. Adding an interface on Core for something that is already provided on SYSMAN duplicates code, and is not scalable in the long run. So it is better to allow for SYSMAN interfaces to be used with Core when the application needs it.
To provide a solution to these two issues, a new set of interfaces is being proposed to enable and access SYSMAN functionality. Idea is to provide interfaces to enable SYSMAN, as well as to discover SYSMAN devices, which will be used to access underlying functionality.
Initial proposal is the following, where we have zesInit, zesDriverSupported, and zesGetDevice.
function main( ... )
if (zeInit(0) != ZE_RESULT_SUCCESS || zesInit() != ZE_RESULT_SUCCESS)
output("Can't initialize the API")
else
# Discover all the drivers
uint32_t driversCount = 0zeDriverGet(&driversCount, nullptr)
ze_driver_handle_t* allDrivers = allocate(driversCount * sizeof(ze_driver_handle_t))
zeDriverGet(&driversCount, allDrivers)
ze_driver_handle_t hDriver = nullptr
for(i = 0 .. driversCount-1)
if (zesDriverSupported(allDrivers[i]) == false)
continue
# Discover devices in a driver
uint32_t deviceCount = 0zeDeviceGet(allDrivers[i], &deviceCount, nullptr)
ze_device_handle_t* allDevices =
allocate_memory(deviceCount * sizeof(ze_device_handle_t))
zeDeviceGet(allDrivers[i], &deviceCount, allDevices)
for(devIndex = 0 .. deviceCount-1)
ze_device_properties_t device_properties
zeDeviceGetProperties(allDevices[devIndex], &device_properties)
if(ZE_DEVICE_TYPE_GPU != device_properties.type)
next
# Get the Sysman device handle. Returns null if device is not supported.
zes_device_handle_t hSysmanDevice = zesGetDevice(allDevices[devIndex])
# Start using hSysmanDevice to manage the device
free_memory(...)
Would we want this to be zesDriverSupported(hDriver) or would it make more sense to have zesDeviceSupported(hDevice)? In other words, would all devices supported by a driver always support sysman, or could some devices support sysman and some other devices not support sysman?
What would the behavior be for zesGetDevice(hDevice) if the device doesn't support sysman? Would this be an error or could it return a NULL handle to indicate that this device does not support sysman? If it could legitimately return a NULL handle when sysman is not supported then maybe we don't even need an "is supported" query?
We would have to change it to ze_result_t zesDeviceGet(hDevice, hSysmanDevice) to get a proper error code. "Unsupported" would be a candidate.
The text was updated successfully, but these errors were encountered:
There are two issues we would like to address here:
As mentioned in oneapi-src/level-zero#36, there's a desired to have an API to enable SYSMAN, instead of an environment variable.
Additionally, there are frequent requests to add to Core API an interface that provides similar functionality to one already existing on SYSMAN. An example is
zesMemoryGetState
, which provides info on available memory in the system. Adding an interface on Core for something that is already provided on SYSMAN duplicates code, and is not scalable in the long run. So it is better to allow for SYSMAN interfaces to be used with Core when the application needs it.To provide a solution to these two issues, a new set of interfaces is being proposed to enable and access SYSMAN functionality. Idea is to provide interfaces to enable SYSMAN, as well as to discover SYSMAN devices, which will be used to access underlying functionality.
Initial proposal is the following, where we have
zesInit
,zesDriverSupported
, andzesGetDevice
.Some follow-up questions:
@bashbaug:
Would we want this to be
zesDriverSupported(hDriver)
or would it make more sense to havezesDeviceSupported(hDevice)
? In other words, would all devices supported by a driver always support sysman, or could some devices support sysman and some other devices not support sysman?What would the behavior be for
zesGetDevice(hDevice)
if the device doesn't support sysman? Would this be an error or could it return a NULL handle to indicate that this device does not support sysman? If it could legitimately return a NULL handle when sysman is not supported then maybe we don't even need an "is supported" query?We would have to change it to ze_result_t zesDeviceGet(hDevice, hSysmanDevice) to get a proper error code. "Unsupported" would be a candidate.
The text was updated successfully, but these errors were encountered: