Skip to content

Conversation

@ldorau
Copy link
Contributor

@ldorau ldorau commented Nov 7, 2025

Replace urEnqueueKernelLaunch() property list with pNext chain property structures.
It resolves Jira URT-990

@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 5e31e12 to b0df01e Compare November 7, 2025 17:18
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from b0df01e to a000354 Compare November 7, 2025 20:47
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from a000354 to 1ae0f9d Compare November 7, 2025 20:57
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 1ae0f9d to 01c7fc1 Compare November 12, 2025 09:59
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 01c7fc1 to 2a106f0 Compare November 12, 2025 11:16
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 2a106f0 to 5f3a8b9 Compare November 12, 2025 12:16
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 5f3a8b9 to 94998d8 Compare November 12, 2025 12:40
return UR_RESULT_ERROR_UNSUPPORTED_FEATURE;
}

while (_launchPropList != nullptr) {
Copy link
Contributor

Choose a reason for hiding this comment

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

You can parse those properties using find_stype_node (like here https://github.com/intel/llvm/blob/sycl/unified-runtime/source/adapters/level_zero/usm.cpp#L1052).

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 think it cannot be used in this place, since we are not looking for a specific type here. Is it right?

@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 94998d8 to 5dc229b Compare November 12, 2025 13:37
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 5dc229b to d1589af Compare November 12, 2025 13:41
@ldorau
Copy link
Contributor Author

ldorau commented Nov 13, 2025

Rebased

@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 17fdcc7 to 889ed38 Compare November 13, 2025 09:58
@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 889ed38 to 017d5f3 Compare November 13, 2025 10:08
name: numPropsInLaunchPropList
desc: "[in] size of the launch prop list"
- type: const $x_kernel_launch_property_t*
- type: const $x_kernel_launch_ext_properties_t*
Copy link
Contributor

Choose a reason for hiding this comment

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

My understanding was that it was only experimental interfaces that were allowed to change arguments. Is that not the case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 017d5f3 to a512bd9 Compare November 13, 2025 12:50
@steffenlarsen
Copy link
Contributor

Just for future reference, it would be preferable if you avoid doing force-pushes. It makes if more difficult to track what changes between reviews. Merges squash commits and uses the description and title of the PR, so it will still become a single commit in the end.

@ldorau
Copy link
Contributor Author

ldorau commented Nov 13, 2025

The make generate step produces a wrong output in the Unified Runtime Pre Commit / Source Checks / source_checks (windows-2022) (pull_request) CI job - the code does not compile with the generated output source code.

@steffenlarsen
Copy link
Contributor

steffenlarsen commented Nov 13, 2025

The make generate step produces a wrong output in the Unified Runtime Pre Commit / Source Checks / source_checks (windows-2022) (pull_request) CI job - the code does not compile with the generated output source code.

That is interesting. It looks like it is related to #20610, but UR CI don't run for libclc, so I don't think we caught it as part of that. @jinge90 - Are the changes it suggest valid? It doesn't look valid to me.

Copy link
Contributor

@steffenlarsen steffenlarsen left a comment

Choose a reason for hiding this comment

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

SYCL RT, NativeCPU, CUDA and HIP changes LGTM!

@sarnex
Copy link
Contributor

sarnex commented Nov 13, 2025

The make generate step produces a wrong output in the Unified Runtime Pre Commit / Source Checks / source_checks (windows-2022) (pull_request) CI job - the code does not compile with the generated output source code.

That is interesting. It looks like it is related to #20610, but UR CI don't run for libclc, so I don't think we caught it as part of that. @jinge90 - Are the changes it suggest valid? It doesn't look valid to me.

We can ignore it, the linked PR (not this one) caused some nonsense on Windows.

@ldorau Please rebase on top of HEAD and run CI again

@ldorau ldorau force-pushed the Replace_urEnqueueKernelLaunch_property_list_with_pNext_chain_property_structs branch from 107a00b to 832ea04 Compare November 13, 2025 19:55
@ldorau
Copy link
Contributor Author

ldorau commented Nov 13, 2025

The make generate step produces a wrong output in the Unified Runtime Pre Commit / Source Checks / source_checks (windows-2022) (pull_request) CI job - the code does not compile with the generated output source code.

That is interesting. It looks like it is related to #20610, but UR CI don't run for libclc, so I don't think we caught it as part of that. @jinge90 - Are the changes it suggest valid? It doesn't look valid to me.

We can ignore it, the linked PR (not this one) caused some nonsense on Windows.

@ldorau Please rebase on top of HEAD and run CI again

Rebased.

@nrspruit
Copy link
Contributor

FYI, the failures happening in https://github.com/intel/llvm/actions/runs/19344092070/job/55340836099?pr=20596 seem to be due to a race condition that has existed since the V1/V2 adapters for L0 were allowed to be "skipped". The adapters were not being properly torndown resulting in sporadic crashes. This fixes that problem #20642 .

To fix that issue you will need to merge my PR first.

@nrspruit
Copy link
Contributor

FYI, the failures happening in https://github.com/intel/llvm/actions/runs/19344092070/job/55340836099?pr=20596 seem to be due to a race condition that has existed since the V1/V2 adapters for L0 were allowed to be "skipped". The adapters were not being properly torndown resulting in sporadic crashes. This fixes that problem #20642 .

To fix that issue you will need to merge my PR first.

nevermind, my fix does resolve an issue, but this sporadic UR only issue in V2 persists. I at least cannot reproduce the hang outside of the CI.

Copy link
Contributor

@mmichel11 mmichel11 left a comment

Choose a reason for hiding this comment

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

Command buffer changes LGTM

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.

6 participants