Page 1 of 1

Shared Memory area on Kaby Lake

PostPosted: Thu Sep 07, 2017 7:02 am
by RobertR

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. :mrgreen:

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... 8) ... 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 ?

Re: Shared Memory area on Kaby Lake

PostPosted: Thu Sep 07, 2017 5:09 pm
by The Coolest

The shared memory block is a separate structure from the internal data structures used in Core Temp.
The extra power values are a relatively new addition, and are currently not exposed via this interface.

I understand that the point of shared memory is to be a shared memory block, but the idea behind the SDK API was to make it easy and simple for a novice developer to get started and also make this feature more foolproof and robust. What the SDK does behind the scene is what you describe, it maps the structure and then copies it over into the structure provided by the user. I guess I could have implemented it differently, but I haven't touched that part of the code in years now, and can't remember the exact reasoning behind the existing implementation.
There is nothing preventing you from doing it your way, though, the SDK is basically a simple wrapper.

Re: Shared Memory area on Kaby Lake

PostPosted: Thu Sep 07, 2017 7:43 pm
by RobertR
Thanks for the speedy and detailed reply, Coolest - I am glad to know I wasn't missing something, as well as there being no bug. :)

When you get around to publishing the power info in the Core Temp shared memory area, I will add code to make use of it - for now, I will finish up my support of Core Temp with the per-core temperature and load values.

For those playing along from home, I have a GitHub project for "RXMDocklet", an ObjectDock (and clones like RocketDock) C++ applet for amalgamating and formatting the display of data from half a dozen H/W monitor apps that make their output available using shared memory... I will be doing the code commit adding support for Core Temp shortly.

Thanks for building something like Core Temp with such a low resource-consumption "footprint".