Patchwork SSE & SSE2

This patch selects SSE & SSE2 in the socket if one exists (except for AMD
since there are many sockets for two models).

The reasoning is that sockets can support multiple models of CPUS for intel,
and SSE & SSE2 settings need to be based on the least capable CPU.

It's all correct as far as Google tells me.

Socket PGA370 - SSE but not SSE2 (supports PIII)
Slot 1 - SSE but not SSE2
Slot 2 - SSE but not SSE2
Via C3 - SSE but not SSE2
Via C7 - SSE and SSE2
Qemu - not SSE2 (I don't know about SSE, so I didn't set it)
Geode - not SSE or SSE2
intel ep80579 SSE and SSE2
Socket 441 SSE and SSE2
Socket mPGA479M SSE and SSE2
Socket mPGA604 SSE and SSE2
Socket BGA956 MMX and SSE and SSE2
Socket mFCPGA478 MMX and SSE and SSE2
Socket mPGA478 MMX and SSE and SSE2
Socket mPGA603 MMX and SSE and SSE2

some intel model_f?x Kconfig files weren't being sourced in
src/cpu/intel/Kconfig

Signed-off-by: Myles Watson <mylesgw@gmail.com>

Thanks,
Myles

On Tue, 16 Mar 2010 10:31:37 -0600, Myles Watson <mylesgw@gmail.com> wrote:
> This patch selects SSE & SSE2 in the socket if one exists (except for AMD
> since there are many sockets for two models).
> 
> The reasoning is that sockets can support multiple models of CPUS for
> intel,
> and SSE & SSE2 settings need to be based on the least capable CPU.
> 
> It's all correct as far as Google tells me.
> 
> Socket PGA370 - SSE but not SSE2 (supports PIII)
> Slot 1 - SSE but not SSE2
> Slot 2 - SSE but not SSE2
> Via C3 - SSE but not SSE2
> Via C7 - SSE and SSE2
> Qemu - not SSE2 (I don't know about SSE, so I didn't set it)
> Geode - not SSE or SSE2
> intel ep80579 SSE and SSE2
> Socket 441 SSE and SSE2
> Socket mPGA479M SSE and SSE2
> Socket mPGA604 SSE and SSE2
> Socket BGA956 MMX and SSE and SSE2
> Socket mFCPGA478 MMX and SSE and SSE2
> Socket mPGA478 MMX and SSE and SSE2
> Socket mPGA603 MMX and SSE and SSE2
> 
Yes this looks correct.

> some intel model_f?x Kconfig files weren't being sourced in
> src/cpu/intel/Kconfig
> 
> Signed-off-by: Myles Watson <mylesgw@gmail.com>
> 
Acked-by: Joseph Smith <joe@settoplinux.org>

On 3/16/10 6:00 PM, Joseph Smith wrote:
>> Socket PGA370 - SSE but not SSE2 (supports PIII)
>> Slot 1 - SSE but not SSE2
>> Slot 2 - SSE but not SSE2
>> Via C3 - SSE but not SSE2
>> Via C7 - SSE and SSE2
>> Qemu - not SSE2 (I don't know about SSE, so I didn't set it)
>> Geode - not SSE or SSE2
>> intel ep80579 SSE and SSE2
>> Socket 441 SSE and SSE2
>> Socket mPGA479M SSE and SSE2
>> Socket mPGA604 SSE and SSE2
>> Socket BGA956 MMX and SSE and SSE2
>> Socket mFCPGA478 MMX and SSE and SSE2
>> Socket mPGA478 MMX and SSE and SSE2
>> Socket mPGA603 MMX and SSE and SSE2
>>
>>     
> Yes this looks correct.
>
>   
Nope. Not at all.

>> some intel model_f?x Kconfig files weren't being sourced in
>> src/cpu/intel/Kconfig
>>
>> Signed-off-by: Myles Watson <mylesgw@gmail.com>
>>
>>     
> Acked-by: Joseph Smith <joe@settoplinux.org>
>   

