David Kuehling | 29 Apr 14:39

[PATCH] cpu support for VIA and Transmeta processors

Hi,

after suffering from extremely low encoding speed on my VIA C7 system, I
had a look at the sources and found out, that MMX and SSE optimization
are only enabled for Intel and AMD CPUs.

The attached patch adds proper CPU capability detection for Via C7, Via
C3 and Transmeta (Crusoe, Efficeon) processors.

Tested on a Via C7 and on a Transmeta Crusoe TM5800.  Via C3 code was
just checked against the output of the 'cpuid' tool.

cheers,

David
--

-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

_______________________________________________
theora-dev mailing list
theora-dev <at> xiph.org
http://lists.xiph.org/mailman/listinfo/theora-dev
Ralph Giles | 29 Apr 18:38
Favicon

Re: [PATCH] cpu support for VIA and Transmeta processors

On 29-Apr-08, at 5:42 AM, David Kuehling wrote:

> The attached patch adds proper CPU capability detection for Via C7,  
> Via
> C3 and Transmeta (Crusoe, Efficeon) processors.

Thanks! Committed as r14813.

  -r
Favicon

Re: [PATCH] cpu support for VIA and Transmeta processors

David Kuehling wrote:
> Tested on a Via C7 and on a Transmeta Crusoe TM5800.  Via C3 code was
> just checked against the output of the 'cpuid' tool.

I have done lots of clean-up to that file in r14814. The only
interesting functional modification is that I made the Intel vs. AMD CPU
flags tests exclusive for VIA processors. According to some random
posting on mplayer-users
(http://lists.mplayerhq.hu/pipermail/mplayer-users/2003-October/038847.html)
the Nehemiah 693 no longer returns useful AMD-like flags, though it
appears to return useful Intel-like flags, so overwriting the results of
the Intel test with the AMD one would be bad. If you can point me to any
official documentation for any of these processors, I would greatly
appreciate it, as my cursory search did not find any.

Please test the results and make sure I didn't screw anything up.

I also added proper support for detecting the cpuid instruction on
win32, instead of just blindly trying to use it. I have absolutely no
idea if this works. Someone on win32 will need to test that it even
compiles.
David Kuehling | 4 May 14:59

Re: [PATCH] cpu support for VIA and Transmeta processors

>>>>> "Timothy" == Timothy B Terriberry <tterribe <at> email.unc.edu> writes:

> I have done lots of clean-up to that file in r14814. The only
> interesting functional modification is that I made the Intel vs. AMD
> CPU flags tests exclusive for VIA processors. 
[..]
> Please test the results and make sure I didn't screw anything up.

Works for C7.  

But Cheking the cpuid output of C3 it looks like C3's 3D-Now
functionality won't be detected.  In your code you only check for 3D-Now
if the Intel-style test for MMX fails ( !(edx&0x00800000) ).  But the
Intel-style MMX test will be successfull on C3.  According to cpuid:

 eax in    eax      ebx      ecx      edx
00000000 00000001 746e6543 736c7561 48727561
00000001 00000673 00000000 00000000 00803135
80000000 80000006 00000000 00000000 00000000
80000001 00000673 00000000 00000000 80803135
80000002 20414956 756d6153 32206c65 00000000
80000003 00000000 00000000 00000000 00000000
80000004 00000000 00000000 00000000 00000000
80000005 00000000 08800880 40040120 40040120
80000006 00000000 00000000 40040120 00000000

That's why my code always checked for AMD-Style vector support and later
added results from the Intel-Style check.  This strategy also works for
C7 (and hopefully for C3-2), see cpuid output of C7:

(Continue reading)

Favicon

Re: [PATCH] cpu support for VIA and Transmeta processors

David Kuehling wrote:
> That's why my code always checked for AMD-Style vector support and later
> added results from the Intel-Style check.  This strategy also works for
> C7 (and hopefully for C3-2), see cpuid output of C7:

Ah, but you didn't add them, you threw the old results away, which would
not have worked correctly on some C3-2's. I've updated the test in svn
r14834. See if that works for you.

We don't actually use 3dnow! support for anything currently, but it's
better to have the test correct than not.
David Kuehling | 5 May 00:04

Re: [PATCH] cpu support for VIA and Transmeta processors

>>>>> "Timothy" == Timothy B Terriberry <tterribe <at> email.unc.edu> writes:

> David Kuehling wrote:
>> That's why my code always checked for AMD-Style vector support and
>> later added results from the Intel-Style check.  This strategy also
>> works for C7 (and hopefully for C3-2), see cpuid output of C7:

> Ah, but you didn't add them, you threw the old results away, which
> would not have worked correctly on some C3-2's. I've updated the test
> in svn r14834. See if that works for you.

Your new code looks good.  Though I didn't compile it (yet).  BTW
anybody knows how to enable the TH_DEBUG() debug messages?  I'm always
adding my own debug code to see what CPU detection did...

cheers,

David
--

-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
Favicon

Re: [PATCH] cpu support for VIA and Transmeta processors

David Kuehling wrote:
> Your new code looks good.  Though I didn't compile it (yet).  BTW
> anybody knows how to enable the TH_DEBUG() debug messages?  I'm always
> adding my own debug code to see what CPU detection did...

Monty added those, but grep says:

CFLAGS=-D_TH_DEBUG_ ./configure && make clean && make

However, then you run into the problem that the variables dframe and
debugout are only defined in the encoder, even though they're used in
the decoder, so the decoder examples will fail to build.
David Kuehling | 5 May 11:46

Re: [PATCH] cpu support for VIA and Transmeta processors

>>>>> "Timothy" == Timothy B Terriberry <tterribe <at> email.unc.edu> writes:

> Monty added those, but grep says:

> CFLAGS=-D_TH_DEBUG_ ./configure && make clean && make

> However, then you run into the problem that the variables dframe and
> debugout are only defined in the encoder, even though they're used in
> the decoder, so the decoder examples will fail to build.

Ran into those errors, too.  That's why I thought this wasn't supported
any more.  Well, if the decoder works, this will be sufficient for
checking.

BTW reading over your prior mail again,

> Ah, but you didn't add them, you threw the old results away, which
> would not have worked correctly on some C3-2's. I've updated the test
> in svn r14834. See if that works for you.

didn't understand what you meant, when I read it the first time.  But
you'r right, it was my code that was broken, and your cleanup didn't
change the semantics.  It's always the same when one thinks one can get
away with not properly verifying new code :)

David
--

-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
(Continue reading)

Favicon

Re: [PATCH] cpu support for VIA and Transmeta processors

One final clean-up committed in r14849. I've unified flag parsing across
all the various brands, since from all the engineering documents I have,
they appear to be compatible. The CPU brand detection now just decides
which ones we try and in what order. I've also added detection for all
the instruction sets up through SSE5 (in case any really bored kids out
there want to rewrite our DCT for the "30%" performance increase the
marketing material claims for an instruction set not due to be
implemented in a real processor until next year).

Hopefully I didn't screw anything up. Unless someone tells me it breaks
for them, I'm going to stop screwing around with this.

Gmane