oneapi-src / level-zero

oneAPI Level Zero Specification Headers and Loader
https://spec.oneapi.com/versions/latest/elements/l0/source/index.html
MIT License
208 stars 90 forks source link

Question: Reusing Command Lists without reset? #52

Open jjfumero opened 3 years ago

jjfumero commented 3 years ago

This is a question about the Level Zero API.

I have the following sequence of instructions in which I accidentally forgot to reset. Once the command list is closed, I can still append commands into the command lists without getting any error/s. Is this behaviour expected?

Perhaps getting something like ZE_INVALID_COMMAND_LIST?

zeCommandListCreate -> Status: 0
zeMemAllocDevice -> Status: 0
zeModuleCreate -> Status: 0
zeModuleBuildLogDestroy -> Status: 0
zeKernelCreate -> Status: 0
zeCommandListReset -> Status: 0
zeKernelSuggestGroupSize -> Status: 0
zeKernelSuggestGroupSize -> Status: 0
zeKernelSetArgumentValue -> Status: 0
zeCommandListAppendLaunchKernel -> Status: 0
zeCommandListAppendBarrier -> Status: 0
zeCommandListAppendMemoryCopy -> Status: 0
zeCommandListAppendBarrier -> Status: 0
zeCommandListClose -> Status: 0
zeCommandQueueExecuteCommandLists -> Status: 0
zeCommandQueueSynchronize -> Status: 0
zeCommandListAppendMemoryCopy -> Status: 0         << Shouldn't we get an error? The list was already closed.
zeCommandListAppendBarrier -> Status: 0

Thank you,

jandres742 commented 3 years ago

Shouldn't we get an error? The list was already closed. zeCommandListAppendBarrier -> Status: 0

Possibly. This is very implementation-specific. In this case, if you are able to execute the list again after appending commands after the close, you are getting lucky that some of the programming for the first set of commands still help for the second set of commands. Returning an error for an append operation after a close w/o a reset, as you suggest, would be a good way of letting the user know that this is not recommended.

We are currently thinking on how to improve the validation layer, including adding tracking status of different L0 objects, as here, the list. This could be a good addition to it. We don't have at the moment timeline for the new validation layer, but will update once we have a formal plan when such changes can be added to the layer.