Please don't commit... N-Ack/Veto by me!

See other mail in a minute or two.

On 3/16/10 5:31 PM, Myles Watson wrote:
> This patch selects SSE & SSE2 in the socket if one exists (except for
> AMD since there are many sockets for two models).
>
> The reasoning is that sockets can support multiple models of CPUS for
> intel, and SSE & SSE2 settings need to be based on the least capable CPU.
>
> It's all correct as far as Google tells me.
Not as far as Wikipedia is concerned. I think we should be careful as
this easily breaks the code in very nasty places (especially SSE chooses
the registers for ROMCC, so this definitely breaks some boards)

The settings have to be the most conservative, not the best possible.
That means if there is a single CPU for a socket that does not have SSE,
SSE has to be off for that socket. Choosing SSE to be on because there
is a single CPU for that socket that has SSE will break other systems.


http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions

> Slot 1 - SSE but not SSE2
Slot 1 is used by Pentium II, but only Pentium III has SSE.
Also, Celeron only has SSE starting from Coppermine. Covington and
Mendocino don't have SSE.
> Slot 2 - SSE but not SSE2
I think this is also wrong. Slot2 was then Xeon slot, but it also
started with Pentium II based CPUs, which do NOT have SSE.
> Via C3 - SSE but not SSE2
Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
CPUs don't.
http://de.wikipedia.org/wiki/VIA_C3


I stopped after checking three of the ones you changed, because all
three are wrong.. I think the code should not be changed. It's likely
that the whole table you were using to do the matching was not
describing what we need but instead the "socket capabilities" (i.e. the
biggest feature set usable with that socket)

Stefan

On 03/16/2010 07:29 PM, Stefan Reinauer wrote:
> On 3/16/10 5:31 PM, Myles Watson wrote:
>> This patch selects SSE&  SSE2 in the socket if one exists (except for
>> AMD since there are many sockets for two models).
>>
>> The reasoning is that sockets can support multiple models of CPUS for
>> intel, and SSE&  SSE2 settings need to be based on the least capable CPU.
>>
>> It's all correct as far as Google tells me.
> Not as far as Wikipedia is concerned. I think we should be careful as
> this easily breaks the code in very nasty places (especially SSE chooses
> the registers for ROMCC, so this definitely breaks some boards)
>
> The settings have to be the most conservative, not the best possible.
> That means if there is a single CPU for a socket that does not have SSE,
> SSE has to be off for that socket. Choosing SSE to be on because there
> is a single CPU for that socket that has SSE will break other systems.
>
>
> http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
>
>> Slot 1 - SSE but not SSE2
> Slot 1 is used by Pentium II, but only Pentium III has SSE.
> Also, Celeron only has SSE starting from Coppermine. Covington and
> Mendocino don't have SSE.
>> Slot 2 - SSE but not SSE2
> I think this is also wrong. Slot2 was then Xeon slot, but it also
> started with Pentium II based CPUs, which do NOT have SSE.
>> Via C3 - SSE but not SSE2
> Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
> CPUs don't.
> http://de.wikipedia.org/wiki/VIA_C3
>
>
> I stopped after checking three of the ones you changed, because all
> three are wrong.. I think the code should not be changed. It's likely
> that the whole table you were using to do the matching was not
> describing what we need but instead the "socket capabilities" (i.e. the
> biggest feature set usable with that socket)
>
Well then we are going to need a different solution......

