-
Notifications
You must be signed in to change notification settings - Fork 86
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
Parameter validation layer erroneously checks pCommandQueueGroupProperties #120
Comments
thanks @etomzak . It is true that zeDeviceGetCommandQueueGroupProperties populates the data, but only for [out] args. [In] arguments, as stype, are only inputs, and must be set by the application. ze_structure_type_t stype ze_structure_type_t stype void *pNext ze_command_queue_group_property_flags_t flags size_t maxMemoryFillPatternSize uint32_t numQueues |
That is a ... surprising API design. I'm not convinced it makes sense. Intuitively, even if More broadly, the concept of I looked up Vulkan to see what they do in this situation. A couple of examples are |
thanks @etomzak . The use of stype as in as you mention, where in means that users set that value, follows the convention of other APIs, like Vulkan, please see here https://registry.khronos.org/vulkan/site/guide/latest/pnext_and_stype.html#:~:text=The%20void*%20pNext%20is%20used,extensions%20that%20expose%20new%20structures. In L0, stype is use for properties and other structs. Having stype as in is needed so the user can tell the target driver which structure the user is passing. W/o this , the driver would have to guess which struct the application is trying to use, which might be not efficient or easy to implement. |
I'm seeing some unexpected behavior with the parameter validation layer enabled.
Expected behavior:
Calling
zeDeviceGetCommandQueueGroupProperties()
populates the memory pointed to by thepCommandQueueGroupProperties
parameter.Actual behavior:
Calling
zeDeviceGetCommandQueueGroupProperties()
returnsZE_RESULT_ERROR_INVALID_ARGUMENT
.Comments
The issue is that the validation layer expects the
ze_command_queue_group_properties_t::stype
field to be set by the application. However, it is the responsibility of thezeDeviceGetCommandQueueGroupProperties()
function to initialize the data. The work-around is for the application to partially initialize the data by setting allze_command_queue_group_properties_t::stype
fields before callingzeDeviceGetCommandQueueGroupProperties()
.I think this is the offending line, and I suspect the solution is just to remove it.
The text was updated successfully, but these errors were encountered: