Shared Memory area on Kaby Lake

User feature requests
Planned features for Core Temp
Post Reply
RobertR
New User
Posts: 2
Joined: Thu Sep 07, 2017 6:17 am

Shared Memory area on Kaby Lake

Post by RobertR »

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

User avatar
The Coolest
Site Admin
Site Admin
Posts: 3379
Joined: Tue Feb 18, 2003 7:48 pm
Location: Tel Aviv, Israel
Contact:

Re: Shared Memory area on Kaby Lake

Post by The Coolest »

Hi,

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.
Main rig:
AMD Ryzen 9 5950X (True Spirit 140 Direct) / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
NAS:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB + HDDs / GPU: ATi Mach64 VT2 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Secondary rigs:
Core i3 7130U / MiniPC / SanDisk SDSSDP-128G / GPU: Intel HD 620 / Mem: 1x8GB DDR3L-1600
Xeon X3430 2.40GHz @ 3.06GHz or Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / PNY CS1111 240GB / GPU: ATI FirePro V3800 / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Seasonic S12II 620W
AMD Phenom II X4 B93 / Mobo: ASUS M2A-VM / GPU: ATI Radeon Xpress X1250 / Crucial M4 120GB / Mem: 2x2GB DDR2-800 - 4GB total / PSU: Antec 380W.

Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors

RobertR
New User
Posts: 2
Joined: Thu Sep 07, 2017 6:17 am

Re: Shared Memory area on Kaby Lake

Post 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".

Post Reply

Return to “Development”