[L0] Fix DeviceInfo global mem free to report unsupported given MemCount==0

[nrspruit]

No description provided.

[ph0b]

This change assumes FreeMemory <= 0 means the FreeMemory api doesn't work, so I have a concern here: Wouldn't there be cases for which the call works and returns <=0 because the device is really out of memory ? In that case we really don't want to report global_memory.

[nrspruit]

This change assumes FreeMemory <= 0 means the FreeMemory api doesn't work, so I have a concern here: Wouldn't there be cases for which the call works and returns <=0 because the device is really out of memory ? In that case we really don't want to report global_memory.

Thank you for the comment @ph0b , I realized I should be checking the MemCount. If there are no memory modules reported by the API, then free memory is invalid. If there are MemCount modules, then free memory is the correct value.

[nrspruit]

This change assumes FreeMemory <= 0 means the FreeMemory api doesn't work, so I have a concern here: Wouldn't there be cases for which the call works and returns <=0 because the device is really out of memory ? In that case we really don't want to report global_memory.

Thank you for the comment @ph0b , I realized I should be checking the MemCount. If there are no memory modules reported by the API, then free memory is invalid. If there are MemCount modules, then free memory is the correct value.

If the API "fails", then the call will report a UR api failure. In the case of MemCount==0, it means that the API did not find any memory modules, which is not an error, but it does mean that the free memory is not set.

[nsirgien]

Hi @nrspruit, can you please explain more about a reason behind this changes?
I mean, as far as I know, the intended behavior is that if you have free memory aspect, then you should get real free memory numbers from driver. And if you do not have free memory aspect, then attempt to access free memory information would lead to a runtime error.
So, I do not understand, when the code suppose to enter the else branch of this change?
I mean, before it was returning zero, which was wrong, as it was described in https://jira.devtools.intel.com/browse/URT-626.
But with change, it will now return global memory (which is a constant), which is IMHO also wrong.

[nrspruit]

Hi @nrspruit, can you please explain more about a reason behind this changes? I mean, as far as I know, the intended behavior is that if you have free memory aspect, then you should get real free memory numbers from driver. And if you do not have free memory aspect, then attempt to access free memory information would lead to a runtime error. So, I do not understand, when the code suppose to enter the else branch of this change? I mean, before it was returning zero, which was wrong, as it was described in https://jira.devtools.intel.com/browse/URT-626. But with change, it will now return global memory (which is a constant), which is IMHO also wrong.

Based on offline discussion, this has been changed to return unsupported if the number of memory modules returned is 0. That way you either get the free memory or unsupported, if the L0 driver cannot query the free memory in this device.