On 3/17/10 12:34 AM, Joseph Smith wrote:
> On 03/16/2010 07:29 PM, Stefan Reinauer wrote:
>> On 3/16/10 5:31 PM, Myles Watson wrote:
>>> This patch selects SSE&  SSE2 in the socket if one exists (except for
>>> AMD since there are many sockets for two models).
>>>
>>> The reasoning is that sockets can support multiple models of CPUS for
>>> intel, and SSE&  SSE2 settings need to be based on the least capable
>>> CPU.
>>>
>>> It's all correct as far as Google tells me.
>> Not as far as Wikipedia is concerned. I think we should be careful as
>> this easily breaks the code in very nasty places (especially SSE chooses
>> the registers for ROMCC, so this definitely breaks some boards)
>>
>> The settings have to be the most conservative, not the best possible.
>> That means if there is a single CPU for a socket that does not have SSE,
>> SSE has to be off for that socket. Choosing SSE to be on because there
>> is a single CPU for that socket that has SSE will break other systems.
>>
>>
>> http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
>>
>>> Slot 1 - SSE but not SSE2
>> Slot 1 is used by Pentium II, but only Pentium III has SSE.
>> Also, Celeron only has SSE starting from Coppermine. Covington and
>> Mendocino don't have SSE.
>>> Slot 2 - SSE but not SSE2
>> I think this is also wrong. Slot2 was then Xeon slot, but it also
>> started with Pentium II based CPUs, which do NOT have SSE.
>>> Via C3 - SSE but not SSE2
>> Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
>> CPUs don't.
>> http://de.wikipedia.org/wiki/VIA_C3
>>
>>
>> I stopped after checking three of the ones you changed, because all
>> three are wrong.. I think the code should not be changed. It's likely
>> that the whole table you were using to do the matching was not
>> describing what we need but instead the "socket capabilities" (i.e. the
>> biggest feature set usable with that socket)
>>
> Well then we are going to need a different solution......

I think the code as it is works just fine. Ok, the warnings should be
silenced, but that's about it.

If someone is developing support for a new chipset and is using romcc
(which is the only reason one would need SSE to be set), they'll find
out what the best possible setting for their slot is, to avoid register
pressure :) If the code compiles, there is not (much) gain in enabling
SSE even if your CPU supports it.

As for SSE2, the only time this is used is for increasing the speed of
ram_check() which is normally not run.

So if you guys think this needs fixing, go ahead, but please don't break
things because it makes Kconfig look nicer. We just went into that trap
for ROMCC itself a day ago.

Stefan

On 03/16/2010 07:39 PM, Stefan Reinauer wrote:
> On 3/17/10 12:34 AM, Joseph Smith wrote:
>> On 03/16/2010 07:29 PM, Stefan Reinauer wrote:
>>> On 3/16/10 5:31 PM, Myles Watson wrote:
>>>> This patch selects SSE&   SSE2 in the socket if one exists (except for
>>>> AMD since there are many sockets for two models).
>>>>
>>>> The reasoning is that sockets can support multiple models of CPUS for
>>>> intel, and SSE&   SSE2 settings need to be based on the least capable
>>>> CPU.
>>>>
>>>> It's all correct as far as Google tells me.
>>> Not as far as Wikipedia is concerned. I think we should be careful as
>>> this easily breaks the code in very nasty places (especially SSE chooses
>>> the registers for ROMCC, so this definitely breaks some boards)
>>>
>>> The settings have to be the most conservative, not the best possible.
>>> That means if there is a single CPU for a socket that does not have SSE,
>>> SSE has to be off for that socket. Choosing SSE to be on because there
>>> is a single CPU for that socket that has SSE will break other systems.
>>>
>>>
>>> http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
>>>
>>>> Slot 1 - SSE but not SSE2
>>> Slot 1 is used by Pentium II, but only Pentium III has SSE.
>>> Also, Celeron only has SSE starting from Coppermine. Covington and
>>> Mendocino don't have SSE.
>>>> Slot 2 - SSE but not SSE2
>>> I think this is also wrong. Slot2 was then Xeon slot, but it also
>>> started with Pentium II based CPUs, which do NOT have SSE.
>>>> Via C3 - SSE but not SSE2
>>> Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
>>> CPUs don't.
>>> http://de.wikipedia.org/wiki/VIA_C3
>>>
>>>
>>> I stopped after checking three of the ones you changed, because all
>>> three are wrong.. I think the code should not be changed. It's likely
>>> that the whole table you were using to do the matching was not
>>> describing what we need but instead the "socket capabilities" (i.e. the
>>> biggest feature set usable with that socket)
>>>
>> Well then we are going to need a different solution......
>
> I think the code as it is works just fine. Ok, the warnings should be
> silenced, but that's about it.
>
> If someone is developing support for a new chipset and is using romcc
> (which is the only reason one would need SSE to be set), they'll find
> out what the best possible setting for their slot is, to avoid register
> pressure :) If the code compiles, there is not (much) gain in enabling
> SSE even if your CPU supports it.
>
> As for SSE2, the only time this is used is for increasing the speed of
> ram_check() which is normally not run.
>
> So if you guys think this needs fixing, go ahead, but please don't break
> things because it makes Kconfig look nicer. We just went into that trap
> for ROMCC itself a day ago.
>
Sorry my bad your right. I thought the whole point was to get rid of 
SSE2 build warnings on model_6xx cpu's that don't support SSE2.

