[coreboot] [Patch] SSE & SSE2

[Stefan Reinauer]

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