Beta 2 Bug - Processor::init calculates CPU type/name incorrectly
by Joel Baxter · in Torque 3D Professional · 05/03/2009 (8:25 pm) · 7 replies
Just something I noticed while stepping through the T3D init sequence (on Windows) out of curiosity:
In the detectX86CPUInfo function, and in the equivalent inline assembly in Processor::init, CPUID leaf 1 EAX is masked with 0xff0. This preserves the family and model info, but not extended model and extended family. And then SetProcessorInfo only uses model and family (not extended) to figure out the processor type & name.
By dropping extended model and extended family on the floor, T3D will have problems correctly identifying some recent Intel and AMD CPUs. For example, T3D says that my Core i7 (Nehalem Bx) is a Pentium III, since it sees that the model is 0xA and doesn't check the extended model.
As a side note, I'm assuming/hoping that the calculated processor type and name aren't used for anything other than informative printouts -- a quick grep seems to confirm this. (I.e. only specific CPUID feature flags should be used to affect code functionality.) Might be worth a comment to that effect in platform.h, for the benefit of anyone fiddling with the source. :)
In the detectX86CPUInfo function, and in the equivalent inline assembly in Processor::init, CPUID leaf 1 EAX is masked with 0xff0. This preserves the family and model info, but not extended model and extended family. And then SetProcessorInfo only uses model and family (not extended) to figure out the processor type & name.
By dropping extended model and extended family on the floor, T3D will have problems correctly identifying some recent Intel and AMD CPUs. For example, T3D says that my Core i7 (Nehalem Bx) is a Pentium III, since it sees that the model is 0xA and doesn't check the extended model.
As a side note, I'm assuming/hoping that the calculated processor type and name aren't used for anything other than informative printouts -- a quick grep seems to confirm this. (I.e. only specific CPUID feature flags should be used to affect code functionality.) Might be worth a comment to that effect in platform.h, for the benefit of anyone fiddling with the source. :)
#2
I agree that it doesn't really matter what the CPU type/name is, so this isn't an urgent bug. It will just log/print the wrong thing.
(Although, along the lines of the last part of my bug report, I _am_ a teeny bit uneasy that the CPU type is actually an enum; people with source code access might be tempted to make some decisions based on it. Which is the wrong thing to do in general, but doubly wrong if the calculated value is incorrect.)
05/04/2009 (9:06 am)
It's been updated some, as it at least tries to detect up through Core 2 CPUs on the Intel side. I didn't look at the AMD side that closely.I agree that it doesn't really matter what the CPU type/name is, so this isn't an urgent bug. It will just log/print the wrong thing.
(Although, along the lines of the last part of my bug report, I _am_ a teeny bit uneasy that the CPU type is actually an enum; people with source code access might be tempted to make some decisions based on it. Which is the wrong thing to do in general, but doubly wrong if the calculated value is incorrect.)
#3
05/04/2009 (2:13 pm)
Old issue, like you said. I will log it and see if we can get this updated. 
#4
More or less cosmetic but what the heck. Updated the code to at least detect some more Intel processors.
As for AMD, I refuse to spend the extra time to try to get beyond their immediately accessible, completely worthless documentation.
05/09/2009 (3:21 am)
More or less cosmetic but what the heck. Updated the code to at least detect some more Intel processors.
As for AMD, I refuse to spend the extra time to try to get beyond their immediately accessible, completely worthless documentation.
#5
SetProcessorInfo now has this line of code:
but it should instead be this:
06/01/2009 (9:59 pm)
For what it's worth, this is still wonky in beta 2.SetProcessorInfo now has this line of code:
U32 extendedModel = ( processor & 0xf00 ) >> 16;
but it should instead be this:
U32 extendedModel = ( processor & 0xf0000 ) >> 16;
#7
06/03/2009 (1:43 pm)
The processor info stuff is good if your game collects hardware spec information into a database, like Steam does. This is useful for long-term online games in order to have a grasp of the userbase hardware while deciding on future updates or even optimization patches. 
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
As it requires at max a P3 for the cpu features it uses (SSE and MMX), if they are used at all anymore with shaders beeing present (MMX was used on the legacy terrain), it does likely not make too much sense for it to check for higher things and find out what cpu it is in detail
that might thought change if multithreading becomes a real topic