> -----Original Message-----
> From: coreboot-bounces+mylesgw=gmail.com@coreboot.org [mailto:coreboot-
> bounces+mylesgw=gmail.com@coreboot.org] On Behalf Of Stefan Reinauer
> Sent: Tuesday, March 16, 2010 5:39 PM
> To: Joseph Smith
> Cc: coreboot@coreboot.org
> Subject: Re: [coreboot] [Patch] SSE & SSE2
> 
> On 3/17/10 12:34 AM, Joseph Smith wrote:
> > On 03/16/2010 07:29 PM, Stefan Reinauer wrote:
> >> On 3/16/10 5:31 PM, Myles Watson wrote:
> >>> This patch selects SSE&  SSE2 in the socket if one exists (except for
> >>> AMD since there are many sockets for two models).
> >>>
> >>> The reasoning is that sockets can support multiple models of CPUS for
> >>> intel, and SSE&  SSE2 settings need to be based on the least capable
> >>> CPU.
> >>>
> >>> It's all correct as far as Google tells me.
> >> Not as far as Wikipedia is concerned. I think we should be careful as
> >> this easily breaks the code in very nasty places (especially SSE
> chooses
> >> the registers for ROMCC, so this definitely breaks some boards)
> >>
> >> The settings have to be the most conservative, not the best possible.
> >> That means if there is a single CPU for a socket that does not have
> SSE,
> >> SSE has to be off for that socket. Choosing SSE to be on because there
> >> is a single CPU for that socket that has SSE will break other systems.
> >>
> >>
> >> http://de.wikipedia.org/wiki/Streaming_SIMD_Extensions
> >>
> >>> Slot 1 - SSE but not SSE2
> >> Slot 1 is used by Pentium II, but only Pentium III has SSE.
> >> Also, Celeron only has SSE starting from Coppermine. Covington and
> >> Mendocino don't have SSE.
> >>> Slot 2 - SSE but not SSE2
> >> I think this is also wrong. Slot2 was then Xeon slot, but it also
> >> started with Pentium II based CPUs, which do NOT have SSE.
I was looking at model numbers supported by Coreboot and the associated
sockets.  According to the table I was reading, socket_6xx means P4 so it
has SSE and SSE2.  

> >>> Via C3 - SSE but not SSE2
> >> Only Nehemiah and newer have SSE. All Samuel, Samuel2, Ezra and Ezra-T
> >> CPUs don't.
> >> http://de.wikipedia.org/wiki/VIA_C3
> >>
> >>
> >> I stopped after checking three of the ones you changed, because all
> >> three are wrong.. I think the code should not be changed. It's likely
> >> that the whole table you were using to do the matching was not
> >> describing what we need but instead the "socket capabilities" (i.e. the
> >> biggest feature set usable with that socket)
I understood that, but I guess I was looking in the wrong places.

I still think we should source all of the models for the intel CPUs.

