Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DDI extension support #285

Draft
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

nrspruit
Copy link
Contributor

@nrspruit nrspruit commented Feb 22, 2025

  • Support in the L0 Loader for https://oneapi-src.github.io/level-zero-spec/level-zero/latest/core/EXT_Driver_DDIHandles.html#ze-extension-driver-ddi-handles
  • To improve the speed for each call of L0 apis into the correct driver, the new support enables for the driver to allocate a header that stores that driver's ddi tables such that the Loader does not need to perform translation of handles to/from ze_object_t.
  • Given a driver supports the new extension, the loader will no longer create the ze_object_t and instead use the packed ddi tables in each handle_t.
  • The code has been refactored such that the legacy path will continue to work for the driver that has not converted over without interfering with a driver which now uses the "fast" path.
  • This new code path also removes the need for handle translation by the user if the drivers all support the new extension.

@nrspruit nrspruit force-pushed the ddi_extension_support branch 4 times, most recently from c2f7ff5 to b1a43bf Compare February 25, 2025 20:34
pDriver = drivers[driver];
pDevice = findDevice( pDriver, type );
if( pDevice )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So clearly, we're going to find all devices now, and not break out at the first one.... However down at line 127 does this logic still hold, if we skip to the end of the driver list via this loop? Maybe instead we insert a temp variable and check pDevice for valid value, increment a counter, and below )(line 128 here, or 127 in new version) replace if (!pDevice) with a if( found_count == 0) ?

}
auto ${th.make_pfn_name(n, tags, obj)} = dditable->${th.get_table_name(n, tags, obj)}->${th.make_pfn_name(n, tags, obj)};
if( nullptr == ${th.make_pfn_name(n, tags, obj)} )
return ${X}_RESULT_ERROR_UNINITIALIZED;
%endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to many %endif here

@@ -97,6 +97,7 @@ zelLoaderTranslateHandleInternal(
}

bool validHandle = false;
*handleOut = handleIn;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't we need nullptr check before dereferencing the pointer?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add that at the start of this api.

return "ZE_API_VERSION_1_11"
if version == "1.12":
return "ZE_API_VERSION_1_12"
return "ZE_API_VERSION_1_0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe default path should break somehow, instead of just silently passing 1.0. If new api version is added and not handled here it shouldn't compile

@@ -96,48 +96,91 @@ zelLoaderTranslateHandleInternal(
return ZE_RESULT_SUCCESS;
}

bool validHandle = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about handling invalid handle after the entire switch?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we check for a valid handle for each handle type. This variable is set here such that we are not creating a new variable for each switch case.

The valid check is for if the handle was seen by the loader, I can change the name of the variable to be more self explanatory.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am removing the variable because it is not needed and I can simplify the check.

Copy link
Contributor

@JablonskiMateusz JablonskiMateusz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nrspruit added 13 commits March 3, 2025 15:12
Signed-off-by: Neil R. Spruit <[email protected]>
Signed-off-by: Neil R. Spruit <[email protected]>
Signed-off-by: Neil R. Spruit <[email protected]>
- Fixed get_version code gen script to fail if the api version for the
  api is not set or is invalid.
- fixed the zelLoaderTranslateHandle to fail given nullptrs and remove
  the extra vairable and simplify the hasInstance handle check.

Signed-off-by: Neil R. Spruit <[email protected]>
@nrspruit nrspruit force-pushed the ddi_extension_support branch from bde6a4a to de519a7 Compare March 3, 2025 23:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants