Shared Memory area on Kaby Lake
Posted: Thu Sep 07, 2017 7:02 am
Hi,
I am attempting to display data from Core Temp's shared memory area on my Win 10 Pro x64 Kaby Lake system... everything seems to work in the Core Temp app itself (as in, is displayed properly), but the shared memory area does not appear to be getting all values updated in it.
The major missing data seems to be the "power" values - I only see a value in the first element of the fPower array, and the values there appear to correspond to the "package" values displayed by the Core Temp app - but all of the remaining elements in the fPower array are 0.0.
It would probably be good to verify a key issue: the point of "shared memory" is so that the data-gathering app (Core Temp in this case) is able to publish its values in a very easily consumed format - for things like plugins.
When operating like this, all that is expected of the "client" code is that it use normal Windows mechanisms to map the shared memory area (which appears on my system as "\Sessions\1\BaseNamedObjects\CoreTempMappingObjectEx") into its own address space, so that it may then just access everything like, well, memory... ... and all that is really needed is that the monitor app continue to periodically update the data in the shared memory area.
The only reason I bring all of this [obvious and well-understood] stuff up is that the Core Temp SDK has samples which depart from this model, in particularly apparently expecting the client apps to be making API calls to physically fill a copy of the CoreTempMappingObjectEx structure... defeating the whole purpose and simplicity of using "shared memory".
So, in addition to verifying where actually to find the 5 "power" values displayed by Core Temp (the first 5 elements in the fPower array?), I was hoping for something like a verification of the expected "shared memory" access mechanism(s), and a statement something like "the Core Temp SDK API calls represent an alternate access method to the shared memory" - or something like that.
To be clear, all values in the shared memory area - when accessed like I describe above, and with no Core Temp SDK API calls whatsoever - appear to have valid and periodically updated data... except the "power" values.
So, does the Core Temp app itself do something trickier to get the other 4 power values, or is this possibly a bug, or ?
I am attempting to display data from Core Temp's shared memory area on my Win 10 Pro x64 Kaby Lake system... everything seems to work in the Core Temp app itself (as in, is displayed properly), but the shared memory area does not appear to be getting all values updated in it.
The major missing data seems to be the "power" values - I only see a value in the first element of the fPower array, and the values there appear to correspond to the "package" values displayed by the Core Temp app - but all of the remaining elements in the fPower array are 0.0.
It would probably be good to verify a key issue: the point of "shared memory" is so that the data-gathering app (Core Temp in this case) is able to publish its values in a very easily consumed format - for things like plugins.
When operating like this, all that is expected of the "client" code is that it use normal Windows mechanisms to map the shared memory area (which appears on my system as "\Sessions\1\BaseNamedObjects\CoreTempMappingObjectEx") into its own address space, so that it may then just access everything like, well, memory... ... and all that is really needed is that the monitor app continue to periodically update the data in the shared memory area.
The only reason I bring all of this [obvious and well-understood] stuff up is that the Core Temp SDK has samples which depart from this model, in particularly apparently expecting the client apps to be making API calls to physically fill a copy of the CoreTempMappingObjectEx structure... defeating the whole purpose and simplicity of using "shared memory".
So, in addition to verifying where actually to find the 5 "power" values displayed by Core Temp (the first 5 elements in the fPower array?), I was hoping for something like a verification of the expected "shared memory" access mechanism(s), and a statement something like "the Core Temp SDK API calls represent an alternate access method to the shared memory" - or something like that.
To be clear, all values in the shared memory area - when accessed like I describe above, and with no Core Temp SDK API calls whatsoever - appear to have valid and periodically updated data... except the "power" values.
So, does the Core Temp app itself do something trickier to get the other 4 power values, or is this possibly a bug, or ?