> >>
> > Well then we are going to need a different solution......
> 
> I think the code as it is works just fine. Ok, the warnings should be
> silenced, but that's about it.
The easiest way is to have SSE and SSE2 default to n.  Then there will be no
warnings, and people can enable them when they need them.

It's confusing to have SSE and SSE2 settings in some of the models, but not
others.
 
> If someone is developing support for a new chipset and is using romcc
> (which is the only reason one would need SSE to be set), they'll find
> out what the best possible setting for their slot is, to avoid register
> pressure :) If the code compiles, there is not (much) gain in enabling
> SSE even if your CPU supports it.

I agree.

> As for SSE2, the only time this is used is for increasing the speed of
> ram_check() which is normally not run.
Yep.

> So if you guys think this needs fixing, go ahead, but please don't break
> things because it makes Kconfig look nicer. We just went into that trap
> for ROMCC itself a day ago.

:)

Thanks for the review.

Myles

> I was looking at model numbers supported by Coreboot and the associated
> sockets.  According to the table I was reading, socket_6xx means P4 so it
> has SSE and SSE2.
>
It is a little grey....
model_6xx is a big clump of PII, Celeron, and PIII's. According to Intel 
docs the P6 family includes Pentium Pro, PentiumII, Celeron, and PIII 
processors. P4 and XEON are the first of the IA-32 family.

>
> I still think we should source all of the models for the intel CPUs.
>
Yes I never liked how the model_6xx is all clumped togethor. I think 
they should be seperated by family/model. But that may be for another day...

On 3/17/10 1:05 AM, Myles Watson wrote:

> I understood that, but I guess I was looking in the wrong places.
>
> I still think we should source all of the models for the intel CPUs.
>
>   
Hah, sorry I forgot about that hunk.... 5231

>>>>         
>>> Well then we are going to need a different solution......
>>>       
>> I think the code as it is works just fine. Ok, the warnings should be
>> silenced, but that's about it.
>>     
> The easiest way is to have SSE and SSE2 default to n.  Then there will be no
> warnings, and people can enable them when they need them.
>   

I think you mentioned that a warning is generally good if people don't
set this explicitly... So maybe we should just fix what we know for sure
(most likely those with no SSE and SSE2) and wait for people to fix this
while they come along these CPUs/sockets... If nobody does, the warning
is maybe not critical for them ;)

> It's confusing to have SSE and SSE2 settings in some of the models, but not
> others. 
Yes. Since one socket can choose multiple cpus, it must go in the socket
to be safe (otherwise a SSE enabled CPU might break a socket with a
non-SSE enabled CPU), but there are also CPU models that don't come in
sockets... "Fake" sockets? Better solution? Set it in the CPU for those,
with a comment?

Stefan

> 
> > I understood that, but I guess I was looking in the wrong places.
> >
> > I still think we should source all of the models for the intel CPUs.
> >
> >
> Hah, sorry I forgot about that hunk.... 5231

Thanks.

> >>>>
> >>> Well then we are going to need a different solution......
> >>>
> >> I think the code as it is works just fine. Ok, the warnings should be
> >> silenced, but that's about it.
> >>
> > The easiest way is to have SSE and SSE2 default to n.  Then there will
> be no
> > warnings, and people can enable them when they need them.
> >
> 
> I think you mentioned that a warning is generally good if people don't
> set this explicitly...
:)

> So maybe we should just fix what we know for sure
> (most likely those with no SSE and SSE2) and wait for people to fix this
> while they come along these CPUs/sockets... If nobody does, the warning
> is maybe not critical for them ;)
Sure.  That does seem like the best way.

> > It's confusing to have SSE and SSE2 settings in some of the models, but
> not
> > others.
> Yes. Since one socket can choose multiple cpus, it must go in the socket
> to be safe (otherwise a SSE enabled CPU might break a socket with a
> non-SSE enabled CPU), but there are also CPU models that don't come in
> sockets... "Fake" sockets? 

> Better solution? Set it in the CPU for those,
> with a comment?
That's my vote.

Thanks,
Myles