L4 cache about libcpuid HOT 18 CLOSED

Probably something like this: https://software.intel.com/en-us/articles/gpu-detect-sample

However, that requires DirectX, and if there's no way around it - we should be doing something else. Geekbench apparently has L4 cache detection, and they are crossplatform, so chances are it's doable.

from libcpuid.

Did you have a chance to explore? We might close this if it's windows-specific or requires directX.

from libcpuid.

Apparently it uses many win api functions, will take a closer look

from libcpuid.

There is useful code, but the means to get the raw is quite obscure to me, full of win api functions, which requires learning what most functions do internally, too much for me.

I'll close for it now, perhaps @x0rg can look into the code, I see there is a __cpuid

https://msdn.microsoft.com/en-us/library/hskdteyh.aspx

from libcpuid.

I have never used Win API, and my C++ level is very bad.
I'll take a look in Intel Architectures Software Developer’s Manual, maybe there are explanations.

from libcpuid.

Actually, John from GeekBench tuned in and shared that L4 cache is a simple matter of deterministic cache decoding in CPUID leaf 04h. In hindsight, I've made cpuid_get_raw_data() only fetch the data for ECX=0, 1, 2 and 3 - getting us L1i, L1d, L2 and L3 - but no L4. I will update the relevant code about this soon.

from libcpuid.

Do you will add l4_cache, l4_assoc and l4_cacheline variables in cpu_id_t?

from libcpuid.

Yes. I want to have this tested first, and I am waiting for some friends which might have Crystalwell CPUs to send in some raw.txt files to test decoding. Of course, that means all tests will be invalidated soon, since they'd need those two fields.

from libcpuid.

Ok. I think you'll tag v0.3.0 after these tests?

from libcpuid.

Yes. I plan to

• Add l4_cache, l4_assoc and l4_cacheline fields to cpu_id_t.
• Test L4 cache handling code.
• Add the sent raw.txt to tests, and update all other tests.
• Compile static and dynamic library versions for Win32, Win64, and Mac OS X, and make a release in Sourceforge. I believe there will be some minor changes here, since the MSVC compiler is C89 only (I'm using MSVC7.1 for best compatibility) and doesn't like declaring variables "as needed". Anyways, the fixes there will be trivial.
• Tag v0.3.0 in github.

from libcpuid.

@anrieff
raw.txt for Intel Core i7-4750HQ: http://ark.intel.com/products/codename/51802/Crystal-Well#@Mobile
raw.txt

from libcpuid.

Thank you SO much! I've been trying desperately to find exactly that, but none of my friends had a Crystalwell.

from libcpuid.

These data are obtained on MacBook Pro Retina (Mid 2014) of my friend.

from libcpuid.

Well I pinged friends with Mid-2014 MacBook Pro Retinas, but they all had Broadwell-U CPUs, and no eDRAM. Anyway, the cache size is detected, I pushed 3f51d3c with the detection. Will add the test and fix up all other tests (to add a L4 fields, which will be -1 for all current CPUs in the tests DB).

from libcpuid.

Win32 build errors:

1. ATOM is a predefined macro in windef.h
2. Visual studio does not support c99:
   2.1) in function cpuid_identify_intel: variables declaring "as needed"
   2.2) c99 struct initialization in file rdmsr.c: "static struct internal_id_info_t internal = { .score = -1 };"

from libcpuid.

I know, I'll fix these as soon as I get back my Windows machine.

from libcpuid.

from libcpuid.

L4 cache fully supported in f52c02d (tests updated). The Intel Core i7-4750HQ test added in 87f3052.

from libcpuid.