[MPlayer-dev-eng] [PATCH] CPU detection related

[Vladimir Mosgalin]

Hi Zuxy!

 On 2005.10.16 at 20:43:27 +0800, Zuxy wrote next:

> > Though I'm not a developer, I have some suggestions:
> > 1) You'd better send text files with LF endings. People around here
> >    don't like text files in dos format ;)
> 
> I really don't think so....CRLF isn't that bad, is it?

No, it was a joke. However, \ vs / issue is more of a problem, since
patch has problems with it.

> > 2) WTF is "main.new\cpudetect.c"?? GNU patch (2.5.4) doesn't understand
> >    stuff like this, I had to convert them to "/" manually. I strongly
> >    suggest you to resend patch with correct dir separators.
> 
> Just conventinal. I'm using mplayer under win32 and I'm developing
> under mingw32.

Conventional way is to use /, both windows and unix understand this. \,
however, is windows-specific. Mingw/cygwin environments are unix-based
anyway, they approve usage of / for portability.

Also, only / must be used for patches in diff format - it's tradition.

(not to mention that argument "I'm developing under win32" is inferior
to the fact that developers who will be applying your patch are most
likely are using linux)

> > processor       : 0
> > vendor_id       : AuthenticAMD
> > cpu family      : 15
> > model           : 44
> > model name      : AMD Sempron(tm) Processor 2800+
> > stepping        : 2
> > cpu MHz         : 2663.728
> > cache size      : 256 KB
> > fdiv_bug        : no
> > hlt_bug         : no
> > f00f_bug        : no
> > coma_bug        : no
> > fpu             : yes
> > fpu_exception   : yes
> > cpuid level     : 1
> > wp              : yes
> > flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
> > bogomips        : 5275.64
> >
> >
> > Right now without your patch mplayer detects it as
> > CPU: Advanced Micro Devices  (Family: 15, Stepping: 2)
> > With your patch, it's
> > CPU: AMD Sempron(tm) Processor 2800+ (Family: F, Model: 2C, Stepping: 2)
> >
> > Its codename is Paris, if I'm not mistaken.
> >
> I've explained that in another thread, maintaining model->codename
> mapping is hell. I've dropped that. And from your reply I can see that
> even /proc/cpuinfo has dropped that either.

Er.. what? If you are talking about "model name" string, it's just a
string given by bios. After I upgraded to this CPU from A64 3000+
(Newcastle) old bios on the mobo knew nothing about this new cpu, and
the string was "AMD Hammer Family - Model unknown" both on the boot
screen and in cpuinfo. After I updated bios, it became like this.

I don't think it's reliable to rely on such kind of information, but be
it your way.. 

> You case isn't that simple. When looking for codename mplayer didn't
> care extended model (2 for your cpu), so it indexed into cputable with
> family 0xf and model 0xc, and what would it get? It would be "Athlon
> 64 Newcastle" which has model 0xc (not 0x2c). I'm much against this
> because two cpus with totally different models are treated alike,
> really confusing and may be misleading.

But that is a problem of current detection code, the overall idea still
works.. Especially with modern CPUs, you can precisely get its name and
other information from cpuid.

> Take a look at last line for AMD cpu (model 0xf) you'll know why I
> prefer namestring:-)BTW that line is far from complete since I didn't
> incorporate codenames for Opterons with model 0xf, and Semprons too,
> perhaps.
> 
> Anyway if you prefer the old way you can just apply the first patch
> and discard the other two (should have been the other one:-)), and
> update cputable.h yourself and send it to the team. New codenames are
> always welcome; I just won't do it myself.

No, I like the new too (but think about problem I described), it's just
that I was surprised by the fact that you missed the model name of the
CPU; from some older thread, I was under impression that you've been
looking through AMD/Intel sites for information about processor models,
and I thought that you updated cpu table from the latest model tables on
both sites. Looks like I was wrong and you picked only several ones.

By looking at the model number at /proc/cpuinfo, it wasn't clear at all
what exactly should have I modified in cputable.h, that's why I sent
cpuinfo contents and the codename to you. But if you don't feel like
giving an example and vote for throwing away the whole codenames system,
that's fine..

-- 

Vladimir